An Attention Namespace for OPML, Part II

Published on by Nick Bradbury

I had hoped to write a follow-up to my post about an attention namespace for OPML before now, but I’ve had to stay on the sidelines of the discussion due to Thanksgiving, family and time spent on other work. Luckily, a number of folks have kept the discussion going:

As expected, I’ve heard a number of arguments against the idea of storing attention data in OPML, many of which aren’t concerned with attention but instead with the suitability of OPML for any purpose. Quite honestly, these arguments seem moot to me given that OPML is already used by pretty much every aggregator. Sometimes the best choice is the one that’s already being used even if it’s not technically superior.

Rather than enter another format war, let’s work to improve the situation instead. OPML is here to stay, and plenty of developers – including myself – will continue to use it and build upon it. Bickering about how OPML is technically inferior won’t slow it down, any more than similar arguments stopped RSS from being adopted.

Another argument I’ve heard a few times is that storing attention data in OPML seems an odd choice given that Attention.xml was designed specifically for this purpose. Again, though, I’m coming at this from a practical standpoint, not a technical one.

To me, the point is that every aggregator already supports OPML import/export. Whenever someone tries a new aggregator, the first thing they do is import their OPML. Which is better: asking a user to import two files – one for their subscriptions, and one for their attention data – or a single OPML file which includes both the user’s subscriptions and attention data? Your OPML subscription list already contains attention data in the form of the feeds you pay attention to, so it’s not exactly a stretch to put more attention data in OPML.

FWIW, my preference would be to define an attention namespace for OPML which contains a subset of the same attributes that are already defined by Attention.xml. After all, the Attention.xml authors have already done the hard work of defining the important attention attributes, and with their permission, we should build on that instead of starting over (and as an added bonus, using the same attributes would simplify converting between the two formats).

8 thoughts on “An Attention Namespace for OPML, Part II”

  2. On The Very Tired Debate Over Full vs. Partial Feeds.

    I’m rather tired of this whole full vs. partial feeds argument really. I don’t think this is a black and white issue anyways. For some sites it makes sense (read: has value) to have full feeds and some it does not.

  3. Nick:
    Regarding the “format wars,” without taking sides in the RSS vs Atom debate, or the OPML vs whatever debate, my own point of view on the subject has changed 180 degrees in the past few years. In the past, I was very much in the “go with what we have and not worry about making it perfect” camp. The reason for being in that camp was that things like file formats had a fairly short shelf life before they were replaced by something else. For example, unformatted text was replaced by roff, which was replaced by WordStar, which was replaced by Word Perfect, which was replaced by MS Word, which will be replaced by OpenDocument.
    But XML changes everything. XML and it’s attendant extensions and vocabularies have become a universal data description language, which, if implemented correctly, may NEVER be replaced by something else. Or at least not for a very long time. Under those circumstances, I think that it’s generally worth taking a little extra time and effort to make sure that any obvious flaws are corrected before a proposed format becomes too entrenched that it can’t easily be changed.
    The switching costs will never be lower than they are now.

  5. I have some reservations about OPML in the long run. The spec is underspecified. I also think that the folder concept might not work for feed aggregators in the future.
    That doesn’t mean that it can’t be fixed. (or that I’m wrong which I’m not ruling out).
    That said there’s no reason we can’t improve OPML. Namespaces would be a step in the right direction. It’s great that Dave likes namespaces now. There’s a lot you can do here.
    As far as real world quality of OPML… I’m not sure it holds up. My recent experience with export format complaince with OPML is that a significant percentage of aggregators are broken. It’s one of those things that’s only used once in a blue moon.
    Some aggregators include the xmlUrl as the htmlUrl. NewsGator OPML output is broken I think. The attributes are all lowercase. I can’t remember if the XML spec is case-insensitive right now.
    Kevin

  7. Kevin, of course the definition of ‘broken’ is fluid. There are things that the spec is silent on, and anyway, for an aggregator like BlogBridge, it’s more important to be able to import, say, BlogLines’ OPML than following the spec. It’s the old “Postel’s Law” at work again: http://en.wikipedia.org/wiki/Jon_Postel. That’s why these efforts at coming to some kind of consensus on basic OPML and namespace extensions are worth while IMHO.

  8. Attention in OPML (again)

    Alex Barnett pointed to Nick Braduburys vision for attention data in OPML. As might be expected, Im not sure how much I agree with what Nick proposes. My objections, though, have nothing to do with OPML as a potential format, for atte…

Comments are closed.