What Are XML Namespaces?

• A W3C recommendation: Namespaces in XML.
• A mechanism for making element type and attribute names globally unique.
• A way to distinguish element types and attributes from different document types that are mixed together in the same document.

How XML Namespaces Works:

In XML processing there is often a requirement to mix elements from different document types together in a single document. For example, a document type that represents a product catalog might want to use HTML elements to structure the catalog copy. The success of XML has resulted in the definition of a huge number of specialized document types, many of which are expressly designed to be used as part of larger “composite” document types.

This need to mix elements from different document types together immediately raises the problem of name conflicts: what if two document types use the same name for element types that are semantically different? For example, in the catalog document type there might be a <form> element that defines the physical form of the product being cataloged. If HTML was also used in the catalog copy there would be a potential conflict with the HTML <form> element. Thus there is a requirement to be able to create globally unique element type names.

XML Namespaces does this by binding local, or base , names to URIs, resulting in names that are guaranteed unique (because URIs form a globally-managed name space of names). For example, the name space URI for XHTML is “http://www.w3.org/1999/xhtml”. Thus the fully-qualified name for the XHTML <form> element is <http://www.w3.org/1999/xhtml:form>.

Of course, using URLs in tags is cumbersome at best, so XML Namespaces provides a way to create short versions of long namespace URLs for local use. These names are declared using “xmlns” attributes and then used in place of the URLs as the namespace prefix. For example, our catalog document might look like this:

The first “xmlns” attribute says that the URL given is the default namespace , which will be assumed for any element or attribute that doesn't have a namespace prefix. The “xmlns:html” says that the local prefix string “html” is mapped to the namespace URL for XHTML. In the document, the elements from the HTML document type are prefixed with the local “html” prefix. When the document is processed, the processor replaces the local prefix string “html” with the full URL, giving processing applications the fully-qualified names.

Note that there is nothing in the namespace declarations that tells you where the element types and attributes are defined—it is up to individual document types to specify what their namespace URLs are. For example, the XHTML specification defines the URL used above, as do many other specifications, but it also means that when you get a document with a particular namespace you just have to know what document type it reflects. In practice this tends not to be a problem because people creating or processing documents usually already know what namespaces will be used in those documents. But it does mean that there is currently no defined mechanism for getting from a namespace declaration to the formal specification for the document type that defines the names in the namespace.

Note also that there is no magic to the local prefix—it can be anything because it is simply a local mapping to the URL that is the true namespace name. So while most people might naturally use “html” as the local prefix for the HTML namespace, you cannot safely assume that “html” always means the XHTML namespace as declared above. Likewise, some processing tasks may require rewriting namespace prefixes. Thus namespace-aware processors must always use the fully-qualified namespace URI, not just the local prefix, for mapping processing to specific elements and attributes.