Namespace Myths Exploded
The XML namespaces recommendation is tantalizingly vague about, or omits altogether, a number of apparently important points. In practice, this is not a problemthe points are not actually important and the recommendation does what it was designed to do: provide a two-part naming system for element types and attributes. Thus, as long as you don't look too deeply, XML namespaces do their job and do it reasonably well.
Of course, many people have looked too deeply. Programmers are curious people and the close link between traditional namespaces and identifiers, as well as the perceived link between XML namespaces and schemas, has naturally invited closer inspection. So too has the fact that the XML namespaces recommendation introduces a new naming system, but does not discuss validation or how to declare XML namespaces in DTDs. Equally inviting is the fact that it discusses the structure of XML namespaces, but in a non-normative appendix. The result has been confusion and controversy.
This article discusses a number of myths that have arisen around XML namespaces, examining possible sources, clarifying what the recommendation says about them, and pointing out ways to resolve the issues they raise. It is hoped that this will help clear up some of the confusion about XML namespaces, as well as reinforcing the point that most of that confusion revolves around things not required to use XML namespaces as they were designedthat is, as a two-part naming system for element types and attributes.
Note: The discussions of these myths often refer to the "traditional namespaces used by an XML document." These are the traditional namespaces that hold element type and attribute names. There is one traditional namespace for element type names and, for each element type, one traditional namespace for attribute names.