While listening to the TechPodCast.com podcast recorded at Gnomedex, I got to hear
a recording of a session that was taped unofficially. I was very interested
to hear MS is going to make extensive use of RSS in the Longhorn platform, consuming
them from the same part of the OS that currently does our Windows update process.
There are a ton of implications to this idea that all have to do with how our applications
will behave and consume data in the future. In order to provide focus to this
post, let’s look at one thing that MS is explicitly proposing to do to RSS.
Making Lists From Feeds
Have you had the experience of subscribing to an RSS feed that was inappropriately
conceived? Netflix has a wonderful example. I love Netflix, but I thought
it sounded really weird when they gave me a link to allow me to subscribe to a feed
that contained items from my rental queue. It makes complete sense to me to
subscribe to a feed that updates when my latest DVD ships, or when a DVD is returned,
but a list just doesn’t make sense in the current RSS model.
The net effect of subscribing to the “My Queue” feed was that every day, my aggregator
would pull a complete re-publication of my queue instead of just the updates to queue.
This had the effect publishing over 100 “new” articles to my feed every day (1 per
movie in my queue). This is, of course, an absurdly inappropriate use of RSS
syndication. I don’t want to subscribe to my queue as a content generation feed,
but as a list. That is the problem that MS is looking to resolve with the list
extension to RSS.
MS is also trying to provide a structure for rich meta data inclusion in the list
feed itself, so that the list will be nicely sortable, may hold enclosures, can be
searched well, etc. Please see the MS
Extensions Specifications page for details on the extension, which live within
the cf: name space.
Here’s a simple scenario that I can easily see being of great use to my company.
If you are a content publisher, but your content more encyclopedic than news wire,
you will publish it as a list. It makes a great deal of sense for the AP to
publish their news articles as RSS today. Once that article is published, it
is out there in the world and it is sealed. If you are publishing an encyclopedia,
however, your articles may be revised, be republished, withdrawn, or you may publish
new articles. This is a great model for a list feed. An aggregator can
monitor the list feed for changes and act only on the changes that it senses in the
list. So we have each article of the encyclopedia exposed as a list item and
the article itself can be published as a PDF enclosure (for example). The aggregator
can run hourly to synchronize a local data store on the consumer’s side to keep the
entire encyclopedia up to date and use the meta data tags within the list feed to
populate a search index.
This is only one example, but it is one that I am going to start playing with.
The question remains, though, “Will the RSS community embrace this extension?”
It matters because aggregators will need to support this extension for it to genuinely
catch on. I grant that with Longhorn, there will essentially be no more need
for separate aggregators ( long conversation in itself ) but what about other OS’s
and other platforms? Microsoft is trying to push this specification through
the Creative Commons License, but will still hit a lot of bumps along the way.
They are Microsoft, after all.
Links