Enclosures and Media RSS Funkiness - The RSS Blog
RSS, OPML and the XML platform.
Copyright 2012 World Readable
The RSS Blog
<< Previous Main Next >>
Sat, 29 Sep 2007 14:46:26 GMT
Enclosures and Media RSS Funkiness

This morning, I was building an image and video application and needed some RSS sources to seed the image and video database. I picked three feed sources; Google Video, Yahoo! Video and Flickr. The first thing I noticed was that only Yahoo! Video used RSS enclosures, where as all three used Media RSS. I decided to write the code once using Media RSS and drop RSS enclosure support. I wasn't too happy about making this decision. Had Flick and Google simply used RSS enclosures in addition to the Media RSS, then I could've written this application for general RSS enclosure support. It's not like this would've been difficult as RSS enclosures look almost exactly like Media RSS content. A sample of each element follows.

<media:content url="http://www.youtube.com/v/aVN_VZhLiCg.swf" fileSize="30" type="application/x-shockwave-flash" height="356" width="450" duration="1"/>
<enclosure url="http://www.youtube.com/v/aVN_VZhLiCg.swf" length="30" type="application/x-shockwave-flash"/>

Using an extension element in place of an equivalent core RSS element is what we call Funky RSS and much not appreciated by people trying to write RSS applications. The reason we don't appreciate it is because the core RSS elements are better understood and you don't end up with the ridiculous situation that I'm about to describe.

Although all three sources use Media RSS, I had to write separate code for all three implementations. All I wanted to do was access the media:content/@url attribute and all three conveniently had unique access paths to this variable. Here's three feeds that I'm looking at.

  1. http://www.flickr.com/services/feeds/photos_public.gne?tags=Simon+Gagne&format=rss_200
  2. http://video.google.com/videofeed?type=search&q=Simon+Gagne&so=0&num=20&output=rss
  3. http://api.search.yahoo.com/VideoSearchService/rss/videoSearch.xml?appid=kbcafe.com&query=Simon+Gagne

Using fully qualified element names, the access paths are as follow.

  1. item.http://search.yahoo.com/mrss/:content.@url
  2. item.http://search.yahoo.com/mrss/:group.http://search.yahoo.com/mrss/:content.@url
  3. item.http://search.yahoo.com/mrss:content.@url
Looking deeper, two of the three implementations appear to be invalid, but which two are invalid is the question. Let's start with the namespace. According to the Media RSS spec, the namespace URI should not have a trailing slash, but according to the Feed Validator, the namespace URI should have a trailing slash. It also turns out that at one point, the spec did have the trailing slash, but later it was removed. This was previously discovered in February 2007 and Yahoo! has dropped the ball since. Turns out, the feeds are not really valid or not. It's actually the spec that is invalid.
Further, disregarding the namespace URI, the Google feed is still invalid, yet the Feed Validator doesn't seem to recognize this. The media:group element is for "grouping of <media:content> elements that are effectively the same content, yet different representations." That's not what Google is doing, rather they are using it as a general container.
Conclusion? Had Google and Yahoo! simply used the RSS enclosure element, then I would be long done by now. Instead, I have 3 times the code I really need. Frustrated.
Reader Comments Subscribe

I have asked countless times for a use-case of multiple enclosures per item. Each time, I outlined how this is done while respecting the constraint. The only response is "But I don't want to do it that way." I've never encountered a technical reason why this is limiting.

So, I ask you to provide a use-case and you are not allowed to respond to my solution with "I don't want to do it that way."


From the spec:
  • The following elements are optional and may appear as sub-elements of channel, item, media:content and/or media:group
- Sam Ruby

I can only guess that your statement is meant to contradict my statement above, but it doesn't.


Agreed. But I don't see how this is relevant. The validation issue is the cardinality of media:content in media:group. Two or more. Not one.

From the spec: It's an optional element that must only be used for this purpose.


Thanks Sam!


I have a great use case for multiple enclosures in a single item: we publish a podcast of a 4-hour radio show. Each show is broken up into four 41-minute segments (commercials, station IDs, etc. removed).

In my current RSS feed, I have to display each show as "Show Name, Part X" with a single enclosure. This makes my RSS feed 4 times the size it needs to be, and limits the number of episodes that can be included in the feed.

I'll go read the specs on media:group, but from what you're saying above, there is some discrepancy between sources as to the validity of media:group/media:content and enclosure, correct?


I just wanted to point out that you included the solution in your comment. As per the size of your RSS feed, this would be insignificant compared to the size of a 41-minute audio file.

I'm not sure what "discrepancy between sources" means.


Sorry, poor choice of wording on my part. Acceptance by third parties is really the discrepancy issue I was talking about. For instance, I can (and did) set up a nice, valid RSS test feed that includes each part of an episode under a single item using media:content. But will iTunes, for instance, display each part or only one, or reject the feed outright? Feedburner supports media:content, but still only one media file per item.

As for the size of the RSS feed, some services won't accept a feed file over a certain size (Feedburner again, for instance, limits theirs to 512Kb). That limitation, combined with the fact that each of our episodes must be broken into four channel items, makes it difficult to push out more than a few episodes at a time.

Now, I'm not attempting to push our entire library out via RSS, as we have over 100 episodes, but it'd be nice to show more than we currently are able.


512KB is a really big for an XML file.


How bad of me to malform the link...sorry


cheap nike Air Jordan 1 KOshoesmodel might be making it way into stores sometime next year.Rumors had been floating around for months that a retro version of the legendary . Jordans For Cheapthe AJKO has become something of legend amongst Jordan fans — many of whom will jump at the chance to get their hands on a pair of the previously unobtainable kicks. Known for its rarity and canvas upper .Said to release next summer, the model is expected to sport a price tag of $45.99.report by nike shoes Although suspicions were confirmed with theJordan Brand 2010 catalogue leak, the news finally has some visual support, as images of two retro colorways of the sneaker have hit the net.,Real Jordan ShoesSome people think that the Jordan Brand is advancing with the times and synchronizing renovation. But cheap Nike Shoes?some people think that this stifled the classic masterpiece. This kind of colorway make the shoes classic enough and fashion enough Anyway, this Nike Air Jordan I have a pure black Nike Shoes?leather upper and a pure white midsole match with an pure orange inner lining and "Jumpman" logo.. Nike Shoes?Cheap Prices JordansWe all know that the sneaker is culture, and sneakers is also art. Big Size Shoe for cheapThe stained glass Air Jordan High 1 is the best job to show us the sneakers art. Stick with Nike Sneakers for more sneakers art news. Here the Air Jordan 1 High comes with design of stained glass by featuring classic color conbination of Air Jordans including white, varsity red and black.During past years, cheap Air Jordan Retro shoessneakesr art theme become much popular like previous Birthday Cake Air Jordan 1 and others.
Type "339":
Top Articles
  1. Unblock MySpace
  2. MySpace
  3. FaceParty, the British MySpace
  4. del.icio.us and sex.com
  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 del.icio.us