« Massachusetts starts open source repository | Main | Hindsight »

XML Namespaces: they set up us the bomb!

There is a profound architectural misdesign with the way that most tools deal with XML Namespaces. Not with namespaces themselves, though some may disagree, but with their common presentation. Even the XML Infoset fosters this misdesign. The error is that the Infoset and most tools present the namespace name and the local name as two wholly separate information items (parameters). - Ken MacLeod

Although I like the idea of APIs using single names, I disagree with Ken. The problem lies squarely with XML Namespaces. The spec goofed by not providing a syntactic artefact for the full name of the element. As a result Namespaced elements are totally abstract. To tunnel them into XML syntax required extending core XML tools with what is effectively a QName macro processor. The QName, which Ken takes issue with - well, being the only thing specified it's naturally what you would expect to show up in the tools initially. A strange beast to offer up to a syntax obsessed community. Ken mentions that James Clark wrote the "clearest description of XML Namespaces" in 1999. But James Clark did that in large part by providing a decent syntax. So while the single name idea is good, all you can say about the tools folks is that they were working to spec.

Unfortunately any cogency stops there - the rest of this is a rant.

Since then, the XML Namespaces abstraction has been shoehorned into XPath syntax and the SAX and DOM APIs via the QName. Each time the complexity has gone up - but hey it's worth it, because name clashes happen every day in XML. Right? Having decided probably for legibility to prefer QNames, XPath had to invent its own (pretty decent however) model for XML Namespaces to explain what QNames are actually standing in for. Technically (if you care), in the XML Infoset XML that doesn't use XML Namespaces doesn't have a "meaningful" Infoset. Why, and what value is a meaningful Infoset anyway? I just don't know - shrug.

Meanwhile the Atom folks are talking about how define relationships between Atom elements and children in another namespace - XML Namespaces don't have any such semantics. Sure, XML doesn't either, but XML doesn't imply the kind of partitioned vocabularies XML Namespaces do, so it's hard to see why it should. So... it seems that when you do have something reusable in an XML namespaced vocabulary people sometimes won't use it. Oops. Ostensibly, this is for the usual reasons you need to be careful about normatively referring to someone's else's standard, but I suspect aesthetics and hubris also play a part. Mixed namespace documents are not always pretty. And if I've learned anything in this industry it's that people will expend no little effort to own the definition of a term. Effort that would otherwise have been wasted on useful work. The available option then becomes a one-shot mapping between vocabulary elements. In the Atom case, that becomes a mapping of Atom elements onto Dublin Core (perhaps defined as XSLT). Yes, the fact an XML Namespace is a URI is useful since we can leverage RDF for the child/parent relationships, but in truth it's just as easy to map any number of raw names or a dotted prefix name directly onto URIs (e.g. Dublin Core in HTML). Once we have the indirection of a mapping function, we might as well use it to keep my markup cruft free. Does anyone see the value XML Namespaces are adding here? I don't. Are we sure the spec understood the uses? I'm not.

[Note that some SGML folks generalized such mappings years ago as Architectural Forms (AF), but it seems not enough people liked them.]

There is almost a total suspension of critical thinking around XML Namespaces - XML itself gets dragged through the coals from time to time, but not XML Namespaces. I don't think I'll ever understand why the XML community has developed a blind spot around them.

I give up. Or maybe I don't. Glimmer of hope: Noah Mendelsohn recently challenged the belief that XML Namespace prefixes don't really matter, a notion which has always been nonsense to my mind. For me, that was a blast of fresh air.

Finally, ignore people saying using XML namespaces means being a good citizen. That one's a lemon folks. You can't be a good citizen with XML Namespaces. Not until default namespaces are dropped for being the pernicious, backward incompatible extension to XML that they are. It there was only one idea that had to go from XML Namespaces, it would have to be the default namespace. Indeed, without the default namespace, a direct spec, and a syntactic representation of a namespace along with its QName model, XML Namespaces might be decent technology. So, what did Namespaces in XML 1.1 grant us?

IRIs instead of URIs.

Uche's article that inspired Ken's entry, is very good tho'.

[marvin gaye: inner city blues]


March 20, 2004 12:11 PM

Comments

Jon Hanna
(March 25, 2004 05:23 PM #)

"total suspension of critical thinking around XML Namespaces" ?

Well, I can remember some pretty nasty fights over them.

Indeed I think that's why people seem to be dug-in not just on the existence of a namespace mechanism, but on the namespace mechanism we have. Those who took the pro-namespace position got polarised into a pro-namespace-exactly-the-way-they-are-Tim-Bray-was-a-genius-though-he-isn't-now-he-seems-to-be-expressing-occasional-doubts position.

Similarly interpretation of prefixes seems to get polarised, often on the basis of whether one's favourite tools directly support namespaces or not. I prefer a middle-ground position that prefixes aren't very important, but they're still there so we have to live with them.

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1193