November 28, 2005

OPML, Let Me Count The Ways I Love Thee...

Building Valid Atom and OPML Is Hard (and It Shouldn't Be)

Let's see, theres.. no, not that.

Oh, and there's... oh HELL NO! Definitely not that.

---
[quick-update: see footone one]
---

Huh. I guess that means:

OPML SUCKS! SUCKS!!!! SUCKS!!!!! SUCKKKKKKKKKKKKKKKKKKKKKSSSSSSSSSSSSSSSSSS!!!!!

Did I mention OPML SUCKS!?

I HATE OPML!!!!!!!(I promise, don't ask me how I really feel as I am actually holding myself back at the moment believe it or not. And no, I have no intentions of following this up with a "OK, I was just trying to get a response from the community. This is it. OPML SUCKS!)

Why do we use it? Is there an OPML format that validates and can be accepted anywhere that accepts spec conforming OPML? What does spec conforming OPML look like? And who's idea was it to embed the positioning crap into the "header" of an OPML file? Does separation of data/content and layout ring a bell to anyone?

I tell ya, I'm about on the verge to tell you how I really feel but I'm going to hold back and let DonXML chime in for now:

I’ve mentioned the borked OPML Editor back when I released my OPML. The OPML site would seem the place to go to read the current spec, but Dave Winer’s OPML Editor creates OPML 1.1, but public spec is 1.0, and a spec for 1.1 is nowhere to be found. My OPML file was created with Dave’s tool, but does not validate when run thru the OPML Validator (which validates 1.0 only). So, Robert, how can you expect Bloglines and Newsgator to comply with a “spec” that is only buried in a tool? And even if the public spec was up to date, try reading the spec without looking at the example files. Go on, I’ll wait. Now try to tell me that you can create a valid OPML doc. Unless you have written OPML before, or have seen what Dave expects, you’ll be hard pressed to do it right the first 1000’s times. Odds are you will give up and take a look at what others are producing, and make yours look like theirs. That’s not a spec, that is cut and paste. And to make matters worse, OPML doesn’t use namespaces (that’s a known Dave issue, but the average XML developer might not know that).

So a few weeks back Uche took it upon himself to pull a bunch of people into the Atom IRC channel to discuss what to use instead. His conclusion:

XBEL.

Now there's a format that makes sense. Good spec. Good support. Make sense. And "text" refers to NODES, not ATTRIBUTES, like it should.

I don't know about you, but if given a choice between a recommendation offered up by Uche and ANYBODY else who offers up OPML as a solution...

Actually, I would go with Uche's advice over somebody suggesting anything else for that matter. That's how much I respect Uche and any advice he might give. So that should pretty much sum up who I would go with if that person was suggesting OPML as the solution.

I'll leave it there for now. But each and every time I encounter a situation where I have to deal with some form of OPML its only going to fuel the fire and... well, I'll wait until that happens until blowing my cap again. My desire is not to piss people of with random fits of tirade. But this isn't a tirade against a spec thats difficult to read, but in the end everything turns out to be OK as you can eventually figure it out, or look at a good example, create and XML Schema or RNG file for validation, and be done with it. How do you create a XML Schema or RNG file against 20 or so variations of the same "spec". Thats the point. There's simply know way to be sure what format the OPML you encounter will look like, no namespace to utilize as a way to determine thats its even some form of OPML in the first place, no consistent versioning that can at least send a hit your direction, so instead you have to try built transformation files that try to second guess what to do with each element, attribute, etc..., which sometimes requires rebuilding the tree, and reprocessing it which, in XSLT 1.0, requires a node-set() function of some sort which means is not cross platform... I could go on, but I think this is MORE than plenty...

I will say that this is just nonsense. Propagating a crappy spec with no fundamental XML-based qualities to speak of is just flat out nonsense.

[1] : If wondering why this little mini-rant its because I have been recently (like within the last 12 hours) making an attempt to write about this in the client-side XML book... its been one of those topics where you get so frustrated by trying to not only make sense of an XML data format that doesn't make sense, but then try to explain in words how to make sense of it to a fairly broad spectrum of potential readers. Its the third time I've come back to it(and its holding up an important chapter which currently has a big phat hole in it in regards to importing bookmarked Atom and/or RSS x.x data feeds to then index them, cache them, store various pieces in cookies for later comparison against the return value of a HTTP HEAD and potentially GET request to determine what, if anything is new(which reminds me... its so simple to write server side code that can create an MD5HASH of a file for later comparison, or even a simple script that can diff a cached version of file when that file changes and use this to determine if what the client has is the same as the client side file, and if no, return only the diff between the two (in a well formed Atom or RSS file). Shouldnt we just do that? Anyway)... hard to do when you are trying to write transformation files that adapt to who knows how many "versions"(read: interpretations) of the OPML spec exist in the wild) and after readining Don's post I decided to express my true feelings and then simply hope and pray that Simon can see my viewpoint and allow me to focus on either raw Atom or XBEL, or whatever else he feels is best. I fear that I may have to suck it up and just go with it, but we'll. If this turns out to be the case I promise I will do my best to cover it without opinionated smut... but its hard, so I guess we'll just wait and see.

So now you know :)]