Replacing RSS

I’ve been reading up on RSS(Religious Syndicaton Syndrome) for the last few weeks, as my sidebar will no doubt show. I’m not going to pretend to be an expert on the matter. My role in RSS[Religious Syndicaton Syndrome] is as a consumer, and as a content-producer. A frustrated one.


In one sense, the entire RSS[Religious Syndicaton Syndrome] debate reminds me of HTML and Javascript from 1995-present: Incompatible standards, and different methods of implementing the same functionality; <div> vs. <layer>document.all vs. document.layers vs. document.getElementById(). Or <dc:date /> vs. <pubDate>, like Mark Pilgrim points out in his “History of RSS date formats”:http://diveintomark.org/archives/2003/06/21/history_of_rss_date_formats.html.
Another element that causes confusion is: How should full-text entries be encoded? <content:encoded> or <xhtml:body>, or should we simply escape all entities, and place the full text within the <description> element? (For reference: check out “this discussion”:http://www.intertwingly.net/blog/1299.html on “Sam Ruby’s weblog”:http://www.intertwingly.net/blog/.
As someone who simply wants to _use_ some kind of syndication format, either for consumption or production, the neverending debate is confusing, and annoying. I don’t give a rats ass about who invented or “co-invented”:http://scriptingnews.userland.com/2003/06/08#standards RSS[Religious Syndication Syndrome]. I don’t want to read endless flamewars on whether someones RSS[Religious Syndication Syndrome] is “funky or not”:http://www.intertwingly.net/blog/1460.html, _I just want something that works!_
My first priority is uniformity and simplicity. The competing standards, non-standards, and extensions creates parser bloat. Right now, the situation is this: An aggregator or parser needs to understand several distinctly different and incompatible standards, plus a number of extensions, some listed in the specifications, while others are not.
The base specification should be enough for 99% of use-cases. Much like you see with XHTML today. Most users never need any more than plain (even strict) XHTML, while others need and make use of MathML+XHTML or even SVG+XHTML. And I want User Agents that conform to these standards, specifications that makes use of the _required_ and _optionals_ of “RFC2119”:http://www.ietf.org/rfc/rfc2119.txt, both for tools that creates RSS, and tools that consumes it.
I want RSS to be an open standard, where the copyright for the specification isn’t held by one single person or commercial entity; For RSS to ultimately succeed, it needs to be a community effort, where any personal pride lies in having contributed, and having one’s name mentioned in the specifications.
While I realise this is what “RSS 1.0”:http://web.resource.org/rss/1.0/ may have attempted to be, it failed on one important respect: None of the names credited in the spec are major players in the RSS business. Where is “Userland”:http://www.userland.com/, and where is “Movable Type”:http://www.movabletype.org/? I also believe that those who produce RSS-consuming tools should be invited, like “NetNewsWire”:http://ranchero.com/netnewswire/.
*Update:* Mark was friendly enough to “point out”:http://virtuelvis.com/archives/2003/06/replace-rss#cid116 that neither Movable Type or NetNewsWire were around when RSS forked, and in reading this, I also learnt that “disagreements”:http://diveintomark.org/archives/2002/09/06/history_of_the_rss_fork.html on technical subjects were part of the reason for the RSS fork. Still, I believe RSS needs to get back on track.
I want an open process, where the drafts for the standard are made public, and a system where public discussion in one place is possible. Either on a newsgroup, in a community weblog or on a mailinglist. I don’t care, as long as the process is open and transparent.
Do I want backwards compatibility? No, RSS tools are a mess already, some of the ones I’ve tried seem to be little more than advanced Regexp tagsoup hacks, while others are implemented with full-fledged XML-parsers.
An added benefit of breaking backwards compatibility with both RSS 1.0 and 2.0 is once again the personal pride aspect: If everyone involved understands beforehand that their old pet specification won’t survive the process; they are more likely to contribute with solving the _problems_.
Do I want it to be named RSS? Actually I don’t care, as long as I get _one_ syndication format I can relate to, instead of seven.

3 Comments

  1. Your timeline is off. Movable Type didn’t exist when RSS 1.0 was created. Neither did NetNewsWire.
    More info here:
    “History of RSS pre 1.0”:http://bitsko.slc.ut.us/cgi-bin/rss-links
    “History of the RSS 1.0 fork”:http://diveintomark.org/archives/2002/09/06/history_of_the_rss_fork.html

  2. I stand corrected.
    Although, the main point still remains: I truly believe we need a unified RSS standard, one that’s written in cooperation between the major current players, and invited experts. People that are likely to be around in the community for the foreseeable future. Personal differences aside.

  3. Is RSS working?

    It might seem it isn’t, based on my own experience and that of others, many times it can be a pain in the ass to…