What is a xml namespace?

Because, back in 1997, some very influential persons in the W3C wanted them, and would not take no for an answer. Even when it was demonstrated, I dare say conclusively, that there were better ways to solve the "problem" they thought they had, they still wielded their influence to have their desires written up into a W3C Recommendation.

The biggest whopper in the by now extensive mythology surrounding XML Namespaces is that there is technical merit to them. (This is the downstream effect of a Recommendation simply existing and thus occupying mindspace - "gee, there's gotta be a (good) reason!" - as opposed to a forgetable footnote somewhere.)

Much pain, no gain.

When should we use them and when should we not?

You should never use them if you can help it. Unfortunately, the relentless promotion of this BAD[*] device by interested parties has fostered a clusterf*ck of specs today that make it practically impossible not to have to contend with XML namespaces at some point or another. So, even if you eschew XML namespaces yourself, you will find namespace-encrusted crud coming at you from all directions, or worse, toolsets that simply refuse to work unless you feed them such crud.

What are the common pitfalls when working with namespaces in XML?

One very common pitfall is in using Xpath expressions with documents where a namespace has been "defaulted": the namespace will have to be explicit in the expressions. Another issue is using them "correctly" when constructing documents: they create problems out of thin air.

XML namespaces are used for providing uniquely named elements and attributes in an XML document. They are defined in a W3C recommendation.[1][2] An XML instance may contain element or attribute names from more than one XML vocabulary. If each vocabulary is given a namespace, the ambiguity between identically named elements or attributes can be resolved.

A simple example would be to consider an XML instance that contained references to a customer and an ordered product. Both the customer element and the product element could have a child element named id. References to the id element would therefore be ambiguous; placing them in different namespaces would remove the ambiguity.

A namespace name is a uniform resource identifier (URI). Typically, the URI chosen for the namespace of a given XML vocabulary describes a resource under the control of the author or organization defining the vocabulary, such as a URL for the author's Web server. However, the namespace specification does not require nor suggest that the namespace URI be used to retrieve information; it is simply treated by an XML parser as a string. For example, the document at http://www.w3.org/1999/xhtml itself does not contain any code. It simply describes the XHTML namespace to human readers. Using a URI (such as "http://www.w3.org/1999/xhtml") to identify a namespace, rather than a simple string (such as "xhtml"), reduces the probability of different namespaces using duplicate identifiers.

Although the term namespace URI is widespread, the W3C Recommendation refers to it as the namespace name. The specification is not entirely prescriptive about the precise rules for namespace names (it does not explicitly say that parsers must reject documents where the namespace name is not a valid Uniform Resource Identifier), and many XML parsers allow any character string to be used. In version 1.1 of the recommendation, the namespace name becomes an Internationalized Resource Identifier, which licenses the use of non-ASCII characters that in practice were already accepted by nearly all XML software. The term namespace URI persists, however, not only in popular usage, but also in many other specifications from W3C and elsewhere.

Following publication of the Namespaces recommendation, there was an intensive debate about how a relative URI should be handled, with some intensely arguing that it should simply be treated as a character string, and others arguing with conviction that it should be turned into an absolute URI by resolving it against the base URI of the document.[3] The result of the debate was a ruling from W3C that relative URIs were deprecated.[4]

