By default, every element in an XML document is assigned to the "empty" namespace, but the document's root element -- or any contained element -- can be assigned to another namespace, identified by a URI (universal resource identifier). The idea is to be able to mix and match XML vocabularies in a modular way. For example, my weblog's RSS 2.0 feed includes an experimental element, called <body>, which lives in the XHTML (extensible HTML) namespace, not in the (empty) RSS namespace.
Normally in an RSS feed, the content of a blog item is not delivered as XML, but rather as HTML that is enclosed within the RSS <description> tag, and is massaged so that its HTML tags don't conflict with the enclosing XML tags. Since the content I create for my blog really is valid XML, I added the <body> element to make the content available as pure XML for use by other XML applications. In particular, I envisioned storing the <body> content in a database and then running XPath queries to do structured searches of the blog entries.
Months passed, things happened, and I never got around to creating that structured-search application. Then, last week, I took another look at my feed and suddenly it seemed wrong. I thought that I had not correctly assigned both the <body> element, and its contained elements, to the XHTML namespace. After conferring with Sam Ruby, a member of IBM's emerging technologies group and one of the developers of an alternative syndication specification (provisionally called Pie, Echo and Atom, but not yet finally named), I realised that I, in fact, had it right in the first place.
It's not just me -- lots of people trip over this stuff. Some notable experts -- including Sean McGrath, CTO of Propylon in Dublin, Ireland -- argue that namespaces should be avoided for that reason.
Clearly there's something counterintuitive about XML namespaces. Here are two oft-cited truisms that suggest different interpretations of that fact.
1. You never forget how to ride a bicycle.
2. Use it or lose it.
Some might say that mastery of XML namespaces is like riding a bicycle: yes, it's counterintuitive, but the trick is impossible to forget once you learn it.
Others might say that mastery of XML namespaces is the kind of skill that atrophies with disuse.
Who would be right? We hope for the former, evidence so far suggests the latter, but I don't think we can decide yet. In my case, I haven't really ridden the bicycle yet.
Although I'm publishing a mixed-namespace format, I'm not yet using it in a namespace-aware way.
In general, we don't have much experience creating and using simple XML vocabularies, never mind mixed ones. InfoPath, the first application making a serious bid to enable mainstream folks to routinely gather and use XML data, hasn't even shipped.
I think the creators of InfoPath and similar tools -- who hope that use of modular XML vocabularies will turn out to be like riding a bicycle -- ought to provide some training wheels. One thing that complicates use of namespaces, for example, is that their effects on downstream XML applications can be hard to predict. There are a number of equivalent ways to write a mixed-namespace document. But for downstream applications, such as structured search, some of those ways make life much harder than others. Tools that help us visualise the effects of mixing namespaces are an example of what I mean by training wheels. We're going to need them.
Udell is lead analyst for the InfoWorld Test Center.