Today I was working on completing the support for Atom 1.0 in the next version of RSS Bandit and decided to make the changes for parsing out enclosure/podcast elements while I was in that part of the code. RSS 2.0 is pretty straightforward, there is an <enclosure> element that is a child of the <item> element.

On the other hand, the Atom 1.0 specification has two completely different mechanisms for creating podcasts. Both mechanisms are described in the article by James Snell entitled An overview of the Atom 1.0 Syndication Format. From the article

Support for enclosures

Listing 4. Atom 1.0 podcasting example

						
								
										       
<feed xmlns="http://www.w3.org/2005/Atom">
  <id>http://www.example.org/myfeed</id>
  <title>My Podcast Feed</title>
  <updated>2005-07-15T12:00:00Z</updated>
  <author>
    <name>James M Snell</name>
  </author>
  <link href="http://example.org" />
  <link rel="self" href="http://example.org/myfeed" />
  <entry>
    <id>http://www.example.org/entries/1</id>
    <title>Atom 1.0</title>
    <updated>2005-07-15T12:00:00Z</updated>
    <link href="http://www.example.org/entries/1" />
    <summary>An overview of Atom 1.0</summary>
    <link rel="enclosure" 
          type="audio/mpeg"
          title="MP3"
          href="http://www.example.org/myaudiofile.mp3"
          length="1234" />
										
												
														  <link rel="enclosure"
          type="application/x-bittorrent"
          title="BitTorrent"
          href="http://www.example.org/myaudiofile.torrent"
          length="1234" />
												
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <h1>Show Notes</h1>
        <ul>
          <li>00:01:00 -- Introduction</li>
          <li>00:15:00 -- Talking about Atom 1.0</li>
          <li>00:30:00 -- Wrapping up</li>
        </ul>
      </div>
    </content>
  </entry>
</feed>
								
						
				

Atom enclosures allow you to do more than just distribute audio content. Enclosure links can reference any type of resource. Listing 5, for instance, uses multiple enclosures within a single entry to reference translated versions of a single PDF document that's accessible through FTP. The hreflang attribute identifies the language that each PDF document has been translated into.

Content-by-reference

In addition to support for links and enclosures, Atom introduces the ability to reference entry content by URI. Listing 6, for instance, illustrates how an Atom feed for a photo weblog might appear. The content element references each individual photograph in the blog. The summary element provides a caption for the image.


Listing 6. A simple list of images using Atom 1.0

						
								
										        
<feed xmlns="http://www.w3.org/2005/Atom"
      xml:base="http://www.example.org/">
  <id>http://www.example.org/pictures</id>
  <title>My Picture Gallery</title>
  <updated>2005-07-15T12:00:00Z</updated>
  <author>
    <name>James M Snell</name>
  </author>
  <entry>
     <id>http://www.example.org/entries/1</id>
     <title>Trip to San Francisco</title>
     <link href="/entries/1" />
     <updated>2005-07-15T12:00:00Z</updated>
     <summary>A picture of my hotel room in San Francisco</summary>
     <content type="image/png" src="/mypng1.png" />
  </entry>
  <entry>
    <id>http://www.example.org/entries/2</id>
    <title>My new car</title>
    <link href="/entries/2" />
    <updated>2005-07-15T12:00:00Z</updated>
    <summary>A picture of my new car</summary>
    <content type="image/png" src="/mypng2.png" />
  </entry>
</feed>
								
						
				

This content-by-reference mechanism provides a very flexible means of expanding the types of content that one can syndicate through Atom.

After looking at this from all angles for about 30 minutes the only conclusion I can come to is that Atom provided two completely different mechanisms of achieving the same goal. This is likely a potential gotcha for aggregator authors who might end up supporting one or the other of the mechanisms instead of both.

After this, I still have to add some code to also support Yahoo! Media RSS and then track down some feeds that actually use all the various enclosure techniques so I can test my code with actual real world scenarios. I'd appreciate any pointers to test feeds especially for the Yahoo! Media extensions to RSS [which I'm considering not supporting if there aren't that many feeds that use it].

No rest for the wicked. ;)


 

Monday, 15 August 2005 03:00:47 (GMT Daylight Time, UTC+01:00)
Hey Dare,

IMHO, podcasting with Atom should only ever be done using the enclosure link. That's why the enclosure link exists. You could achieve the goal using content-by-reference but on the same thought, you could also achieve the same goal in RSS using the link element.

Besides, using the enclosure link mechanism gives you much greater flexibility for linking to multiple formats (e.g. my MP3 and BitTorrent example), for linking to mirrors, for providing downloads in multiple languages, etc... none of which you can achieve easily with the content-by-reference mechanism.

I'll write up some of these thoughts in a detailed post on my blog in the coming day or so.

Thanks for looking at this!
Monday, 15 August 2005 03:10:37 (GMT Daylight Time, UTC+01:00)
James,
The point is that as an aggregator if I see content-by-reference I'm going to treat it the same as a link with rel="enclosure". Best practices for publishers aren't relevant to me, I need to know how to deal with all probable cases.
Monday, 15 August 2005 03:23:54 (GMT Daylight Time, UTC+01:00)
Whether they'll be used reasonably is an open question, but I think there's content that fits each method, that ought to be handled differently. If I have a podcast where each mp3 has a corresponding blog entry where I go over the topics it covers, and provide supplementary links, and that has comments and trackbacks, then using link rel="enclosure" and having aggregators treat it like any other entry makes sense. But if I have a song-of-the-day podcast that really has no other content or web existence, rather than shoehorning it into something that doesn't fit, I'd rather have it treated as "enclosure-only" and just passed off to my player without sticking a faked-up entry into my unread items.
Monday, 15 August 2005 04:19:38 (GMT Daylight Time, UTC+01:00)
Hi Dare,

Do you plan to support the Apple iTunes enclosure technique and its associated syndication format?

http://phobos.apple.com/static/iTunesRSS.html

Lots of feeds use it.
Monday, 15 August 2005 07:18:51 (GMT Daylight Time, UTC+01:00)
Dare said: "The point is that as an aggregator if I see content-by-reference I'm going to treat it the same as a link with rel="enclosure". Best practices for publishers aren't relevant to me, I need to know how to deal with all probable cases."

Following this logic, do you intend to allow RSS 2.0 based podcasts to use the link element to reference MP3's? It's not the way publishers should do it, but they certainly could.
Monday, 15 August 2005 13:12:45 (GMT Daylight Time, UTC+01:00)
Robert,
There is nothing the iTunes syndication format adds that I can see I need to support. All I need is a pointer to the media and a title. I already get that from RSS 2.0 and the Apple extensions don't provide alternates for them.

James,
As Phil points out 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.
Monday, 22 August 2005 23:33:49 (GMT Daylight Time, UTC+01:00)
I'm just a simple hacker, but if I did this correct, this should be a valid Atom 1.0 feed with enclosures... (video in the form of .mov files, not audio in the form of .mp3 files.)

http://tinkernet.org/feed/atom/

Do what you will with it...

Wednesday, 31 August 2005 09:31:21 (GMT Daylight Time, UTC+01:00)
I believe the difference between Atom's "enclosure" link and the "content-by-reference" is that the "enclosure" link means "pre-download this" ahead of time (before I even look at this). Where "content-by-reference" means "download this when I view it".

For large media files, you'd want to use Atom's "enclosure" link so that you don't have to wait for it to download. (The "content-by-reference" would have you sit there and wait for it to download.)

-- Charles
Comments are closed.