Dave Winer: The road to RSS 2.0.
Change the title of the spec to RSS 2.0. Do a search for 0.94 and replace with 2.0.
… Namespace support is no longer in the future, the core of RSS is frozen, no features are deprecated (explain why), there may be a 2.01 and 2.02, for the purpose of clarification, but no new core elements are anticipated.
I (and others) feel that RSS 2.0 is the perfect opportunity to deprecate some existing elements in the core namespace of RSS 0.94. I await Dave’s explanation on why he feels no features should be deprecated. In the meantime, here are some thoughts on the matter:
Sam Ruby: RSS Progress and a big missed opportunity.
RSS 0.94 added a number of elements without consideration as to what possibilities were out there once namespaces were added. Now it looks like namespaces will be added.
What RSS 2.0 needs now is a focus on simplicity and some serious deprecation. Strip it to the core. Then have two modes (just like HTML does)… a transitional mode which allows anybody to add any element they wish with or without namespaces, including the classic 0.91 ones like skipHours and the proposed 0.94 ones. And a strict mode in which the only additions permitted are ones that reside in namespaces.
Sjoerd Visscher: The future of RSS.
Modules are just perfect for the next step in RSS use. And there’s no burdon of the crippled syntax of RDF. There’s no doubt in my mind that this is the way to go. But then there remains the issue of putting some of the old elements in modules.
Imagine a core RSS of these elements: rss, channel with title, link, description and language, and item with title, link and description. This is a core which you can’t touch, because most older RSS implementations use these. This is also a core that’s very useful and a low barrier to implement. The other elements should be grouped in modules, using namespaces. I believe that applications that use these elements are in active development, and can be easily changed. This requires some effort from implementors, but the result is a clean future-compatible RSS basis, that can remain popular as long as XML remains popular.
Rael Dornfest: RSS: Let a 1,000 flowers bloom, and all that
I genuinely like — as I always have — RSS 0.9x style simple XML syntax with room for expansion via XML-namespace based modularization. And I’d love to see it in RSS 0.94.
Do I wish we could go back to 0.91 and further, moving all those imperfect elements into namespaces? Why sure. Who wouldn’t? But the sheer number of tools and applications that rely upon what’s in there (for better or for worse) makes that impossible — not without considerable breakage and retooling. Am I content to have that simply be optional water under the bridge? Sure thing.
That said, I am concerned to see last minute stuffing of the core with elements that have yet to prove their worth. Of course they’re all optional again, but that’s just so much more baggage (remember skipHours?) to carry around. When the idea has been put forth to go the route of XML-Namespaces, why clutter a room with boxes from the basement just before building a shelving unit. Would I like to see those elements pushed out into namespaces? Sure thing. More toothpaste out of the tube? No more than some of the fiddling with RSS autodiscovery in its first few days of existence.
Leigh Dodds: RE: [RSS-DEV] Time to move along?
Lets keep the core of RSS lean and mean, but assign it a namespace. None of the work on RSS modules needs to be jettisoned and will instantly be available to people moving up from 0.92/0.93, etc.
Ian Davis: Re: [RSS-DEV] Time to move along? #2
I agree wholeheartedly with this. My preference is to have the simplest possible, extensible format for syndicating news headlines and content. That means items with title, description, link and date and very little else. Restrict the description and title to be text only and make use of the content module to embed entire stories if required.
For the record, this is also how I envisioned RSS 2.0:
Also note that there are absolutely no additions to the core namespace (compared to the basic example above). You get a channel element which contains a series of item elements, each of which can have a title, link, and description (all of which are plain text, no encoded HTML). Everything else is handled by RSS modules which already exist. Full HTML posts are included with mod_content. Dates (including item-level dates) are included with Dublin Core. Contact information is included with mod_admin. Information about how often aggregators should poll is included with mod_syndication. Your feed can be as rich as you want. If your news aggregator supports the extra metadata, great; if it only supports the basic title-link-description, well, you’ve got that too.
