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?


  • The next evolution for OpenID?

    This morning at IIW Dick Hardt presented his vision for solving the issue whereby a user is dependent on his OpenID provider being up and non-evil.…

  • HTML 5 vs. Yadis

    One of the ways that the Yadis specification allows for the XRDS document location to be declared is via the X-XRDS-Location header embedded via a…

  • Client Certificates: It's easy, man! recently added support for logging in with client certificates. I've heard people talking about client certificates lots of times, but…

  • 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.