A new RSS?

Sam Ruby is collecting ideas for a new weblog data format. [via Scripting News]

I see some pros and cons to this effort.

Cons: RSS is already well established. It is simple, easy to implement and understand. In other words, done properly (which isn’t hard to do) it just works. I whacked together an RSS feed from a database in an hours or so – and it worked in aggregators straight up. I don’t think (particularly with RSS 2.0) that there is a significantly better mouse-trap. (I’m sure others disagree)

Pros: Ever since I first looked at RSS I couldn’t work out why auther and publication date of the individual entries were not included (not that I could see anyway). There were other annoyances, but that was the main one. It basically meant that RSS couldn’t be used for multi-author news. This didn’t make sense. However, (and that’s a big however), these gripes were fixed in RSS 2.0.

IMHO, weblog tools that include standard HTML as content in item and description elements shouldn’t – it should be well-formed XHTML. But this fact doesn’t seem to bother most RSS aggregators and other tools.

Looking quickly (read: skimming /really/ fast) at the WIKI for what the effort is discussing, this looks like it’s going to be another SOAP – really hard to use and understand. It looks as though it’s going to incorporate attachments and all sorts of cruft that make it hard to get up and running without pre-built libraries and a couple of weeks to get your head around the concepts.

But this is probably jumping the gun a little. As Sam states: “At the present time, I would like limit the scope of this wiki to describing a conceptual data model of what constitutes a well formed log entry.”

Maybe they’ll come to the conclusion that RSS 2.0 kinda does that, maybe they won’t…

One thought on “A new RSS?

  1. I think your comments are premature. I think that once we get down to physical modelling, you’ll be surprised how simple the required core is, and how well-designed the optional application-specific extensions are.

    BTW, the driving force behind this format is stated clearly here:


    * 100% vendor neutral. RSS isn’t.
    * implemented by everybody. RSS isn’t. There are 7 versions ( http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html ) and everybody implements them differently.
    * freely extensible by everybody. RSS is in theory, isn’t in practice. cf: “funky RSS”.
    * cleanly and thoroughly specified. RSS isn’t. Can title contain HTML markup? (This was mentioned on Scripting News recently; Dave’s initial answer was “well, the spec doesn’t specify, so who am I to say you can and can’t do?” Damn it, you’re the spec author! It’s your job to tell me what I can and can’t do!) If a feed contains pubDate and dc:date, which one takes precedence? It a feed contains link and guid, which one takes precedence? (NYT feeds do this, and they’re different.) What language codes are allowed? (The spec points to a severely outdated list.) And so forth.

    RSS is underspecified in several small but important ways, and this hurts implementators on all sides. Dave has simultaneously asserted himself as the sole gatekeeper of RSS, yet shown zero interest in maintaining it.

Comments are closed.