RSS, OPML and the XML platform.
Copyright 2022 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, whereas 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 Flickr and Google simply used RSS enclosures in addition to the Media RSS elements, 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="" fileSize="30" type="application/x-shockwave-flash" height="356" width="450" duration="1" />

<enclosure url="" 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.


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

  1. item.
  2. item.
  3. item.

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.

Conclusion? Had Google and Yahoo simply used the RSS enclosure element, then I would be long done by now. Instead, I have three 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.


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


Type "339":
Top 10 Articles
  1. Understanding TTL
  2. Polling RSS
  3. Multiple Enclosures, Part II
  4. Enclosures and Media RSS Funkiness
  5. DTD for RSS 0.9 and 0.91
  1. Folksologies: De-Idealizing Ontologies
  2. OPML Manager
  3. XSS Test Cases in OPML
  4. State of Blogosphere Search, Part II
  5. Is Atom Dead?
Copyright 2022 World Readable
RSS Spec
Drudge Retort
Local Farmers Markets
Winnetoba Radio