« More database type switching | Main | Automated mapping between RDF and forms, part I »

Apples and Oranges

It seems that Dare Obasanjo thinks there are two ways to support podcasts in Atom and one in RSS2.0. He's incorrect in his analysis I disagree with his analysis, which goes as follows:

  • Atom for podcasts - use an atom:link whose @rel type is 'enclosure' to link to an audio file. Or use an atom:content whose type attribute is audio/mpeg (or some such media type value) and which links to an audio file.
  • RSS2.0 for podcasts - use rss2:enclosure whose type attribute is audio/mpeg (or some such media type value) and which links to an audio file.


But, RSS2.0 also allows you to link to an an audio 'podcast' with rss2:link element. That would be similar in spirit to the atom:content way of doing it, insofar as it's not the spirit of either spec to link to audio files for such purposes, else neither would offer syntax for enclosures. As we're navel-gazing on the specs here rather than looking at what anyone actually does, the only interesting difference viz. podcasting is the fact that atom:link and atom:content both allow media type declarations as metadata. Whereas only rss2:enclosure allows the media type to be set and the rss2:link with its absence will defer to the media type set in the HTTP response. Some of this also comes down to conflating "podcasting" with "enclosures" with "links", which though it makes conversational sense to avoid such pendantry, in the way "AJAX" and "Web2.0" makes broad conversational sense, it is wooly thinking technically.

The conclusions I draw from this are:

  • Atom and RSS2.0 don't support "podcasting". Technically speaking, "podcasting" is about as meaningful here as "Web2.0" or "AJAX".
  • Atom and RSS2.0 support the notion of an enclosure, which is the basis for most "podcasting" functionality. Mixing up enclosures and podcasting is a mistake - it doesn't neccessarily make sense to limit enclosure functionality to podcasting.
  • Atom and RSS2.0 have the notion of a link, which could be used to support linking to audio and other non-textual media. Mixing up enclosures and linking is a mistake - it's probably easier to dispatch functionality for something like podcasting when you hang the data of an enclosure structure.
  • Irrespective of how podcasting is to be enabled, RSS aggregators need to figure what to do for audio/visual media types coming in via links, which might include doing nothing and deferring dispatch responsibility to the embedded browser/renderer control.


To add some flavour, Apple has published a spec for enabling podcasting via RSS2.0. It's specifically targeted at the iTunes application, and can be described as an RSS2.0 extension for that purpose. I think it would be weasel-worded to describe this as a 2nd (or even 3rd) way for RSS2.0 to support podcasting, even though it is more closely aligned with that kind of functionality than an rss2:link. It's more of an application-specific extension for iTunes.

As an extension it could be supported by any software that supported RSS2.0. More interesting, there is of nothing to stop this iTunes extension being published via Atom or any other syndication format, making it a kind of feed-agnostic vendor-specific microprotocol. I personally expect to see more of these as a function of the markets enabled by more generic innovations, such as enclosures.

August 15, 2005 12:08 PM


Dare Obasanjo
(August 15, 2005 01:16 PM #)

An aggregator author has to figure out the user experience when a link with rel="enclosure" is encountered and an entry with src="someurl" is as well. Besides causing unnecessary complexity for myself and our end users, I don't see why I should try and come up with some 'slightly different' user experience to differentiate between both mechanisms for distributing binary content in Atom.

I'm sure a philosophical debate on the difference between enclosures and podcasts would be fun but I'll have to pass on that one.

Bill de hOra
(August 15, 2005 01:49 PM #)

"I'm sure a philosophical debate on the difference between enclosures and podcasts would be fun but I'll have to pass on that one."

You can call it philosophical, but it ain't so. Confusing the enclosures with podcasts is like confusing CDs with songs. Enclosures are a geek mechanism, podcasts are a cool feature.

Dare Obasanjo
(August 15, 2005 03:13 PM #)


I'd forgotten how much XML syndication geeks like to split hairs over semantics. As an aggregator author I care about podcasts and the mechanism for getting them from feeds is via enclosures.

An MP3 file attached to an entry is a podcast. Arguing that in some situations it is an 'enclosure' and in others it is a 'podcast' is a foolish argument that I want no part of.

Robert Sayre
(August 15, 2005 03:45 PM #)

I downloaded the latest RSSBandit to see what the kerfuffle is about. I can see why Dare wants to treat them identically--he just links them up. That's a perfectly legit way to do it.

That said, I always thought podcasting is when the aggregator downloads things automatically so the user can enjoy them timeshifted with no waiting, if a connection is present at all. Atom link rel=enclosures are used to call out such content... "special handling" is how the spec puts it.

(August 15, 2005 06:23 PM #)

iTunes Atom support is still evolving, apparently, due to a limited number of real-world feeds to test against.

Dare Obasanjo
(August 15, 2005 07:11 PM #)

Currently they are treated as links. What I am working on is the "aggregator downloads things automatically so the user can enjoy them timeshifted with no waiting" bit. I plan to do this for both link rel=enclosure and content src=someurl.

In his post Bill is claiming that I am "incorrect in my analysis". If so, I'm open to a correction in my analysis that describes how to represent the difference between content by reference and Atom enclosures in the user interface of RSS Bandit that will be clear to end users as well as what the tangible end user benefit of this actually would be.

Bill de hOra
(August 15, 2005 09:31 PM #)

Dare, I think (as a sometimes Bandit user) if you want to do the "timeshifted with no waiting" thing, then that should happen when the code sees "//enclosure'" or "//atom:link[@rel='enclosure']" patterns and switches on those. Not anything else.

All technical geekery aside, I'm not sure you need to support behavour beyond that from the user side. If it's declared as linked atom:content @src, let the browser controls deal with it. If somebody wants me to see it as a podcast they should have said so. I might as well be digging through inlined content for links ending in mp3/wma/whatever for podcasts as treating //atom:content/@src pattern values ending in mp3/wma/whatever as podcasty-timeshifted-with-no waiting-things. never mind having to GET/HEAD to check for the media type. Whatever about being a a pita to implement, as a user the application is being too 'clever' at that point.

Open issues then are 1) you see an atom:content element with a @src *and* a @rel='enclosure' directive, and, 2) you see an atom:link without @rel='enclosure' but with a URI that maps to an audio file or some other medium. The latter is sniffing URIs/media types (cleverness). For the former, the Atom spec leaves that combination undefined insofar as there's nothing that says a publisher can't emit such and @rel atttributes/values are only articulated on for certain elements. I might run that cases by the atom-syntax list, but my opinion atm is that "podcasts" are only implied by an enclosure mechanism.

As it's (arguably) as much a matter of opinion than fact, I changed the leader to say I disagree with you, rather than you being incorrect.

Robert Sayre
(August 15, 2005 10:46 PM #)


I'm currently looking at the same situation in Thunderbird (I write most of the RSS/Atom/OPML code these days). While I don't think there are any plans to support true podcasting features in the next version, there may be in the future. The app does support "remote content", and currently lumps enclosures in there (similar to what RSSBandit currently does). If podcasting support does happen in the future, I'll recommend against supporting podcasting with content:item, atom:content, and other such things.

My opinion, and my recommendation to the Thunderbird drivers, is that it's possible to treat enclosures as another content element, but it's not wise to implement podcasting features with all "content" elements.

Post a comment

(you may use HTML tags for style)

Remember Me?

Trackback Pings

TrackBack URL for this entry: