« Exercise and the Imbalanced Man | Main | NetNewsWire 2.0 Nominated in MacWorld's Readers' Choice Awards »

Tuesday, November 08, 2005


Feed You can follow this conversation by subscribing to the comment feed for this post.

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

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.

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

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.

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.

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


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

PS. see http://micromodels.org

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.


The comments to this entry are closed.