Dave’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.

This is not the only service, just as weblogs are not RSS’s only domain, but lets look at how we might include this comment service in an RSS feed. ### 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 both ping 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?

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







```

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 mod*link ships with a standard “service” relationship for pointing at WSDL descriptors (and presumably [RSD descriptors](http://archipelago.phrasewise.com/rsd) 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](http://search.cpan.org) will now (0.98*4) look in rdf:resource attributes if it is explicitly told to, but discards the rest of the attributes, [MagpieRSS](http://magpierss.sf.net) ignores attributes entirely. Mark Nottingham’s [RSS.py](http://www.mnot.net/python/RSS.py) has limited attribute support (and like XML::RSS should be hard to add more support), I haven’t played Mark Pilgrim’s [rss](http://diveintomark.org/projects/misc/rssparser.py.txt)*parser but I’m betting against attribute support. What are the other standard RSS parser? ### A services module

A last option is to write a new module proposal specifically for carrying service information, it could be simpler, and not make extensive use of attributes. It would probably be easier to parse with current toolkits, and more likely to be adopted into RSS 2.0. However, I’m having trouble getting motivated to design something new in the face of the elegant work Kevin has already done. Maybe inspiration will hit soon.