Martin Atkins (mart) wrote in apparentlymart,
Martin Atkins

Atom Media Extensions

In my last entry I noted that there doesn't seem to be any standard practice for publishing media in Atom. A handful of publishers do the best they can with the stock Atom spec and make a single link with rel="enclosure", while Google (Picasa, YouTube) is the only publisher I could find that actually uses the MediaRSS elements in Atom. Most sites just don't bother: if you want that information, you need to go fetch the RSS feed.

Since only Google's using it right now anyway, rather than import wholesale the whole of MediaRSS into Atom — MediaRSS is a pretty big, complex beast with lots of stuff that's arguably unimportant for most use-cases — I decided to design an Atom extension that's based on some of the features of MediaRSS but bashed into a more Atom-like shape and without the elements for which Atom already provides equivalents.

I now have a first draft of "AtomMedia". Here are the main differences between AtomMedia and MediaRSS:

  • AtomMedia has the narrower scope of being aimed at the aggregation and activity stream use-cases. Much of MediaRSS's complexity is so that it can be used by the indexer for Yahoo! Video Search, but that's not my goal here.
  • MediaRSS uses extension elements exclusively, while AtomMedia extends the atom:link element. In particular, it extends standard Atom's link rel="enclosure" for compatibility with existing implementations.
  • AtomMedia excludes the MediaRSS features that are not directly useful for the aggregation and activity stream use-cases. In particular, I did not include content ratings, regional exclusions, "credits", timed text and media hashes. Many of these feel like things that are more general than this use-case, anyway.
  • AtomMedia excludes some bits that Atom already has equivalents or near-equivalents of: category, title, keywords.
  • Due to the tighter scope, I was able to include tighter requirements for specific use-cases that will hopefully mean that there will be less variation between publishers.
  • AtomMedia reduces the media metadata considerably: it has only width/height for visual things and duration for time-based things. Some of the other attributes (fileSize, lang, type, ...) have equivalents in generic Atom and are thus omitted.
  • AtomMedia assumes that each entry describes exactly one media object that might have multiple representations. MediaRSS looks like it's trying to allow entries with multiple objects associated with them, but it doesn't define well exactly how that works in practice and I've seen no feeds actually make use of this feature.

If I can get some traction on this I'd like to use it as the representation format for the photo and video object types in the AtomActivity schema specification. The main important thing I'm missing right now is a namespace URI. How does one register URLs under, as seems to be the done thing for Atom extensions in development?


  • Moved to TypePad is now hosted on TypePad rather than LiveJournal. All of the old content remains over here in LiveJournal land, but those who are…

  • Moving the Goalposts

    In the few weeks since I published the first drafts of AtomActivity, ActivitySchema and friends several things have come about: FriendFeed is…

  • Activity Streams and Comment Aggregation

    One pain point that exists for activity streams right now is the dispersal of responses over various networks. When I post a blog entry like this…

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.