RSS, OPML and the XML platform.
|
|
|
|
Blogroll
Copyright 2012 World Readable
|
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.
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.
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.
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.
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.
The first solution to this problem is to have one <item> element per enclosure.
<rss version="2.0">
<channel>
<title>sample</title>
<description>sample</title>
<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 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.
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</title>
<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.
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 [randy@kbcafe.com] 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.
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
The samples provided does not have the right </description> end tags.
Sharanya S