This post originated from an RSS feed registered with Java Buzz
by Bill de hÓra.
Original Post: XML Namespaces: they set up us the bomb!
Feed Title: Bill de hÓra
Feed URL: http://www.dehora.net/journal/atom.xml
Feed Description: FD85 1117 1888 1681 7689 B5DF E696 885C 20D8 21F8
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. 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. 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 probabably for legibility reasons 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 be able 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). Here I'll grant that the fact an XML Namespace is a URI is useful since we can leverage RDF for the child/parent relationships, but in truth I could just as easily map any number of raw names or a dotted prefix name directly onto URIs (e.g. Dublin Core in HTML). Once I go for the indirection of a mapping function, I 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 Mendehlson 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 passable 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]...
Previous Topic
