Namespace Myths Exploded: Myths 1-5

Myth #1: XML namespaces exist

Table of Contents

Preposterous as this myth might sound, it is at the root of much of the confusion about XML namespaces. To make it a little easier to understand, we can restate it more lucidly as, "Myth #1: The XML namespaces recommendation requires an XML namespace to exist as a physical or conceptual entity."

At a superficial level, this myth is true. In its definition of XML namespaces, the recommendation states the following: "An XML namespace is a collection of names, identified by a URI reference [RFC2396], which are used in XML documents as element type and attribute names. XML namespaces differ from the 'namespaces' conventionally used in computing disciplines in that the XML version has internal structure and is not, mathematically speaking, a set." Thus, an XML namespace exists at least at the conceptual level.

At a deeper level, myth really is a myth, the above statement notwithstanding. Except for this statement, there is nothing in the recommendation that requires an XML namespace to exist as a physical or conceptual entity. What the recommendation requires is the existence of a qualifier—the XML namespace URI—that, in combination with an element type or attribute name, creates a universal (and universally unique) name. An XML namespace is simply a convenient (and unnecessary) stop on the road from prefixed name to universal name. Thus, while many readers spend their time looking for clues about XML namespaces—their structure, what names are in them, how to instantiate them, and so on—the recommendation spends its time discussing XML namespace URIs—how to declare them, how to associate them with element type and attribute names, and how to construct universal names with them. Small wonder that so many people are confused.

If you think in terms of universal names rather than in terms of XML namespaces, an XML namespace is nothing more than a collection of all the local parts of universal names that share the same XML namespace URI. Although such a collection is a short and logical step from universal names, it is a step in the wrong direction, as it points you down a road you never need to travel. Thus, it is better to ignore the definition (not to mention existence) of an XML namespace as a physical or conceptual entity and instead think about XML namespace URIs and universal names. In other words, to think of the XML namespaces recommendation not as "Namespaces in XML," but as "Universal Names in XML."

Myth #2: Universal names uniquely identify element types and attributes.

OK, this myth is a bit of a cheap shot, but it points out one of the reasons people want to know about the structure of an XML namespace, as well as reinforcing the potential ambiguities of invalid documents.

