Why are you doing this? RSS is over five years old. It was designed for news sites, a way for them to list the stories they had. Things are different now, and RSS is mostly used as a way of sending around the content of weblogs. RSS has been kludged and pushed into this world, but it doesn't really fit.
This isn't just a theoretical problem; there are real interoperability issues. Take a title like "<a good story>". Some tools, like RadioUserland, will treat this title as the beginning of the link and it won't show up at all. Some, like NetNewsWire, will assume that it's a bit of HTML left in by accident and strip it. Some will treat it as the exact title and display it properly. Who's doing the right thing? The spec doesn't say.
So let's change the spec. The problem is that Dave Winer has declared RSS 2.0 the last version of RSS. We could write guidelines and recommendations but we'd be always be hobbled by the fact that the actual spec is untouchable.
Oh, so it's all about personalities, is that it? You guys just don't like Dave Winer? Not at all! The fact is that Dave Winer has asked us not to create a new version of RSS, and we plan to respect his wishes.
Well, let's extend RSS into a new spec then. To keep any backwards-compatibility, we'd have to keep the top-level element as <rss> so people would think the format is actually RSS, and this would be really confusing.
Forget about backwards-compatibility. If we're not worried about backwards-compatibility, why are we bothering to keep around the old mistakes of RSS? Why not take this opportunity to fix them so that the future doesn't have to deal with all the kludges necessary to parse RSS today?
You're just throwing away all the investment in RSS? Not at all! Software will continue to support RSS for a long time to come, I expect. But that's the software's job, not the specification's. Nobody's throwing away the past here, we're just working on improving the future.
In other words, you're building a better RSS. Well, what we're doing isn't just a replacement for RSS -- it's also a chance to unify the blogging formats. Now, if you want to build a weblog tool like NetNewsWire that can both read and write weblogs, you need to know a variety of different formats and protocols: HTTP, XML-RPC, RSS 0.9, RSS 0.91, RSS 0.92, RSS 1.0, RSS 2.0, the Blogger API, the MetaWeblog API, the new Blogger API, etc. We'd like to make this just one format (Atom) and one protocol (HTTP).
Simplicity and bug-fixing is nice, but do you have any actual benefits over what's there now? Yes! We've got support for blog entries in multiple languages and formats, machine-readable information about authors, etc. And our weblog editing system will be fully extensible, so that editors can take advantage of non-standard additions (like Movable Type's Excerpt and Format features) without resorting to proprietary protocols or additional calls. The result is a user experience that's faster, more featureful, and less bugprone.
Wow, sounds pretty good. Wait a second, I thought this was all about politics. There are some politics involved, of course. The hope is that bringing the various people involved in weblog tools together to work on this project will help us push aside our differences and provide a solid way to move forward and continue making weblogs better.
Well, you've got me convinced. But I guess that's to be expected since I'm your literary foil. Yeah, I guess it is. If there are any real skeptics out there, post your questions below and I'll try to answer them.
Six Apart: Why We Need Echo
Raw Blog: The Principle of Sufficient Irritation
Why a conceptual model of a log entry?
We want a weblog authoring tool to be able to post log entries to all sort of weblog engines. Prerequisites:
common API to the weblog engine
common markup for the entries
common meta information such as author, time, place, etc.
We want to read weblogs using a variety of means, including various transformations by software. Prerequisites:
standard output formats such as RSS with a specified list of optional well-defined modules (and plain HTML, of course)
common API if the queries are allowed (eg. all log entries in a specific time period)
These are the points the discussion should focus on.
Moved to MotivationDiscussion