December 22, 2004
@ 05:27 PM

It seems there's been some recent hubbub in the world of podcasting about how to attach multiple binary files to a single post in an RSS feed In a post entitled Multiple-enclosures on RSS items? Dave Winer weighs in on the issue. He writes

This question comes up from time to time, and I've resisted answering it directly, thinking that anyone who really read the spec would come to the conclusion that RSS allows zero or one enclosures per item, and no more. The same is true for all other sub-elements of item, except category, where multiple elements are explicitly allowed. The spec refers to "the enclosure" in the singular. Regardless, some people persist in thinking that you may have more than one enclosure per item.

Okay, let's play it out. So if I have more than one enclosure per item, how do I specify the publication date for each enclosure? How do I specify the title, author, a link to comments, a description perhaps, or a guid? The people who want multiple enclosures suggest schemes that are so complicated that they're reduced to hand-waving before they get to the spec, which I would love to read, if it could be written. Some times some things are just too hard to do. This is one of them.

And there's a reason why it's too hard. Because you're throwing out the value of RSS and then trying to figure out how to bring it back. There's no need for items any more, so you might as well get rid of them. At the top level of channel would be a series of enclosures, and then underneath each enclosure, all the meta-data. Voila, problem solved. Only what have you actually solved? You've just re-created RSS, but instead of calling the main elements "item" we now call them "enclosure".

The value of RSS is fairly self evident to me but it seems that given the amount of people who keep wanting to reinvent the wheel it may not be as clear to others. As someone who used to work on core XML technologies at Microsoft, the value of XML was obvious to me. It allowed developers to agree to use the same data format for information interchange which led to a proliferation of a wide and uniform set of tools for working with data formats. XML is not an optimal format for most of the tasks it is used for but it more than makes up for this with the plethora of tools and technologies that exist for processing XML.  

My expectation about XML was always that the software industry would move on to agreeing on other higher level protocols built on XML for application information interchange. So I've always been frustrated to see many attempts by various parties, including the W3C with efforts such as XML 1.1 and binary XML, take us steps back by wanting to fragment the interoperability promise of XML.

RSS is a wonderful example of the higher level of interoperability that can be built upon XML formats. Instead of information sources using various incompatible mechanisms for providing information to end users such as NOAA's SOAP web service and the web services which each require a separate custom application to consume them, sites can all standardize on RSS. This standardization creates an ecosystem of applications that produce and consume RSS feeds which is a lot larger than what would exist for each site specific web services or market specific XML syndication formats.  Specifically, it allows for the evolution of the digital information hub where users can view data from the various information sources they care about (blogs, news, weather reports, etc) in their choice of applications. 

Additionally, RSS is extensible. This means that even if the core elements and attributes do not satisfy all the requirements of a particular problem domain, then domain-specific information can be added to the feed. This allows for regular consumers of RSS to still be able to consume the content while domain specific applications can give users a richer experience. This is a much better solution for both content producers and consumers than coming up with domain specific applications.

As a user I want less formats not more. I want my email to come in my RSS aggregator, I want my favorite newsgroups to show up in my RSS aggregator, I'm tired of having a separate application for what is essentially the same kind of data. In fact, it seems Google agrees with me as evidenced by them exposing XML feeds for your GMail inbox and for USENET newsgroups via Google Groups. Unfortunately, if you have a plain old RSS reader, you can't view these feeds and instead have to find an aggregator that supports Atom 0.3. Two steps forward, one step back.

We need less data interchange formats not more. It is better for content producers, better for end users and better for developers of applications that use these formats. Existing problems in syndication should focus on how to make the existing formats work for us instead of inventing new formats. 

Vive la RSS. 


Wednesday, December 22, 2004 6:02:16 PM (GMT Standard Time, UTC+00:00)
Ooo look. FUD!
Wednesday, December 22, 2004 8:10:51 PM (GMT Standard Time, UTC+00:00)
Another brilliant essay from Dare.
Sunday, December 26, 2004 10:58:42 AM (GMT Standard Time, UTC+00:00)
As a user I don't care about formats. As a developer, I want less formats, not more. But the design of RSS 2.0 is such that extensions are entirely domain-specific (aside from following XML+namespaces), there are no clear hooks for the extendor to refer to in RSS 2.0. This means in effect that extensions are equivalent to additional formats, only the the data appears inline in the feed. Not much benefit in terms of interoperability.

What RSS 1.0 has is a higher-level language in which extensions can be described. There are hooks in the form of URIs and the RDF/XML structure. Atom looks like it will have similar hooks, though without the higher-level language (beyond simple identification and relationships). If you're looking for minimising the variety of exchange formats, RSS 2.0 is not the best place to start. But it really doesn't matter - the domain model is essentially the same across syndication whatever the syntax. So all that's needed is a little syntax transformation. It's easy enough to view RSS 2.0 as an RDF syntax, and get the benefits of the model. Ok, every extension will need its own specific handling, but that's unavoidable no matter what you want to do with the stuff, there is no common semantics for extending RSS 2.0. But because of the shared domain model, there doesn't have to be a conflict between RSS 1.0, 2.0 and Atom, any more than there is a conflict between Windows 95 and Windows XP.

