Service enriched RSS feeds
January 24th, 2003Dave’s evangelism reminded me of an idea thats been tickling at the back of my brain for a while:
RSS feeds should come packed with a soup of meta-data, and some of that meta-data should be services.
Comment Service
A comment service is the most obvious service one could provide, and most applicable to the majority of deployed RSS feeds. As a bonus we’ve already got a widely deployed API for publishinhg a comment serve: a TrackBack URL.TrackBack provides a simple, RESTful interface for commenting
-
GET
a TrackBack and you have a list of comments, POST
to a TrackBack and your part of the flow.
Deployment Vector?
So how do we describe such a service? I suppose the <comment> tag works for RSS 2.0, but I would hope for something a little more structured, clever, and forward looking for RSS 1.0.
modtrackback
A proposed modtrackback exists (in a limbo state of not having hit the proposed modules list) and provides for bothping
which is the comment service discussed above, plus about
which functions more like annotation. This works (in fact ben used to suport it), and is very simple. But isn’t very future proof.
- What do we do when we want to advertise more then one service?
- Or a service that works differently then TrackBack?
modlink
Kevin Burton’s modlink seems like it has a lot of promise with its ability to provide richly described. arbitrary linking. It comes with 6 standard types of links, and is extensible through providing new relationship URIs (like namespaces). More good info in his design decisions. Maybe a comment service could be published with relationship “http://purl.org/rss/1.0/modules/link/#comment”, e.g.<l:link l:rel="http://purl.org/rss/1.0/modules/link/#comment" l:type="?????" l:title="urn:trackback-comment" l:lang="en" rdf:resource="http://laughingmeme.org/mt-tb.cgi/292"/>
As you can see, I’m not clear on what should go in the type
attribute.
Extensible
I think this is a cool option, and very extensible. It also isn’t limited to REST based services (though I think REST is a more natural fit for the resources already available to an RSS aggregator) as the modlink ships with a standard “service” relationship for pointing at WSDL descriptors (and presumably RSD descriptors as well).
Problem with mod
link Unfortunately it would require a rather major (though doable) upgrade of the existing RSS parsers at least the ones I work on: XML::RSS will now (0.984) look in rdf:resource attributes if it is explicitly told to, but discards the rest of the attributes, MagpieRSS ignores attributes entirely. Mark Nottingham’s RSS.py has limited attribute support (and like XML::RSS should be hard to add more support), I haven’t played Mark Pilgrim’s rssparser but I’m betting against attribute support. What are the other standard RSS parser?