Slowly digging myself out of the back log from a week offline (expect lots of MLPs).

One thing that happened last week was the release of two very rich new modules for RSS (2.0) that are being batted around the Net this week (both via les).

The Reviews (RVW) namespace “is intended to allow machine-readable reviews to be integrated into an RSS feed, thus allowing reviews to be automatically compiled from distributed sources”.

Over at Deanspace (which is doing a surprising amount of interesting hacking) the Datebook Schema Embedded in RSS (DBRSS) is embedding an vocabulary for discussing very complex information about events including recurring events, location info, event planning (tracks and costs), scheduling (rsvp) requirements, and convener info.

It is awesome to see people really pushing the boundaries of syndication, thinking about new and creative applications that can be enabled by sharing more data in more structured ways. Which is why I felt a little odd at the very similar disquiet both these specs caused in me. As I was struggling to articulate it, I found Bitsko’s Is a Feed the right place for your Data? which sum up the unease quite nicely.

Review data has permanence, it has linkability, it has searchability, it has reusability — why is it locked in a syndication feed for use pretty much only by syndication clients?

(this is less true of events, and perhaps DBRSS is less covered by this critique) ### Its a HyperTextual World

Bitsko proposes “freeing” the review information by giving it its own url, and syndicating a link to it. I think this is brilliant, the information at the end of the URLs is a real untapped source of descriptive power, which is why I loved Kevin’s proposed mod_link. (though no one else seemed to) Bitsko demonstrates how if you moved the structured data (e.g. a machine readable review) to its own URL, you could link to it transparently from an HTML document, or any of the various syndication formats, well worth a read. ### Don’t Forget the People

A while back I started writing an article I hoped to pitch to XML.com on designing RSS modules. I never finished it (and XML.com published so many RSS articles, the market seemed played out) but the central idea of the article (in retrospect) was about striking an aesthetic balance in namespaces between readability, and structure. A good rule of thumb is: > Include just enough information in a feed so that an item could be displayed in a meaningful way without having to fetch the remote resource.

There are a few reasons for this

  • RSS has proven that human readable formats get faster uptake; design for the “View Source” style of learning.
  • Fetching and parsing a remote resource is hard for beginners to do well, like all the neophyte PHP hackers in the world who are just wanting to do something quick.
  • Strikes a balance between current, and future usage patterns

Externalizing Reviews

Taking the Reviews namespace as an example, as I imagine myself trying to use it, I think I would want to at least know the title of book as well as the title of the review. This changes the RSS item to read “I am syndicating a review of this book, more information at this URL” instead of just “I am syndicating a review at this URL“. I support Bitsko’s idea of giving microcontent a home of its own, but lets not sap all of the semantic meaning out of the feeds while we are at it.

Externalizing DateBook RSS

Similarly the bulk of the DateBook schema could be moved an external resource, and the feed could syndication a link to this resource , and the most basic of event information (which is the idea behind modevent). DBRSS even has the advantage that unlike reviews, there are already a number of calendaring/scheduling formats available, and there is no need to invent a new one. (I’m assuming DateBook schema is something new, the name makes me think of an attempt to XMLize the core Palm calendar, but the fields don’t match at all)

Depending on persuasion you have a choice between iCalendar, RDF Calendar, or xCal.

Transient Metadata

You’ll notice (or at least, I notice) that this is a different approach then what I took with my rough sketch of modweather (an admittedly much simpler namespace), where I packed all of the information into the feed.
The difference is current weather conditions (and even forecasts) are about the most transient information imaginable. They are also laden with some of the worst, most obscure formats to ever reach wide circulation. There is no added benefit to giving the current weather conditions for this instant in time a home of its own.

More on DBRSS

I think the story on DBRSS is less cut and dry then RVW, I’ve certainly felt the tug of a richer event syndication format myself, perhaps one less unencumbered by Calsch’s years of work. A couple of quick thoughts that came up looking at it. - Durations instead of endtimes is a seductive choice, but I’ve found that if you’re storing your events in a SQL datastore, endtimes are much more useful.

  • Tracks I don’t understand, and seem a little off to me. It seems like an attempt to cram a calendar into an event.
  • Wouldn’t it be better to use a geo vocabulary to describe the location, rather then larding it into your calendaring one?