XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.


Cracks in the Foundation
by Micah Dubinko | Pages: 1, 2


Other specific choices made in the development of XML namespaces cause persistent confusion among markup practitioners. For one, namespace prefixes are largely incompatible with DTDs, which, although unfashionable, are still a built-in part of XML and intimately connected to any use of XML involving DOCTYPEs or named character entities. In other words, they're still important to nearly any web developer.

Does a namespace declaration apply to elements or attributes? A reasonable answer would be "yes and no"; the subtleties still pop up in mailing lists. Ron Bourret covered this and more in the seminal Namespace Myths Exploded article previously published on this site. The way things ended up, attributes can't be placed in a specific namespace without an explicit prefix regardless of whether a conflict is even possible -- a decision that would cause problems later.

Another trouble spot lies in the use of "namespace names," or strings that look like URLs, which add a truckload of URL baggage to the spec and lead many enthusiastic new learners to wonder what will happen if they visit that URL in a browser. This is an old debate, one that won't be rehashed here. But direct confusion from the XML Namespaces spec is only the beginning.

Collateral Damage

QNames in content: what does this phrase bring to mind? The Namespaces in XML spec defined QNames but remained silent on the topic of using them in content; in practice, it arrived with XPath 1.0, which needed a way to refer to element and attribute names. At the time, making XPath identifiers look the same way as the elements themselves was justified as the most sensible way to deal with two-part names with one part bound to a longer third name. Over time, though, this practice has fallen out of favor and been compared to "using TCP packets as delimiters in an application protocol." This bit of unpleasantness has become firmly entrenched in XML vocabularies, at a minimum including any that use XPath. The lineage of this practice can be traced straight back to namespaces.

Aside from using QNames in content, the XML Schema Part 1 specification has been criticized for its complexity. I started counting how many times the word "namespace" or its plural appears in the document and gave up somewhere around 400. How much of this complexity is caused by namespace-think?

Then there's XLink, once a promising branch of XML technology. XLink failed to meet a key requirement:

It must be possible to apply XML link semantics to existing documents by modifying the documents' DTDs only, requiring no modification to the document instances themselves.
For example by supplying appropriate information in an element's definition (in the DTD), such as a default ROLE attribute. This provides for layering of XML link semantics onto large bodies of XML documents without requiring modification of those documents.

The syntactic restrictions introduced by namespaces caused this conflict. It wasn't possible to meet this requirement and define XLink as a distinct namespaced vocabulary.

Even when vocabularies use namespaces, there's no guarantee of coordination. If anything, scoping encourages folks to go off and do their own thing. Already within the W3C we have paragraphs as html:p as well as speech:p, where html and speech map to the "namespace names" for XHTML and Speech Synthesis Markup Language, respectively. (Don't even get me started on wml:p.) Markup vocabularies also have multiple anchors as a elements, including XHTML, SMIL, and others outside of W3C. So the problem attributed to chameleon namespaces at the outset of this article has already come to pass. In aggregate, the amount of time that has been wasted debating and rehashing such issues in standardization and development communities is staggering.

Now What?

There are a few other lines of evidence that will have to go in another article, like the mobile industry reaction to namespaces or examining the continual stream of proposed alternatives. Individually, any of the objections recounted here wouldn't amount to much. Collectively, though, they form a composite sign that suggests that the XML community might need to reconsider not only its approach and attitudes toward HTML, but toward the foundation of namespaces as well.

What would the XML world look like without namespaces, or with a less intrusive version thereof? Docbook and HTML would continue to be fine. Newer languages like SVG would be slightly different in details, but overall the same. The big question is what compound documents would look like, but it's hard to imagine the situation much worse than what we have today.

So far, the W3C hasn't posted an official notice to the effect of what Tim Berners-Lee wrote on his blog. Nevertheless, it's encouraging to see a willingness to change course when needed. Let's hope this willingness extends deep enough to reconsider namespaces. The tension between incremental HTML 4 philosophies and XML namespace practice will only get stronger.

The formal objection noted at the start of this article concludes with these words:

If we're going to go changing the namespace for every host language that comes along, we might as well not have namespaces in the first place.

Actually, that doesn't sound like such a bad alternative.

Disclosure: the author of this article is a former editor for the XForms and HTML Working Groups, and is a contributor to XML Hacks. He submitted this article in namespace-free HTML.

1 to 11 of 11
  1. Still a skeptic
    2007-07-08 14:59:19 arjunray
  2. XMPP
    2007-03-21 09:34:04 phil wilson
  3. Compelling examples
    2007-01-29 20:50:04 rpbourret
  4. Middle position
    2007-01-11 00:26:54 rjelliffe
  5. namespaces: we shouldn't be forced to pick them
    2006-12-01 11:35:26 rp_
  6. Not compelling?
    2006-11-13 07:50:56 Norman Walsh
  7. Examples of documents with multiple namespaces
    2006-11-10 02:19:32 spepping
  8. XLink
    2006-11-09 11:38:46 Erik Wilde
  9. Namespace Examples
    2006-11-09 11:10:06 Erik Wilde
  10. DocBook Would Be Fine...
    2006-11-09 10:35:18 KeithFahlgren
  11. It's all up to the parser implementation
    2006-11-08 18:56:40 chuckwh
1 to 11 of 11