Attention, OPML and nails on head

If you've been following my blog, especially this month, you can't have failed to notice me banging on about this Attention / OPML topic for a while now (and here and here and here and here).

Not that I've been obsessed or anything...

Anyway, Nick Bradbury has returned from his Thanksgiving break and instantly hits the nails on the head:

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

I, not suprisingly, support this approach 100%.

Let's just do it now.

Tags: Attention, , ,

Comments (3)
  1. J Wynia says:

    I’m actually going to disagree with Nick a bit here Alex and say that "import/export" isn’t what people are really after.

    What really opens things up is when your aggregator can just be *pointed* to an OPML URL. That URL can then be dynamically manipulated in whatever ways you want and *every* aggregator is updated whenever you use it. I did the import/export thing, but read feeds in multiple ways and the sync issues crop up pretty quickly. However, my IMAP reader setup just points to an OPML file that changes whenever I add or remove feeds and it does it all automatically.

    Import/export is a relatively clumsy, static approach to moving data around. I MUCH prefer to have the portions that are "mine" stored somewhere I control and have all of the tools just read it whenever they need it.

  2. phil jones says:

    What I can’t help wondering though, is whether current aggregators that "support" importing and exporting OPML, preserve the XML sufficiently to keep new namespace tags.

    Can we be sure that if I export my subscriptions from aggregator A to B, edit them in B, then export for aggregator C, that B hasn’t lost the any non-standard tags from other namespaces that were added by A?

    I’d assume we *will* need the aggregators to be upgraded to know about this information.

Comments are closed.

Skip to main content