Raw

With all due respect to people using it, I've yet to see a compelling reason why anyone would want to use OPML for their primary data format - it allows you to express hierarchies in XML, sure, but XML allows you to express hierarchies in XML! There are a lot of other reasons for not only using an alternative, but running many miles from OPML.

The first point usually made in favour of OPML is that other tools can use it - aggregrators and so on. But those tools are still in their infancy, it's too early to lock things down. The amount of effort needed to implement any format to carry the kind of information shipped around in OPML would be pretty straightforward. For lists like blogrolls the OCS format is supported by many tools.

It's worth noting that you can express hierarchies and everything else I've seen suggested for OPML (text outlines, links, images etc) in (X)HTML. I suspect there are more HTML readers/writers than OPML ones!

The maintenance of an application using OPML is an important consideration. The merry dance that Dave Winer has taken RSS would seem to suggest that perhaps he isn't best qualified to look after the spec. You think I'm being biased because of RSS 1.0? Well look at XML-RPC then : until recently you had to use US-ASCII. Despite about 3 years pressure from users, it only finally got support for internationalization after it appeared as an argument against using XML-RPC in the AtomAPI. Objection! - Sustained. Circumstantial evidence, previous offences, fair dinkum your honour. So what about OPML itself? Back in 2001 Dave said "Head's Up", OPML 1.1 was on it's way. There's still no sign of a spec, yet the data Dave himself passes around has version="1.1".

Ok, on to the tech details, and why you'd be better off using anything but OPML.

A quicky : it doesn't know whether it's a data or presentation language. The file Dave is suggesting as an example for passing around a hierarchical list of feed lists (data, right?) contains the element <vertScrollState>9</vertScrollState>. Eh?

In OPML's favour, there's the ability to use it for custom kinds of data (blogrolls, text outlines, images or whatever) by making up your own elements/attributes and 'type'. But, errm, that's what you do when you create XML languages.

But, (one might argue) it allows a level of tool interop that you don't get with other XML languages. But, (one might reply), if there is a shared model between the producer and consumer, then you can have this level of interop

anyway, either directly (using a shared, domain-appropriate language) or using transforms (e.g. XSLT). OPML gives you nothing.

Then there's the way you can mix things up in OPML (blogroll, text outlines etc). You can do exactly this with XML namespaces, without the risk of naming clashes (e.g. my title and your title).

Still, for the most part this would all point to it being a simple choice, you can pretty much do the same things with OPML or custom XML. Except using OPML you lose the ability to properly validate your data using DTDs/XML Schema (thanks to the switch on 'type', arbitrary attributes etc).

The only justifications I can see for anyone using or promoting this format are 1. they are a big stakeholder in products that depend on it; 2. they wrote it and have an ego the size of a minor planet.

Working in an outliner-like domain with IdeaGraph, personally I was thinking of using a not-broken alternative such as OML for representing arbitrary trees. But after a year or so of expecting to need it any day, that day hasn't come. Purpose-built XML languages or RDF vocabularies are much more useful. (X)HTML is far better suited to representing structured documents than OPML. RDF is generally considerably better at representing 'outline' structures relating to resources such as documents or URI (lists). Basically a tree-based system falls down when your data isn't structured as a tree, which is most of the time on the web. I've nothing against trees - they're relatively simple to implement, efficient and intuitive to use.

For example, if you're using a tree-based outline, and a channel appears in more than one category, you somehow either have to hack a connection across (can you imagine XLink in OPML?) or duplicate the item. Either way you lose the benefits of using a tree in the first place. But if you use a model based on a general node and arc graph structure (such as RDF) then you can still project trees in the user interface. It's just a separation of model and presentation.