Combining Applications with Namespaces

One of the obvious limitations of the original XML 1.0 recommendation was the lack of a mechanism for dealing with the inevitable naming collisions that would occur as more and more XML applications were defined. For example, imagine how many different documents would include a <name> element. If large, complex documents were to be built using shared libraries of markup declarations, some definitive way for grouping and separating markup elements had to be developed.

The W3C Namespaces in XML recommendation serves this purpose. It allows XML document designers to mix elements from different applications without the possibility of confusing one with another. This is done by associating each element and attribute name with an XML namespace.

Namespace URIs

Logically, an XML namespace is simply a Uniform Resource Identifier. Most commonly, the URI is a simple HTTP URL (such as http://www.strategicxml.com). Because domain names are guaranteed to be globally unique (thanks to their hierarchical nature), applications can depend on well-known published namespace URIs to make assumptions about element contents.

For example, the URI http://www.w3.org/2001/XMLSchema is the official namespace for elements that define an XML schema. A <schema> element associated with this namespace should conform to the XML Schema recommendation, and nothing else. So, the question remains: How are elements and attributes associated with namespace URIs?

The xmlns Attribute

The answer is that they are associated via the special xmlns attribute. Whenever an element has an xmlns attribute, it (and its descendants) belong to the namespace associated with the URI in the attribute value. For instance, adding the following attribute declaration to the restaurant.dtd example places every restaurant document into the http://namespaces.strategicxml.com/restaurant namespace:

<!ATTLIST restaurant
  xmlns CDATA #FIXED "http://namespaces.strategicxml.com/restaurant"
>

The root <restaurant> element and (by default) every child element and attribute now belongs to the globally unique namespace associated with the URI given previously. But setting the default namespace doesn't help us combine elements from different XML application vocabularies. To combine elements, you actually need to change the structure of the element tag names themselves.

Qualified Names

To support mixing namespaces, the “Namespaces in XML” recommendation defines the idea of a qualified element name. A qualified name consists of a regular tag name with a namespace prefix, like this:

<prefix:localpart/>

The part of the name to the left of the colon is the namespace prefix. The part to the right is called the local part. When different prefixes are used, elements with the same base name can be combined in a single document. Take, for example, the following XML snippet that contains three different elements that have the same name but belong to different namespaces:

<a:localname>
  <b:localname/>
  <c:localname/>
</a:localname>

Without the namespace prefixes, all the tags would be called <localname> and would be indistinguishable. But the prefix by itself is not what distinguishes one element from another. The prefix is merely shorthand for the actual namespace URI that must be declared using a special : attribute:

<namespace-example xmlns:a="http://namespaces.strategicxml.com/example/a"
    xmlns:b="http://namespaces.strategicxml.com/example/b"
    xmlns:c="http://namespaces.strategicxml.com/example/c">
  <a:localname>
    <b:localname/>
    <c:localname/>
  </a:localname>
</namespace-example>

The three xmlns attributes on the <namespace-example> element declare the :, :, and : prefixes. When a namespace-aware parser is comparing elements for equality, it doesn't do a simple text comparison of the two tag names, it actually compares the namespace URIs and local names. Therefore, the namespaces from the preceding example could be declared like this:

<namespace-example xmlns:a="http://namespaces.strategicxml.com/example/a"
    xmlns:b="http://namespaces.strategicxml.com/example/b"
    xmlns:c="http://namespaces.strategicxml.com/example/c">

In this case, all three elements would actually be equivalent to a namespace-aware parser, even though they all have different namespace prefixes. Although this kind of thing is possible, it is definitely not considered to be a good XML design practice, and should be avoided.