Attention.opml or Attention.rss?

Alex Barnett has an interesting post suggesting that OPML is a great format for attention data. OPML is already supported by every RSS aggregator, so it seems a natural format for storing feed-specific attention information.

Of course, whenever the topic of an attention format is raised, the focus shifts to attention.xml, which was designed expressly for this purpose. So it's interesting that Steve Gillmor - co-creator of attention.xml and President of AttentionTrust.org - is also (and has always been) in favor of saving attention data in OPML. Steve and I discussed this at length earlier today, and we agreed that using OPML for attention data makes perfect sense, especially for RSS aggregators.

As Alex mentions, FeedDemon 1.6 already stores attention data in OPML, so this isn't merely a theoretical argument - it's being used today. However, right now FeedDemon uses a set of namespaced fd: attributes for this information, which leads to two problems:

1. These attributes are proprietary to FeedDemon, and may not be applicable to other services which wish to make use of this data
2. Namespace support in OPML is uncertain

The first problem can be tackled with an open discussion about an attention namespace, but OPML is going through a transition at the moment, so it remains to be seen whether namespaces will be officially supported. If not, there is a simple solution: store the same namespaced attention attributes in RSS instead. Every aggregator obviously supports RSS 2.0 already, and RSS 2.0 supports namespaces, so RSS 2.0 should work (albeit not nearly as well as OPML).

Really, the bottom line here is that we've moved past the stage where we have to wonder whether attention is important (it is), so the next step is agreeing upon a format. Given that both OPML and RSS are already supported by every aggregator, why not just choose one and get on with it?

Signed by Nick Bradbury and Steve Gillmor

Comments

[Danny]

I've posted a longer comment over at Alex's (currently in moderation), but my basic point follows this: "OPML is already supported by every RSS aggregator" - XHTML is already supported by every RSS aggregator (and browser), it's also based by a clear specification, and Attention.xml is pretty well spec'd out on top. I can't see any strong justification for creating a new spec for Attention in OPML.

Having said that, personally I'm not overly concerned about what format is used as long as it's done unambiguously (which may be a problem with OPML, but whatever...). If there's a common data model behind the formats, interop is possible at that level (i.e. we have XSLT).

[Nick Bradbury]

Danny, I've spent the last decade writing software that has had to deal with the side effects of not adhering to specs (not to mention the side effects of bad specs to start with), so I definitely understand where you're coming from. But at some point you've just got to say "screw it" and give in to practicality.

Pretty much every aggregator supports OPML import/export, so why not just include the attention data in OPML? After all, how would an end user get that information into their aggregator - would they first import their OPML file, then import a separate attention.xml file?

And don't get me wrong - I'm not saying that attention.xml should be discarded. But I am saying that OPML seems like the obvious format for RSS aggregators to store - and share - their attention data.

[Timothy Appnel]

I'm a bit lost by what you mean by practical. You said OPML is in a transition right now with an uncertain outcome, but call the use of OPML more practical over RSS, XHTML or even Atom all of which we know is not in transition. While OPML's use as a blog roll import/export format is widespread, isn't it more practical to build something new (in general, not just Feed Demon) more practical using a specification that is widespread AND stable now?

One comment: attention data has value beyond aggregators -- for instance web browsers. It would be a shame if that were overlooked..

[Nick Bradbury]

It's practical because it's already widely used for maintaining subscriptions lists, and because existing aggregators already support OPML import/export.

In this situation I'm focused on aggregators, but I definitely agree that attention data has value beyond aggregators, and even beyond web browsers.

[Danny]

Hmm, although I generally agree with tima, the current existence of OPML for import/export is a good point. Do we stop at feedlists and attention, or is OPML suitable for anything we can wrap in it? At this point in time I'd suggest that it's barely enough for feedlists, because of the spec ambiguity (having advisory pages and a validator elsewhere is not the same thing as having a clear spec). But ok, assume for a moment that OPML *must* be used for feedlists, attention (and possibly a lot more). How can this be done in a clearly-defined fashion?

Two suggestions:

1. Use Profiles
- the "Guidelines" approach to adding rigour to the spec is fine, as is the addition of new element types and so on, as long as it's possible for tool developers to be able to tell which guidelines are being followed, which element types are included, how their tools expected to process the stuff. Having to trawl Dave's blog to find out what things mean isn't a good mechanism for the 21st Century! If, where e.g. the "power OPML" guidelines are being followed, a URI is used to declare this, a lot of the ambiguity disappears. Think Postel. The URI could maybe appear as an attribute on the root element, i.e.
opml profile="http://feeds.scripting.com/powerOpmlGuidelines"
This would be low cost to the producer (one extra attribute) but potentially high value to the consumer.

2. HTML-based tools should provide equivalent standards-following XHTML representations
- many of the OPML tools I've seen actually do their rendering as HTML, so there is another point at which the same data can be provided to other tools in a consistent fashion. There are standard ways of expressing the structures OPML uses in HTML (ol, li, a, dl etc), but it would be good to encourage consistent use of these. The XOXO microformat offers an entirely suitable approach. Given that Attention.xml is expressed using the XOXO format, following this approach would automatically enable interop.

[Kevin Burton]

Mu (http://en.wikipedia.org/wiki/Mu_(Japanese_word))! Attention.rdf!

:-P

[Danny]

Kevin - absolutely! RDF is perfect for modelling this kind of information, and I personally plan to use attention data in an RDF-based system. But I don't expect people to be publishing attention data in RDF/XML (at least not in the short term), and as long as they are using an unambiguous format there's no reason that they should. As long as the domain model makes sense and the format is unambiguous, virtually anything can be interpreted as RDF (I'll be using XSLT on Attention.xml for a start).

[Danny]

PS. see http://micromodels.org

[Chris]

Nick great post as usual - I tried trackbacking to it but apparently blogger doesn't support that! What the heck??

So I thought I might post the link here.

http://universalgadget.blogspot.com/2005/11/attention-attention-everywhere.html