Something I'm kind of looking forward to is unsubscribing from all the persistent search feeds I've got running on variants of the search term "del.icio.us". There's probably about a dozen of them I monitor. I love the site, and I love the service, and this is going to be a great book - but man am I tired of hearing about it. ";->"

Just finally finished and uploaded another chapter - which feels good despite the fact that it had been due this past Wednesday. It turns out that a large chunk of the material I'd planned for the chapter back in the fall last year had evaporated by now, so I had to spend some time inventing some fresh stuff from scratch. Now, just two more chapters left, then it's on to revisions and edits before wrapping everything up by April.

You know, I'm really looking forward to above-freezing temperatures and sunshine as a regular occurrence.

The addition of subscription lists as a part of the OPML 2.0 spec is actually pretty significant, and I only just now felt it sink in. This has been one of the main uses of OPML up to now, and it's mostly been passed around by oral tradition and whatever news aggregator happened to do with it. Now there's documentation. If nothing else, that alone makes the OPML 2.0 spec worth the price of admission. From here on out, future use cases for OPML should follow the same lead, defining the semantics of their new node types and associated attributes.

Objections to OPML?

• I've been searching around, trying to collect all the objections to OPML as a format that I've seen floating around the blogosphere so that maybe they can be brought up in a friendly environment and either debunked or fixed. The main ones seem to fall into these groups:

  • "What are all those elements like windowLeft and crap doing in the head?"

    • These are artifacts of OPML being used by GUI outline editors - namely Frontier, Radio, and the OPML Editor. I have seen a few other outliners use these elements, however. And, after all, these elements in the head are all optional and ignorable by parsers. Why do people seem to get so bent out of shape about them? It doesn't seem like extra work, if you don't care to do anything with them - but at least their meanings are documented in the spec.

  • "Attributes and not elements? UGH!"

    • The use of attributes seems to be a design decision meant to make OPML simpler to parse. It's a bit of a compromise. It's also a reinforcement of the outline data model: Nested nodes, each with a set of fields attached. Yeah, there are encoding pains to be had, and then there's the rich history of attribute-vs-element fights in XML itself. But, I don't think there's a straight technical reason why using attributes is bad. And, with OPML2, if there's data that just can't fit usefully in a flat attribute, you can use your own extension elements in an XML namespace.

  • "In feed lists, people keep using xmlurl when they mean xmlUrl! Or, they use a type="link" when they mean a type="rss "! What the hell?"

    • These people are confused, attribute names are not case insensitive - though values are - and now there's a documented node type for feed lists. All the variations I've seen between feed list formats seem to be covered in a reading of the OPML 2.0 spec.

  • "This is one of Dave's formats. I don't like Dave."

    • The easy way to fix this one is to go work on something else - or if you find that OPML keeps appearing in your field of interest, suck it up and don't pee in the potato chips.

• OPML has a background of being a workhorse exchange format. It's got bits that aren't conformant to any Platonic ideal, but they've been used in the past and so they're in the spec so that at least they're explained somewhere when you run into them. But, I'm having a hard time finding issues that aren't just "smell tests" or gut reactions and are really tough ambiguities or serious breakdowns of the format for its intended uses. I may be missing something, but I'm looking.

Oh, and it would be nice to see a few OPML profiles. (Like this one, that I missed when I first wrote all of this.) That is, a document that's not a full-on spec but one that says, "Here's what a feed list should look like." There's not that much to a reading list to get it totally right - why should there be a need for OPML format converters in NewsRiver and such? Things like this have been levelled at OPML itself as a failing - when really it's not something wrong with the general format, but with the lack of a defined profile for a particular usage of OPML and everyone's understanding of it.

It seems like the discussion around the OPML 2 spec has been civil and interesting so far. I'd really like to see the review draw out all of the long standing gripes people have had with the format and either get them happily resolved or slay them as strawmen. (I don't think there are many left that matter.) And it would be nice if the room stayed clear of people just there to pick a bone with Dave or with something to prove. Really, I have only one remaining wishlist item for the format - other than that, it could use a few more FAQs answered, some test cases and a beefy validator, and maybe a pool of implementation examples and tips.