This blog can't be viewed on LiveJournal. Instead see

ActivityRSS instead of AtomActivity?

14th Dec 2008

If you've been following my adventures this weekend you'll know that I started off wondering why RSS is still so prevalent when we have Atom. However, not long after that I started doing research in preparation for specifying the media object types in AtomActivity and discovered one big reason why RSS is still widely used: folks publish media objects like podcasts using MediaRSS, but there is no standard for media objects in Atom.

So faced with the need to mark up activities involving photos and videos in Atom, what is a boy to do? Last night I took a whack at adapting a subset of MediaRSS to Atom, with the hope that AtomActivity could refer to that. However, today I played around some more with various software that consumes feeds with embedded media, and found that there does seem to be a subset of MediaRSS that does actually work in software today, and that made me take a step back and reassess my goals.

My design goal with AtomActivity was always to describe some minimal extra markup that would allow existing feeds to be consumed by activity aggregators. Asking providers to add a bunch of additional junk to their Atom feeds when they already have fully functional MediaRSS feeds doesn't really jive well with that design goal.

The research that motivated me to ask why sites still publish RSS does seem to indicate that RSS is far more widely deployed, both by publishers and by aggregators, than Atom is. Aside from a few Six Apart products, no major service that I looked at publishes Atom only. Most publish both Atom and RSS at the same time with only basic content in the Atom feed. Many others publish only RSS, or they publish both but only have autodiscovery for RSS. I'm less certain about the consumer side, but given that only a tiny handful of publishers actually publish Media information in Atom at all I'm guessing that today systems like FriendFeed and Plaxo Pulse are using the RSS feeds when they're pulling from sites like YouTube and Flickr. If the goal is to make only minimal changes to existing practice, it does look like we're barking up the wrong tree by building on Atom.

The question now is whether to persevere with AtomActivity or to repurpose it as an RSS extension instead. Using RSS has the benefit that MediaRSS is already widely used in RSS to mark up media content, so we can do a reasonable job at consuming these feeds as they exist today. It does mean that we lose out on some Atom features such as atom:source and the Atom Threading Extensions, but neither of these are widely used today so that's no major loss.

If we did go this route I'd still want to write up a proper spec for a subset of MediaRSS that serves the same use-cases as my AtomMedia draft, since the current "specification" for MediaRSS is to big and not really detailed enough. However, at least this approach means that there is existing implementation practice to base such a subset on, so I'd be describing what works today rather than what might work in a few years if anyone actually bothers to implement it when their RSS feeds already work anyway.

As ever, I'm eager to hear what the rest of the world thinks. It's lonely here inside my head...


TPCThread 6a010535617444970b01053614336e970c