The use of URIs taking the form of URLs in the http scheme (such as http://www.w3.org/1999/xhtml) is common, despite the absence of any formal relationship with the HTTP protocol. The Namespaces specification does not say what should happen if such a URL is dereferenced (that is, if software attempts to retrieve a document from this location). One convention adopted by some users is to place an RDDL document at the location.[5] In general, however, users should assume that the namespace URI is simply a name, not the address of a document on the Web.

An XML namespace is declared using the reserved XML attribute xmlns or xmlns:prefix, the value of which must be a valid namespace name.

For example, the following declaration maps the "xhtml:" prefix to the XHTML namespace:

Any element or attribute whose name starts with the prefix "xhtml:" is considered to be in the XHTML namespace, if it or an ancestor has the above namespace declaration.

It is also possible to declare a default namespace. For example:

In this case, any element without a namespace prefix is considered to be in the XHTML namespace, if it or an ancestor has the above default namespace declaration.

If there is no default namespace declaration in scope, the namespace name has no value.[6] In that case, an element without an explicit namespace prefix is considered not to be in any namespace.

Attributes are never subject to the default namespace. An attribute without an explicit namespace prefix is considered not to be in any namespace.

Different specifications have taken different approaches on how namespace information is presented to applications.

Nearly all programming models allow the name of an element or attribute node to be retrieved as a three-part name: the local name, the namespace prefix, and the namespace URI. Applications should avoid attaching any significance to the choice of prefix, but the information is provided because it can be helpful to human readers. Names are considered equal if the namespace URI and local name match.

In addition, most models provide some way of determining which namespaces have been declared for a given element. This information is needed because some XML vocabularies allow qualified names (containing namespace prefixes) to appear in the content of elements or attributes, as well as in their names. There are three main ways this information can be provided:

Other articles in this series:

XML Schema: Understanding Datatypes

XML Schema: Understanding Structures

Downloads for this article:

Oracle XML Developer's Kit

Oracle JDeveloper 10g (includes visual XML Schema editor)

As defined by the W3C Namespaces in XML Recommendation , an XML namespace is a collection of XML elements and attributes identified by an Internationalized Resource Identifier (IRI); this collection is often referred to as an XML "vocabulary."

One of the primary motivations for defining an XML namespace is to avoid naming conflicts when using and re-using multiple vocabularies. XML Schema is used to create a vocabulary for an XML instance, and uses namespaces heavily. Thus, having a sound grasp of the namespace concept is essential for understanding XML Schema and instance validation overall.

Namespaces are similar to packages in Java in several ways:

Thus, we see that the namespaces in XML concept is not very different from packages in Java. This correlation is intended to simplify the understanding of namespaces in XML and to help you visualize the namespaces concept.

In this article, you will learn:

Namespaces are declared as an attribute of an element. It is not mandatory to declare namespaces only at the root element; rather it could be declared at any element in the XML document. The scope of a declared namespace begins at the element where it is declared and applies to the entire content of that element, unless overridden by another namespace declaration with the same prefix name—where, the content of an element is the content between the and of that element. A namespace is declared as follows:

In the attribute xmlns:pfx, xmlns is like a reserved word, which is used only to declare a namespace. In other words, xmlns is used for binding namespaces, and is not itself bound to any namespace. Therefore, the above example is read as binding the prefix "pfx" with the namespace "http://www.foo.com."

It is a convention to use XSD or XS as a prefix for the XML Schema namespace, but that decision is purely personal. One can choose to use a prefix ABC for the XML Schema namespace, which is legal, but doesn't make much sense. Using meaningful namespace prefixes add clarity to the XML document. Note that the prefixes are used only as a placeholder and must be expanded by the namespace-aware XML parser to use the actual namespace bound to the prefix. In Java analogy, a namespace binding can be correlated to declaring a variable, and wherever the variable is referenced, it is replaced by the value it was assigned.

In our previous namespace declaration example, wherever the prefix "pfx" is referenced within the namespace declaration scope, it is expanded to the actual namespace( http://www.foo.com) to which it was bound:

In Java: String pfx = "http://www.library.com"

In XML:

Although a namespace usually looks like a URL, that doesn't mean that one must be connected to the Internet to actually declare and use namespaces. Rather, the namespace is intended to serve as a virtual "container" for vocabulary and un-displayed content that can be shared in the Internet space. In the Internet space URLs are unique—hence you would usually choose to use URLs to uniquely identify namespaces. Typing the namespace URL in a browser doesn't mean it would show all the elements and attributes in that namespace; it's just a concept.

But here's a twist: although the W3C Namespaces in XML Recommendation declares that the namespace name should be an IRI, it enforces no such constraint. Therefore, I could also use something like:

which is perfectly legal.

By now it should be clear that to use a namespace, we first bind it with a prefix and then use that prefix wherever required. But why can't we use the namespaces to qualify the elements or attributes from the start? First, because namespaces—being IRIs—are quite long and thus would hopelessly clutter the XML document. Second and most important, because it might have a severe impact on the syntax, or to be specific, on the production rules of XML—the reason being that an IRI might have characters that are not allowed in XML tags per the W3C XML 1.0 Recommendation .

Below the elements Title and Author are associated with the Namespace http://www.library.com:

In the example below, the elements Title and Author of Sherlock Holmes - IIIand Sherlock Holmes - I are associated with the namespace http://www.library.com and the elements Title and Author of Sherlock Holmes - II are associated with the namespace http://www.otherlibrary.com.

The W3C Namespaces in XML Recommendation enforces some namespace constraints:

The following violates both these constraints:

[Error]: prefix lib not bound to a namespace. [Inadvisable]: prefix XmlLibrary begins with 'Xml.'

Default Namespace (Not Default Namespaces)

It would be painful to repeatedly qualify an element or attribute you wish to use from a namespace. In such cases, you can declare a {default namespace} instead. Remember, at any point in time, there can be only one {default namespace} in existence. Therefore, the term "Default Namespaces" is inherently incorrect.

Declaring a {default namespace} means that any element within the scope of the {default namespace} declaration will be qualified implicitly, if it is not already qualified explicitly using a prefix. As with prefixed namespaces, a {default namespace} can be overridden too. A {default namespace} is declared as follows:

In this case the elements Book, Title, and Author are associated with the Namespace http://www.library.com.

Remember, the scope of a namespace begins at the element where it is declared. Therefore, the element Book is also associated with the {default namespace}, as it has no prefix.

In the above, the elements Book, and Title, and Author of Sherlock Holmes - III and Sherlock Holmes - I are associated with the namespace http://www.library.com and the elements purchase,Title, and Author of Sherlock Holmes - II are associated with the namespacehttp://www.otherlibrary.com.

Default Namespace and Attributes

Default namespaces do not apply to attributes; therefore, to apply a namespace to an attribute the attribute must be explicitly qualified. Here the attribute isbn has {no namespace} whereas the attribute cover is associated with the namespacehttp://www.library.com.

Unbinding an already-bound prefix is not allowed per the W3C Namespaces in XML 1.0 Recommendation, but is allowed per W3C Namespaces in XML 1.1 Recommendation. There was no reason why this should not have been allowed in 1.0, but the mistake has been rectified in 1.1. It is necessary to know this difference because not many XML parsers yet support Namespaces in XML 1.1.

Although there were some differences in unbinding prefixed namespaces, both versions allow you to unbind or remove the already declared {default namespace} by overriding it with another {default namespace} declaration, where the namespace in the overriding declaration is empty. Unbinding a namespace is as good as the namespace not being declared at all. Here the elements Book, Title, and Author of Sherlock Holmes - III and Sherlock Holmes - I are associated with the namespacehttp://www.library.com and the elements purchase, Title, and Author of Sherlock Holmes - II have {no namespace}:

Here's an invalid example of unbinding a prefix per Namespaces in XML 1.0 spec, but a valid example per Namespaces in XML 1.1:

From this point on, the prefix lib cannot be used in the XML document because it is now undeclared as long as you are in the scope of element purchase. Of course, you can definitely re-declare it.

No namespace exists when there is no default namespace in scope. A {default namespace} is one that is declared explicitly using xmlns. When a {default namespace} has not been declared at all using xmlns, it is incorrect to say that the elements are in {default namespace}. In such cases, we say that the elements are in {no namespace}. {no namespace} also applies when an already declared {default namespace} is undeclared.

In summary:

Thus far we have seen how to declare and use an existing namespace. Now let's examine how to create a new namespace and add elements and attributes to it using XML Schema.

XML Schema is an XML before it's anything else. In other words, like any other XML document, XML Schema is built with elements and attributes. This "building material" must come from the namespace http://www.w3.org/2001/XMLSchema, which is a declared and reserved namespace that contains elements and attributes as defined in W3C XML Schema Structures Specification and W3C XML Schema Datatypes Specification . You should not add elements or attributes to this namespace.

Using these building blocks we can create new elements and attributes as required and enforce the required constraints on these elements and attributes an d keep them in some namespace. (See Figure 1 ) XML Schema calls this particular namespace as the {target namespace}, or the namespace where the newly created elements and attributes will reside.

Figure 1: Elements and attributes in XML Schema namespace are used to write an XML Schema document, which generates elements and attributes as defined by user and puts them in {target namespace}. This {target namespace} is then used to validate the XML instance.

This {target namespace} is referred from the XML instance for ensuring validity of the instance document. (See Figure 2 .) During validation, the Validator verifies that the elements/attributes used in the instance exist in the declared namespace, and also checks for any other constraint on their structure and datatype.

Figure 2: From XML Schema to XML Schema instance

In XML Schema we can choose to specify whether the instance document must qualify all the elements and attributes, or must qualify only the globally declared elements and attributes. Regardless of what we choose, the entire instance would be validated. So why do we have two choices?

The answer is "manageability." When we choose qualified , we are specifying that all the elements and attributes in the instance must have a namespace, which in turn adds namespace complexity to instance. If say that the schema is modified by making some local declarations global and/or making some global declarations local, then the instance documents are not affected at all. In contrast, when we choose unqualified , we are specifying that only the globally declared elements and attributes in the instance must have a namespace, which in turn hides the namespace complexity from the instance. But in this case, if say, the schema is modified by making some local declarations global and/or making some global declarations local, then all instance documents are affected—and the instance is no longer valid. The XML Schema Validator would report validation errors if we try to validate this instance against the modified XML Schema. Therefore, the namespaces must be fixed in the instance per the modification done in XML Schema to make the instance valid again.

The declarations that are the immediate children of the element are the global declarations, and the rest are local declarations. In the above example, Book and BookType are declared globally whereas Title and Author are local declarations.

We can express the choice between qualified and unqualified by setting the schema element attributes elementFormDefault and attributeFormDefault to either qualified or unqualified.

When elementFormDefault is set to qualified , it implies that in the instance of this grammar all the elements must be explicitly qualified, either by using a prefix or setting a {default namespace}. An unqualified setting means that only the globally declared elements must be explicitly qualified, and the locally declared elements must not be qualified. Qualifying a local declaration in this case is an error. Similarly, when attributeFormDefault is set to qualified , all attributes in the instance document must be explicitly qualified using a prefix.

Remember, {default namespace} doesn't apply to attributes; hence, we can't use a {default namespace} declaration to qualify attributes.Unqualified seems to imply being in the namespace by virtue of the containing element. This is interesting, isn't it?

In the following diagrams, the concept symbol space is similar to the non-normative concept of namespace partition. For example, if a namespace is like a refrigerator, then the symbol spaces are the shelves in the refrigerator. Just as shelves partition the entire space in a refrigerator, the symbol spaces partition the namespace.

There are three primary partitions in a namespace: one for global element declarations, one for global attribute declarations, and one for global type declarations (complexType/simpleType). This arrangement implies we can have a global element, a global attribute, and a global type all have the same name, and still co-exist in a {target namespace} without any name collisions. Further, every global element and a global complexType have their own symbol space to contain the local declarations.

Let's examine the four possible combinations of values for the pair of attributes elementFormDefault and attributeFormDefault.

Case 1: elementFormDefault=qualified, attributeFormDefault=qualified

Here the {target namespace} directly contains all the elements and attributes; therefore, in the instance, all the elements and attributes must be qualified.

Case 2: elementFormDefault=qualified, attributeFormDefault=unqualified

Here the {target namespace} directly contains all the elements and the corresponding attributes for these elements are contained in the symbol space of the respective elements. Therefore, in the instance, only the elements must be qualified and the attributes must not be qualified, unless the attribute is declared globally.

Case 3: elementFormDefault=unqualified, attributeFormDefault=qualified

Here the {target namespace} directly contains all the attributes and only the globally declared elements, which in turn contains its child elements in its symbol space. Therefore, in the instance, only the globally declared elements and all the attributes must be qualified.

XML Namespaces provide a method to avoid element name conflicts.

In XML, element names are defined by the developer. This often results in a conflict when trying to mix XML documents from different XML applications.

This XML carries HTML table information:

This XML carries information about a table (a piece of furniture):

If these XML fragments were added together, there would be a name conflict. Both contain a

element, but the elements have different content and meaning.

A user or an XML application will not know how to handle these differences.

Name conflicts in XML can easily be avoided using a name prefix.

This XML carries information about an HTML table, and a piece of furniture:

In the example above, there will be no conflict because the two

elements have different names.

When using prefixes in XML, a namespace for the prefix must be defined.

The namespace can be defined by an xmlns attribute in the start tag of an element.

The namespace declaration has the following syntax. xmlns:prefix="URI".

In the example above:

The xmlns attribute in the first

element gives the h: prefix a qualified namespace.

The xmlns attribute in the second

element gives the f: prefix a qualified namespace.

When a namespace is defined for an element, all child elements with the same prefix are associated with the same namespace.

Namespaces can also be declared in the XML root element:

Note: The namespace URI is not used by the parser to look up information.

The purpose of using an URI is to give the namespace a unique name.

However, companies often use the namespace as a pointer to a web page containing namespace information.

A Uniform Resource Identifier (URI) is a string of characters which identifies an Internet Resource.

The most common URI is the Uniform Resource Locator (URL) which identifies an Internet domain address. Another, not so common type of URI is the Uniform Resource Name (URN).

Defining a default namespace for an element saves us from using prefixes in all the child elements. It has the following syntax:

This XML carries HTML table information:

This XML carries information about a piece of furniture:

XSLT is a language that can be used to transform XML documents into other formats.

The XML document below, is a document used to transform XML into HTML.

The namespace "http://www.w3.org/1999/XSL/Transform" identifies XSLT elements inside an HTML document:

If you want to learn more about XSLT, please read our XSLT Tutorial.