Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

XML

So every time I decide that I need to addle my brain a little bit more than the Economist and Slashdot can assist me with, I go reading blogs. This is kind of last-ditch boredom born from hour upon hour of mind-numbing, totally brain rotting work (documentation, IDS signatures, etc...). This is only outdone by the necessaray confluence of ennui and righteous indignance necessaray to actually post to a blog. Blogs are continuous-partial-attention theater as implemented via HTTP.

Anyway, I digress. Athough this is a blog, so you probably wouldn't have been able to tell it from "real" content had I not pointed it out. What I was going to blather about was XML, XHTML, and the assylum escapees who love them.

It seems that every time I point my browser at a blog of interest (I wonder if that's a term the DHS uses?) I get more and more flapping and jawing about the current state of this XML standard, that schema, and RPC API fOO. Every time I do, I realize how very, very little I frigging care. Now this isn't to say that these aren't important topics in my life. I currently maintain the netWindows documentation entirely in DocBook, I used to maintain the OWASP Guide (a couple of hundred pages of DocBook), and I use XML from everything from backend data storage to config files. I've been using XML since '99-'00 when I implemented XML document returns directly from Oracle Java stored procedures (no, it wasn't well-documented then either).

But I still don't care. I can't muster up the will to care. XML is parsing, and meta-parsing at that. It is NOT important, it is transport. Transport is not important, transport is transport and it can be done a million ways. So why is it that every Architecture Astronaut on the planet seems to gravitate to XML as the way things Should Be Done (TM)? And why will they yell at you very very loudly indeed when you suggest something else?

My first thought is insecurity. XML lets bad programmers throw up their hands in frustration when something breaks below their level of expertise. You're having problems with buffering and you're getting corrupted data streams which lead to invalid XML being passed to your app? Oooh, must be a system problem...better call those system monkeys to come fix it.

Next, I think that XML is a canvas for debates that people who would do much better as prickly lit profs can now have in a technical arena. By the nature of its status as a language for defining languages, it is ripe for every kind of misunderstanding and rhetorical parry and thrust in the book. In other words, it makes great stuff to fight about because you can take sooooo many sides (very often not even at odds) on its user-defineable battlefields.

After that, I think there's a herd mentality in effect regarding XML. One of my observations about successful technology is that is has to draw herds. It has to be so bloody obviously a good thing for some applications that it is declared the coming savior of every application. Herds must then form around these nebulous declarations in order for said technology to be really successful. And when the dust settles, the technology will succeed where it probably should have (and some places where it hsouldn't have), and will leave a lot of dissapointed disciples. No matter though, the herd will be jumping on the next bandwagon to pass through the programming wasteland soon enough. The really important thing though is that the herd has to jump in the first place. XML satisfies this requirement with a vengance. Once the herd jumps, the herd builds some tools, and these tools are the only really important things about a "technology" (if you can term anything about it important with a straight face). In the case of XML, it's DOM, SAX, and XSLT. These are the only "important" things about XML. That's it. That's the whole shebang. Those 3 acronyms are why XML is important, and those things are the reason XML will outlive its useful life expectancy and get used in some places it has no business ever being. It's sad to say, but the herd is ultimately useful if missdirected.

The herd property is maddening because as much as I want to be a contrarian about XML in many respects XML DOES make an entire class of problems easier (assuming good tools, ha!). Inevitably it's going to get pushed and pulled and twisted in ways it should never have been and holy wars will be fought (this is the part I hate), but when it's all said and done XML will still make a lot of things easier. Which is why I still use it. But I hate the holy wars, and I hate the way they always tend to happen in public (because it's no fun to be prick if no one can be offended, I guess).

Which brings us back to blogs. Blogging about XML is about as useful as clipping your toenails in public. You get just about as much useful feedback and roughly the same ammount of idle discussion regarding the particulars ("you use what to clip your toes?"). Writing in a blog is a crappy way to create a discussion. It's like so much of the web: a uni-directed stream of consciousness that has neither meaningful context or definite locality in what context it can scrape togeather. Conversation via blog is debate in the worst tradition of academic discourse, a disjoint and generally unfathomable exercise in ego stroking.

So go ahead, work on those XML specs and security-as-an-afterthought RPC APIs and what-have-you but please, for goodness sake, shut up about it. Speaking as an interested XML user, I don't want to hear about it. I want to hear what you did with it (thereby implying that you've got to do something useful first).

And keep your grubby semantic-web fingers off my HTML markup, will you? It's just as conformant as I deem it useful to be. I've already got a real document dialect (DocBook) which, suprise suprise, isn't all that expressive either.