When a traditional namespace provides names to identify a set of objects, it usually provides names only to that set of objects and not to any other sets of objects. As a result, given a traditional namespace and a name from that namespace, it is usually possible to uniquely identify an object. This is not the case with XML namespaces, which provide names to both element types and attributes. That is, given the URI of an XML namespace and a name from that namespace—for example, {http://www.foo.org}bar—it is not possible to say whether the name identifies an element type or an attribute. This has led to much speculation about the structure of XML namespaces (see myth #6), since separating the names inside an XML namespace into separate sets of element type names and attribute names is one way to solve this problem. In practice, the problem is usually solved by the application, which knows whether it is looking at an element type or attribute name.

Technically, even the knowledge that a universal name applies to an element type or attribute is not quite enough for that name to uniquely identify a specific element type or attribute, even at the syntactic level. For example, consider the following document:

   <?xml version="1.0" ?>
   <A xmlns="http://www.foo.org/">
      <A>abcd</A>
   </A>

This document contains two elements with the universal name {http://www.foo.org/}A. Do these share a single element type or do they have two different element types? This ambiguity is nothing new, as it potentially exists for any document lacking a DTD. Fortunately, the ambiguity can be resolved through validation, just as it can when XML namespaces are not used. However, to guarantee that validation does resolve this ambiguity, the document must be constructed according to the following guidelines:

Declare all xmlns attributes in the DTD.
Use the same qualified names in the DTD and the body of the document.
Use one prefix per XML namespace.
Do not use the same prefix for more than one XML namespace.
Use at most one default XML namespace.

The first two guidelines are necessary to ensure that all names used in the body of the document are declared in the DTD. The latter three guidelines guarantee that a universal name always has the same qualified name, meaning that qualified names in the DTD are equivalent to universal names.

Myth #3: An XML namespace is an object; it has an interface

Because an XML namespace is "a collection of names," has "internal structure," and "is not, mathematically speaking, a set," there is a reasonable expectation that it has some sort of solidity—that like a DOM tree, you can instantiate it, ask it questions, and pass it to other applications. In other words, that it is an object (or collection of objects) and has an interface.

This would be a useful thing. It would mean that a few vendors could implement XML namespace objects and the rest of us could use them. After instantiating the object and initializing it with our own names, we could ask useful name-related questions, such as, "Does the element type name foo already exist in this namespace? If not, please add it," and "What integer is associated with the element type name bar? I'd like to use it to switch to the code to process a bar element," and "Could you give me the definition of a foobar attribute?"

However, this is not the case. Like the XML 1.0 recommendation, the XML namespaces recommendation specifies only a syntax. Any "XML namespace objects" would have to be layered on top of this syntax, just as the DOM is layered on top of the XML 1.0 syntax. Thus, this myth really is a myth: an XML namespace is not an object and it does not have an interface.

Myth #4: Unprefixed attribute names are in XML namespaces

There are two probable origins of this myth. The first is a simple wish for completeness—that is, that an XML namespace should include all related element type and attribute names. The second is the idea that an XML namespace is an object (it is not—see myth #3), which begs the question, "What are the member elements of the object? Do they include unprefixed attribute names?"

In fact, the XML namespace recommendation never resolves this myth because it never formally defines membership in an XML namespace. Instead, it defines a mapping from certain names in an XML document to an XML namespace and then states how to construct universal names from the mapped names. What is clear is that no mapping is defined for unprefixed attribute names—this is the meaning of the statement, "...default namespaces do not apply directly to attributes..."—and therefore that there is no way to construct universal names from unprefixed attribute names. The importance of this is that applications: (a) must not attempt to map unprefixed attribute names to the default XML namespace, and (b) must identify attributes with unprefixed names through their associated element type, just as they do in the absence of XML namespaces.

From a purely philosophical standpoint, it can be argued that unprefixed attribute names are not "in" an XML namespace. This is because, unlike prefixed names and unprefixed element type names, unprefixed attribute names are never mapped to an XML namespace and therefore are not members. It is also possible to argue the converse. The first argument is the non-normative Appendix A, which explicitly states that unprefixed attribute names are "in" an XML namespace. The second argument is the use of the word "directly" in the above quote, which implies that the default XML namespace applies indirectly, such as through unprefixed element type names. Fortunately, the resolution of this myth is unimportant, as it does not affect how documents that use XML namespaces are written or how namespace-aware applications process unprefixed attribute names.

Note that elsewhere the Namespaces FAQ states that unprefixed attribute names are not in any XML namespace. This is done for simplicity, as the presence or absence of XML namespaces in a document does not affect how unprefixed attribute names are written or processed.

Myth #5: The XML namespaces recommendation introduces "global attributes"

The XML namespaces recommendation discusses global attributes in Appendix A. This appendix is non-normative and global attributes are never mentioned in a normative part of the recommendation. Thus, the recommendation never formally introduces or defines the concept of global attributes. However, the concept of global attributes is necessary to understanding one of the reasons why attribute names can be prefixed and thus mapped to universal names.

"Global attributes" are an idea that pre-dates the XML namespaces recommendation and has never been clearly defined. One variation is that they are simply a declarative shorthand—that is, you declare a global attribute in a DTD (there is no syntax to actually do this) or schema and it applies to all element types in that DTD or schema. This would be useful, for example, if you wanted all element types to have a certain attribute.

The variation in Appendix A appears to be more flexible, allowing global attributes to "float" from one DTD or schema to another. For example, they might be defined in one schema and used on an element type in another schema. The XML namespaces recommendation specifically supports such attributes through qualified attribute names, which resolve to universal names. This allows these attributes to be recognized wherever they appear.

An example of this kind of global attribute is the version attribute in XSL Transformations (XSLT). XSLT supports a simplified syntax for its style sheets in which many of the XSLT elements are eliminated. The root element of such style sheets, which is not defined in XSLT, must use XSLT's version attribute to declare which version of XSLT it is using. In the following, xslt:version is a global attribute whose name belongs to the http://www.w3.org/1999/XSL/Transform namespace. This is different from the version attribute of the bar element type.

   <foo:bar
         xmlns:foo="http://www.foo.org/"
         xmlns:xslt="http://www.w3.org/1999/XSL/Transform"
         xslt:version="1.0"
         version="2.x">
      ...
   </foo:bar>

Although it is never explicitly stated in Appendix A, global attributes should always have the same type and semantics, regardless of the element type on which they occur. This represents a restriction to the XML 1.0 recommendation, which allows attributes on two different element types to have the same name but different types and semantics. However, it is the only way for global attributes to fulfill the stated motivation of XML namespaces as a way to support and reuse modular software. If an attribute identified by a universal name has a different type and semantics on each element type on which it occurs, it is impossible to write modular, reusable software to process it.