Now blogging at diego's weblog. See you over there!


On my previous entry about Postel's Law, Danny Ayers made a comment, and to a part of it I said I'd reply in a separate entry. To make the question clear, I'll restate it here in a different way to involve the technology only.

Essentially, Danny was asking "If you have used OPML, would you agree that OPML does not follow this route you are advocating of adding as many constraints as possible to a spec, to make interoperability easier?" (Danny, if I misunderstood the question please let me know, but I'm pretty sure that was the essence of your comment, personal matters aside).

My answer to that question would have to be no, I do not agree. Let me explain.

I have implemented both readers and writers of OPML when used for RSS subscription lists for an end-user product (ie, clevercactus). And there is one main point that I've found frustrating, namely that the attributes used on the "outline" element vary between tools. I have previously noted, in another context the elements that would "complete the spec" by properly specifying these attributes.

However, I've come to the conclusion that this is not a problem with the spec itself, but rather a problem of what are we using it for. As far as I can read in the spec, it was designed to be a very simple and flexible storage mechanism. The first sentence in the spec says "This document describes a format for storing outlines in XML 1.0" (my emphasis). It doesn't say "This is a format for interchange of outlines" or anything like that.

That is, creating an interoperable format for RSS subscription lists was not part of the original "charter" of OPML.

Which is why I can't agree with Danny's statement, because the interoperability problems we all know about pop up when using OPML outside of its original intended domain.

As such, that is, as a format for local storage of outlines, the OPML spec might have done a good thing by keeping things very open. Note that the spec explicitly says, in its goals: "Outlines can be used for specifications, legal briefs, product plans, presentations, screenplays, directories, diaries, discussion groups, chat systems and stories." -- that's a big set of apps, and I'd be hard pressed to define a consistent set of common attributes for all of them. To be honest, if it was me designing it maybe I would have chosen a different path (like for example target less applications), but that's not really the point. Design is at its core subjective.

So. Given that OPML was not originally designed as an interoperable way to store feed subscription lists, the current situation is logical, almost predictable. It seems to me (given what I've seen--I might be wrong of course) that this is a use of OPML that grew in ad-hoc fashion and as such created some incompatibility problems. But is this a problem with OPML itself? I don't think so. Usage grew beyond its original intended target, and things got a bit messy.

Okay, that's my answer to Danny's question, but I just want to be clear on what I think about OPML given the current situation, as what I said above might seem a bit too ... err... "theoretical".

That is, we still have the interoperability problems for feed subscription lists.

However, now that it's clear that it has become accepted for that use, I noticed that Dave recently put up a short RFC that clearly states "Using OPML to exchange subscription lists". My comments from October last year would, then, apply in this new context, and the new RFC already covers part of them (the most important in my mind, which is the issue of standard attributes).

This new spec of "Interchangeable OPML Subscription Lists" plus the OPML spec itself (which doesn't necessarily need to change, since it is still relevant in its original intended domain) make a simple combined spec that is useful and already deployed (granted, some aggregators might be generating different attribute names that those on the RFC, but that's a tiny change, and none of the other items under discussion that I'm aware of are in any way "deal-breakers").

Hence, OPML applied to the domain of feed subscription lists in particular is a good solution, simple and to the point. And to me that's what matters: if something does what I need, it's simple, and it works, I'm all for it.

Categories: technology
Posted by diego on January 12, 2004 at 1:19 AM

Copyright © Diego Doval 2002-2011.