Really Simple Syndication: The Joy of Specs
The ongoing Canterbury tale about the efforts of the RSS Advisory Board must be utterly incomprehensible to people who have enthusiastically adopted Really Simple Syndication without knowing the history of the format.Syndication is like sausage, major Congressional legislation and Bruce Jenner. You might be better off not knowing how it's made.
Dave Winer, the co-creator of RSS and the person most responsible for its widespread adoption, argues that the current version of the RSS specification must never be revised in order to protect the stability of the format:
These constraints have served us well. They have kept the platform stable, so Microsoft could take two years to adopt it from top to bottom in their Windows operating system, and not have RSS change while they did their work.
This position deserves strong consideration, though I must point out that under his leadership the board made six revisions to the specification.
If the current spec is treated as the final word on the matter, there are practical consequences to that decision for RSS software developers, publishers and users.
One of the biggest involves podcasting.
An RSS feed may carry podcasts and other media files, storing them in enclosures associated with items in the feed.
There's disagreement among developers over whether the spec permits more than one enclosure in each item. Some believe that because it doesn't explicitly forbid multiple enclosures, they're permitted. Others can demonstrate that the spec author's intent was to allow no more than one.
The publishing tools Blogware, Movable Type and WordPress all produce RSS feeds with multiple enclosures per item.
The political weblog Power Line, published with Movable Type 3.15, offers a podcast feed that includes multiple enclosures.
This feed doesn't work properly in some popular podcast-enabled RSS clients, including Bloglines, FeedDemon, Google Reader and new software being developed by Microsoft, the company whose top-to-bottom support for RSS is cited as the reason to leave the spec alone.
The preview edition of Microsoft Internet Explorer 7 only downloads the first enclosure in each item. Power Line users who listen to its podcasts with that browser must manually download the other enclosures, which removes the biggest advantage of podcasting -- instant availability of the files.
When Microsoft rolls out the browser later this year, millions of new users will be introduced to RSS and podcasts for the first time.
If no group has the authority to resolve the enclosures issue, all podcasters relying on multiple enclosures will be publishing RSS feeds that don't work for what is potentially their largest audience.
Comments
I make my living largely by developing web sites that produce and consume RSS - these clarifications to the spec (either way they fall) will be very welcome.
Rogers:
I've been following the rss-public and rss-board Yahoo group discussions. I encourage you to move RSS forward into a well specified light...
The RSS Board was architected and implemented by Dave Winer. It appears that he then considered the Spec locked down tight and the Board a "help desk" for implementors to query.
What he is learning is that a board can and should act or disband if there's no work to be accomplished.
Once you started to take the role of the board in ernest Dave has re-emerged as someone with ultimate control (in his mind) of the process.
I hope you ignore his rantings and control tactics and conduct the work of clarifying the issues that are well known to all RSS implementors for the benefit of users (publishers and readers) who don't care about such issues: Does the technology work as expected? It clearly does NOT and some clarification could suggest changes for developers to save us all a lot of needless drama and confusion.
I sincerely wish Dave Winer would let the "baby" grow up and spend some time putting out an OPML 1.1 spec or creating some specs for an ABI between the OPML Editor and Blogging services... MetaWeblog 2.x
Dave's role as a visionary and entrepreneur is unquestioned but his role as an administrator is highly questionable. I see too many voices in the b'verse that confuse the two roles and give him more rights and control over issues than he reasonably can lay a claim too.
We should counsel him to a degree and stop enabling his tactics... They lead to confusion and the inability to discuss policy and specifications that are required to make the net function.
Keep the RSS Board moving: add more members, let the politically and economically sensitive board members gracefully step down (if they fear the backlash from the "Bear" or don't see the value) and clarify the spec.
One final point:
People often focus on the pain of committee work but there is a temperment and work style that can make a committee effective and relatively Joyful.
It's a personality style that pulls the meat from the debate, drives to concensus and closes debate after something have been decided.
Rogers, you have those qualities. I suspect that those are they qualities that led you to be included by Dave in the formation of the RSS Board.
There can be Joy in Specs... when they are complete and they make a positive difference in people's lives.
Personally, I think it's exceptionally silly to forcibly ignore extra enclosures in RSS 2.0 for the sake of simply being "correct". If you ignore the extra enclosures, you've made your aggregator clearly less convenient even if you can legitimately make the argument that it's more correct.
I'll write here what I wrote in Dave Winer's weblog, which I guess he found too offensive to leave as a comment:
This is something that shouldn't be treated lightly, because this is one issue I have pushed Rogers on--enclosures.
I did some work for Molly at molly.com, and had to modify her installation of Wordpress, because it would put in multiple enclosures. These would then cause some RSS aggregators to break.
This is one issue where clarification in the specification is considered especially important.
Rogers, I hope you don't consider this comment to be offensive and allow it to remain.
"...all podcasters relying on multiple enclosures will be publishing RSS feeds..."
Please define "podcaster" and "RSS" as used in this context.
Rogers, I clearly support your efforts to continue evolving the RSS 2.0 spec, for all the reasons you've specified in your series of posts on the subject here (and in my own posts on the subject here, there, and elsewhere). Yes, I carry some baggage into this opinion, but yes, I also think that you're right in saying that without a clear spec, RSS 2.0 is a crippled beast that will continue to "work" and "break" at the whim of each developer's read of the (currently inadequeate) specification.
Honestly, though, my feeling would be that this whole morass -- the resurgence of this whole what's-OK-to-clarify mess -- should stand out to Microsoft and any other aggregator implementor as a reason to move towards a spec that does have a clear specification, and does have a clear method of allowing that spec to evolve as its deficiencies are noted and its needs are further defined. The longer this goes on, the more marginalized RSS 2.0 is going to find itself, perhaps to the benefit of both implementors and users alike.
Keep up the fight, you are doing the community a service. Who's know i may even switch my default format from atom3.0 to RSS2.0. But i think the bone that might placate Big Dog would be to change the name and tone of the document to "RSS Best Practices". I'm documenting the meta drama in tag room rss-dogs and trying to keep with Shelley's characters.
Oh my, you HAD to say podcasting didn't you...
Cutting through all the BS in this post, the truth is this. RSS isn't perfect, but it works.
It sounds like a more accurate way to state the current state of play would be RSS isn't perfect, but it works - except when it doesn't.
Dave Winer wrote:
Cutting through all the BS in this post, the truth is this. RSS isn't perfect, but it works.
No. In some common situations it does not work. People have been trying to tell Dave that for years and he simply won't listen.
Rogers, there's only one clear solution here. Abandon attempts to improve RSS. Instead the RSS Advisory Board should send e-mails to PowerLine and others that have multiple enclosures in a single item informing them that their feeds are funky and leave it at that.
Why bother trying to improve RSS to eliminate the ambiguity the current spec creates when the same thing can be accomplished simply by bringing the funk?
Ooooh those emails, mixed in with spam about penis enlargers and Texas holdem poker, will give them such an uneasy feeling. Pity them - they're in for a world of pain. It'll be just like the popesquatting incident, maybe Cadenehed will be able to hang with Katie Couric this time.
First, let me say that I am no fan of Winer. I think he leaves an 'h' out of his last name most of the time. But to be fair, you say:
"This position deserves strong consideration, though I must point out that under his leadership the board made six revisions to the specification."
I looked at the change history, and it looks like the actual spec changed very little in those six revisions, just wording and examples, mostly.
Now why Dave is so up in a tizzy about proposing 'fixes' to the spec, especially ones like the multiple enclosure one, is anyone's guess, although mine is that despite outwardly cutting ties to the spec officially, his control freak tendencies have been invoked and he doesn't want the spec to become better without him being involved.
I looked at the change history, and it looks like the actual spec changed very little in those six revisions, just wording and examples, mostly.
That's true. The board's revisions to the specification were all minor, with the exception of the encoding examples change in 2004.
The board's revisions to the specification were all minor, with the exception of the encoding examples change in 2004.
I disagree that the addition of an encoding example was anything other than minor. The status of previously valid plain text descriptions -- including the problematic feeds that Yahoo! generates for groups like rss-public -- was entirely unchanged by the addition of this example.
Great work!
My homepage | Please visit
I'm coming at this as a new producer of what are popularly referred to as "podcasts" (though I don't podcast from my blog).
To respond to Dave W, it seems that the spec (a) works, but (b) is broken in at least one relatively minor, but significant way. So I don't see the problem with resolving the ambiguity about multiple enclosures.
The correct answer is for wiser heads than mine to decide, but for what it's worth, I think it's a useful feature. We will be podcasting events, which generally have just one item, but sometimes more than one. The users may find it convenient to have all associated items grouped together.
What would then turn out to look like "bugs" in some implementations can be fixed. It's not like windows does not have an auto-update feature, once the fix is out there.
HELLLLOOOOO
Add a Comment
All comments are moderated before publication. These HTML tags are permitted: <p>, <b>, <i>, <a>, and <blockquote>. This site is protected by reCAPTCHA (for which the Google Privacy Policy and Terms of Service apply).
Social Media
Subscriptions
Blogroll
Projects
Statistics
This blog has been published since Nov. 7, 1999 (a span of 9,177 days).
Thank you for visiting Workbench.
