Multiple-Enclosures, Part II - The RSS Blog
RSS, OPML and the XML platform.
Copyright 2012 World Readable
The RSS Blog
<< Previous Main Next >>
Wed, 23 May 2007 04:45:41 GMT
Multiple-Enclosures, Part II

In part I of the my articles on multiple-enclosures, I describes why I think the spec is clear that RSS <item>s may only contain on <enclosure>. The best response I got was a questioning of how do 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 multiple-enclosures should be supported in RSS. There are numerous reason 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 he really requires.

Different Media Formats

Sometimes an RSS publisher would like to attach a media file in several different formats. For example, he 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 him.

Different Media Types, but Similar Content

Sometimes an RSS publisher would like attach different media types with similar content. This might be an MP3 and an MPG. 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 ave two different RSS feeds, one for the audio and one for the video. A user could subscribe to his 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 previously 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-enclosure per item is not allowed.

Side-By-Side Enclosures

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

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

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 than 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="">
         <description>preview for sample</description>
         <enclosure url="http://sample/sample.mpg" length="23456" type="video/mpeg"/>
         <media:content  url=""
               fileSize="12345"  type="audio/mpeg" medium="audio" />      

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.


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 1% exception rate would mean hundreds, maybe thousands of exceptions. If you can`t figure out the exceptions on your own, then ping me with an email [] and I`ll try to help.


 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.


Good one. Agreed.


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

Sharanya S
this is not working
I just started posting comments for blog and faced a lot of rejections. I think your suggestion would be helpful for me.
bad credit car loans

Type "339":
Top Articles
  1. Unblock MySpace
  2. MySpace
  3. FaceParty, the British MySpace
  4. and
  5. Blocking Facebook and MySpace
  1. Review of RSS Readers
  2. MySpace Layouts
  3. RSS Stock Ticker
  4. RSS Gets an Enema
  5. Google Reader rejects