The RSS Blog

News and commentary from the RSS and OPML community.

In part I of my articles on multiple enclosures, I described why I think the spec is clear that an RSS <item>s may only contain one <enclosure>. The best response I got was questioning how I know the intent of the author. My response was that the original author told us his intent was one or zero enclosure per item.

In this part, I want to describe various scenarios showing how multi-part enclosures should be supported in RSS. There are numerous reasons why a publisher would want to include more than one enclosure in an RSS item. Let me describe some. If I missed one, then drop me an email and I can address your specific scenario too.

  1. Enclosures in different languages.
  2. Enclosures in different media formats.
  3. Enclosures in different media types.
  4. Enclosures with different content.

Different Languages

Sometimes an RSS publisher would like to attach a media file in several different languages. This is almost always a fundamental misuse of the enclosure. Even if you could have multiple enclosures, then why would any user want to download your audio or video in several languages? Surely each user is interested in one specific language. In this case, it's almost always best to have one RSS feed for each language. Otherwise, each user may be downloading several times more media bytes than they really require.

Different Media Formats

Sometimes an RSS publisher would like to attach a media file in several different formats. For example, they may want to attach a WAV file and an MP3 of the same audio compilation. This isn't really different from the scenario above. A separate feed should be provided for each format. The user can then decide why format is best for them.

Different Media Types, but Similar Content

Sometimes an RSS publisher would like to attach different media types with similar content. This might be an MP3 and an MPEG. In this case, not only is the format different, but the basic media type is also different: audio vs. video. This is an interesting scenario. The best approach is likely also to have two different RSS feeds: one for the audio and one for the video. A user could subscribe to their preferred media or both.

Different Media Content

The last common scenario is where the user wants to attach two or more media, each with unique content. Let's make up an example to suit this scenario. Imagine an RSS feed for movie reviews, with a video attachment (the movie trailer) and an audio file (the review of the critic). There are several ways of handling this type of multi-enclosure scenario, but offering multiple RSS feeds is not really an option. In the previous scenarios, the same content was being offered in different languages/formats. In this scenario, it's not a language/format difference but actual content. In this case, there's no reason to have multiple RSS feeds.

The question becomes how to allow for multiple enclosures when multiple enclosures per item are not allowed.

Side-By-Side Enclosures

The first solution to this problem is to have one <item> element per enclosure.

<rss version="2.0">
   <channel>
      <title>sample</title>
      <description>sample</description>
      <link>http://sample</link>
      <item>
         <title>sample</title>
         <description>preview for sample</description>
         <enclosure url="http://sample/sample.mpg" length="23456" type="video/mpeg"/>
      </item>
      <item>
         <title>sample</title>
         <description>review for sample</description>
         <enclosure url="http://sample/sample.mp3" length="12345" type="audio/mpeg"/>
      </item>
   </channel>
</rss>

In this case, there's a lack of binding between the two enclosures. Other than maybe a similar title, it's not programmatically possible to tell that the two RSS <item>s are related. This can make the job of the podcatcher a bit difficult and the experience of the user confusing.

Yahoo! Media Extension

A second solution is to use the Yahoo! Media RSS extension to describe the second and any further enclosures.

<rss version="2.0" xmlns:media="http://search.yahoo.com/mrss/">
   <channel>
      <title>sample</title>
      <description>sample</description>
      <link>http://sample</link>
      <item>
         <title>sample</title>
         <description>preview for sample</description>
         <enclosure url="http://sample/sample.mpg" length="23456" type="video/mpeg"/>
         <media:content  url="http://www.foo.com/movie.mp3"
               fileSize="12345"  type="audio/mpeg" medium="audio" />      
     </item>
   </channel>
</rss>

In this case, we provide two enclosures by re-using Yahoo!'s Media RSS extension. The binding between the enclosures is obvious. The only problem with this technique is that Yahoo! Media RSS is not as well-supported as the base enclosure element. Mind you, I think the difference in support level is very minimal.

Exceptions

There are likely some exceptions to the rules above. In fact, there are likely many exceptions. There are so many use cases for RSS enclosures that even a one percent exception rate would mean hundreds, maybe thousands of exceptions. If you can't figure out the exceptions on your own, then contact us in email and we'll try to help.

Debate

It's also possible that you disagree with my multiple-enclosure thoughts. In that case, I'd love to hear why. Please reply in the comments.

Reader Comments Subscribe

For completeness, I can think of another common reason, and solution.

You might need to distribute a set of objects that must stick together. For example, an updated exe and supporting dlls.

The solution would be to zip the objects or, better, provide them as a single installer (msi) object.

Andy

Andy,
Good one. Agreed.

Randy

Quick check:
The samples provided does not have the right </description> end tags.

Sharanya S
Thanks for letting me know. The examples have been corrected.
Type "339":