This post originated from an RSS feed registered with Java Buzz
by Bill de hÓra.
Original Post: Apples and Oranges
Feed Title: Bill de hÓra
Feed URL: http://www.dehora.net/journal/atom.xml
Feed Description: FD85 1117 1888 1681 7689 B5DF E696 885C 20D8 21F8
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, 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. Oranges 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. Apples 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....
Previous Topic
