The XML Namespaces Recommendation seems to be causing a great deal of confusion. This note attempts an alternative explanation of the mechanism described in the Recommendation which I hope will be less confusing.
In the data model implied by XML, an XML document contains a tree of elements. Each element has an element type name (sometimes called the tag name) and a set of attributes; each attribute consists of a name and a value. Applications typically make use of the element type name and attributes of an element in determining how to process the element. In XML 1.0 without namespaces, element type names and attribute names are unstructured strings using a restricted set of characters, similar to identifiers in programming languages. I'll call these names local names. This is problematic in a distributed environment like the Web. One XML document may use part elements to describe parts of books, another may use part elements to describe parts of cars. An XML application has no way of knowing how to process a part element unless it has some additional information external to the document.
The XML Namespaces Recommendation tries to improve this situation by extending the data model to allow element type names and attribute names to be qualified with a URI. Thus a document that describes parts of cars can use part qualified by one URI; and a document that describes parts of books can use part qualified by another URI. I'll call the combination of a local name and a qualifying URI a universal name. The role of the URI in a universal name is purely to allow applications to recognize the name. There are no guarantees about the resource identified by the URI. The XML Namespaces Recommendation does not require element type names and attribute names to be universal names; they are also allowed to be local names.
Documents using this extended data model can be written by extending the XML syntax to allow universal names written as a URI in curly brackets followed by the local name. With this syntax,
<{http://www.cars.com/xml}part />
would specify an element whose element type name is a universal name with local name part and URI http://www.cars.com/xml. The XML Namespaces Recommendation does not take this approach, because XML 1.0 parsers would not be able to handle such documents. However, I will use the above syntax to explain the syntax actually used by the XML Namespaces Recommendation.
The XML Namespaces Recommendation expresses universal names in an indirect way that is compatible with XML 1.0. In effect the XML Namespaces Recommendation defines a mapping from an XML 1.0 tree where element type names and attribute names are local names into a tree where element type names and attribute names can be universal names. The mapping is based on the idea of a prefix. If an element type name or attribute name contains a colon, then the mapping treats the part of the name before the colon as a prefix, and the part of the name after the colon as the local name. A prefix foo refers to the URI specified in the value of the xmlns:foo attribute. So, for example
<cars:part xmlns:cars="http://www.cars.com/xml"/>
maps to
<{http://www.cars.com/xml}part/>
Note that the xmlns:cars attribute has been removed by the mapping.
This works for attribute names just as for element type names. For example
<NAME HTML:CLASS="largeSansSerif"
xmlns:HTML="http://www.w3.org/TR/REC-html40"
>Layman, A</NAME>
maps to
<NAME {http://www.w3.org/TR/REC-html40}CLASS="largeSansSerif"
>Layman, A</NAME>
All these xmlns attributes are rather cumbersome, so the XML Namespaces Recommendation allows them to be inherited: if a prefix foo is used in a tag, but the element does not have an xmlns:foo attribute, then the value of the parent element's xmlns:foo attribute will be used; if the parent does not have an xmlns:foo attribute, then the value of the grandparent element's xmlns:foo attribute will be used, and so on. For example,
<RESERVATION xmlns:HTML="http://www.w3.org/TR/REC-html40"> <NAME HTML:CLASS="largeSansSerif">Layman, A</NAME> <SEAT CLASS="Y" HTML:CLASS="largeMonotype">33B</SEAT> <HTML:A HREF='/cgi-bin/ResStatus'>Check Status</HTML:A> <DEPARTURE>1997-05-24T07:55:00+1</DEPARTURE></RESERVATION>
maps to
<RESERVATION>
<NAME {http://www.w3.org/TR/REC-html40}CLASS="largeSansSerif"
>Layman, A</NAME>
<SEAT CLASS="Y"
{http://www.w3.org/TR/REC-html40}CLASS="largeMonotype">33B</SEAT>
<{http://www.w3.org/TR/REC-html40}A HREF='/cgi-bin/ResStatus'
>Check Status</{http://www.w3.org/TR/REC-html40}A>
<DEPARTURE>1997-05-24T07:55:00+1</DEPARTURE></RESERVATION>
In many cases, most of the elements in a document have universal element type names that have the same URI. The XML Namespaces Recommendation has a special syntax to make this more convenient. An attribute xmlns specifies a URI that qualifies all unprefixed element type names. The xmlns attribute is inherited just like the xmlns: prefixed attributes. For example,
<section xmlns='urn:com:books-r-us'>
<title>Book-Signing Event</title>
<signing>
<author title="Mr" name="Vikram Seth" />
<book title="A Suitable Boy" price="$22.95" />
</signing>
</section>
maps to
<{urn:com:books-r-us}section>
<{urn:com:books-r-us}title
>Book-Signing Event</{urn:com:books-r-us}title>
<{urn:com:books-r-us}signing>
<{urn:com:books-r-us}author title="Mr" name="Vikram Seth" />
<{urn:com:books-r-us}book title="A Suitable Boy" price="$22.95" />
</{urn:com:books-r-us}signing>
</{urn:com:books-r-us}section>
Note that the xmlns attribute does not affect unprefixed attribute names.
An empty value for xmlns makes the mapping treat unprefixed element type names as local names (which is the default behaviour in the absence of xmlns attributes). Thus
<section xmlns='urn:com:books-r-us'>
<title>Book-Signing Event</title>
<signing xmlns=''>
<author title="Mr" name="Vikram Seth" />
<book title="A Suitable Boy" price="$22.95" />
</signing>
</section>
maps to
<{urn:com:books-r-us}section>
<{urn:com:books-r-us}title
>Book-Signing Event</{urn:com:books-r-us}title>
<signing>
<author title="Mr" name="Vikram Seth" />
<book title="A Suitable Boy" price="$22.95" />
</signing>
</{urn:com:books-r-us}section>
It is important to realise that the XML Namespaces Recommendation does not change the behaviour of XML 1.0 parsers in any way. The mapping from prefixes to URIs is a separate processing layer that operates on the element tree resulting from XML 1.0 parsing. Note in particular that it does not change the processing of the DTD. For example
<!DOCTYPE doc [ <!ATTLIST foo:x att CDATA "foo"> ]> <doc xmlns:foo="http://www.foo.com" xmlns="http://www.foo.com"> <x/> <foo:x/> </doc>
maps to
<{http://www.foo.com}doc>
<{http://www.foo.com}x/>
<{http://www.foo.com}x att="foo"/>
</{http://www.foo.com}doc>
This includes validation. The XML Namespaces Recommendation does not define a kind of validity distinct from XML 1.0 validity. Thus
<!DOCTYPE doc [ <!ELEMENT doc (x)> <!ELEMENT x EMPTY> <!ATTLIST x xmlns CDATA #FIXED "http://www.jclark.com/"> <!ELEMENT foo:x EMPTY> <!ATTLIST foo:x xmlns:foo CDATA #FIXED "http://www.jclark.com/"> ]> <doc><foo:x/></doc>
is invalid just as it would be in XML 1.0, even though
<!DOCTYPE doc [ <!ELEMENT doc (x)> <!ELEMENT x EMPTY> <!ATTLIST x xmlns CDATA #FIXED "http://www.jclark.com/"> ]> <doc><x/></doc>
is valid, and they both map to
<doc><{http://www.jclark.com/}x/></doc>
It would of course be very useful to have namespace-aware validation: to be able to associate each URI used in a universal name with some sort of schema (similar to a DTD) and be able to validate a document using multiple such URIs with respect to the schemas for all of the URIs. The XML Namespaces Recommendation does not provide this. The reason is is that DTDs have many other problems and missing features in addition to lack of namespace-awareness. So the plan is to come up with a new schema mechanism that fixes the problems with DTDs and, as part of this, provides namespace-awareness. This work is being done by the XML Schema WG.
Last updated: 1999/02/04