Is RSS Bandit a "plain old RSS reader"? That, and virtually every other even half-decent aggregator I've seen supports not only all the varieties of RSS 0.9x, RSS 2.0 but also RSS 1.0 and Atom. What matters is the information, the syntax in which it is conveyed is of secondary significance. As someone who used to work on core XML technologies at Microsoft I would have thought you would have been aware of XSLT...

Vive le RSS, certainly, but also vive le Atom, vive le syndication and vive le Web.

Sunday, December 26, 2004 12:49:58 PM (GMT Standard Time, UTC+00:00)
I think it shows the shortsightedness of a developer to look at an increasing proliferation of syndication formats as not a big deal since the code to write parsers for them isn't that huge [for now]. If MSN Spaces decided to shut off RSS feeds and switch on CDF feeds, would you also feel the same way? This is basically what Google did with RSS. Do you think aggregator developers or users would be happy about this? For all the hype, XML syndication is still a niche technology and the efforts to fragment it before it can go mainstream are unhealthy.

PS: I have always been confused about why you are interested in Atom. All the scenarios you keep harping about can be satisfied with RSS 1.0 today. I don't see how a third syndication format that isn't RDF-based and isn't as simple as Dave Winer's family of specs buys you anything except extra padding for your upcoming book.
Monday, December 27, 2004 1:24:55 AM (GMT Standard Time, UTC+00:00)
"If MSN Spaces decided to shut off RSS feeds and switch on CDF feeds, would you also feel the same way? This is basically what Google did with RSS."

Trade one proprietary format for another? I don't really see the comparison.

You harp on about how Atom shouldn't exist, but plenty of other aggregator developers spring for the Atom feed whenever they get the chance. Quote: "I don't care what you do, as long as you keep the Atom feed, because Atom is so much better than RSS." The person who wrote that is the author of an aggregator that will ship more copies than most others next year. You can contact me privately if you want to know who wrote it and/or bite my head off.

It seems like your real beef is with standards organizations themselves. Truthfully, they probably just get in Microsoft's way, but they help companies who aren't monopolies.
Monday, December 27, 2004 2:14:49 AM (GMT Standard Time, UTC+00:00)
You amuse me. Your persecution complex seems to be getting the better of you. My post was about people who want to replace RSS for podcasting, with a throwaway comment about Atom. My opinions about Atom have been the same for the past year or so; it's going to exist since it has inertia, aggregators will have to support it and there's little justification for its existence.

This opinion is uniform for all XML syndication formats for the World Wide Web that aren't RSS 0.91/2.0 or RSS 1.0.

PS: Please, take your personal battles with Dave Winer elsewhere. I'm not interested.
Monday, December 27, 2004 2:25:41 AM (GMT Standard Time, UTC+00:00)
It's just that there's this vast conspiracy out to get me!

P.S. -- I don't have any personal battle with Dave. I've barely communicated with him.
Friday, December 31, 2004 11:31:19 AM (GMT Standard Time, UTC+00:00)
At a guess I've written maybe 9 or 10 different aggregator front-ends (different approaches, different languages) and have looked at quite a few more written by other people. I don't it would take more than an hour in any of them to make the necessary adjustments if MSN Spaces went to CDF.

This is assuming only core RSS is used, so effectively there's a common domain model. The difficult bits I've encountered have been in the extensions, where there *isn't* a common model. Which is why I harp on about the need for useful extensibility so much.

Re. supporting Atom - yes, RSS 1.0 pretty much does everything I'd want (though it could use a few tweaks). But I can't see everyone moving to this in the foreseeable future, and RSS 2.0 doesn't do everything I want - aside from the extensibility issue there's all the hassle of figuring how many times to escape content, and general underspecification (how many enclosures elements?).

Generally speaking, from an RDF viewpoint the syntax is of secondary importance. XSLT isn't particularly costly, and it's not difficult to support custom XML formats programmatically (e.g. Redland can read RSS 2.0/tag soup).

If syndication tools used RSS 1.0 throughout it would make RDF folks' life a lot easier, but the key is there being a clear domain model through which to interpret the data. i.e. a decent spec. That's my main technical reason for supporting Atom over RSS 2.0. There's also the small matter of having to use a completely different system for authoring (XML-RPC, Blogger API, Metaweblog APIs) than for publishing (HTTP+RSS).

Politically, there is a better chance of there being developer consensus on Atom than either RSS 1.0 or 2.0. Having the development done through a proper standards org makes a lot of difference too.

Don't forget software changes and evolves. What is the path forward for RSS 2.0 when the spec is frozen? It wasn't people from the RDF community burst out of RSS 2.0, it was people that were using RSS 2.0 that had hit its limitations.

btw, Atom certainly didn't provide padding for the book, it was actually a bit of a nightmare because of the moving target. It would have been far, far easier to have written solely about RSS 2.0.
Comments are closed.