XML Namespaces FAQ

Copyright 2000-2009 by Ronald Bourret

Last updated January, 2009

FAQs

Part I: Overview

Section 1.0: Executive Summary

1.1 Can you give me an executive summary of what XML namespaces are?

Sure. Here it is in five easy bullet points.

1.2 Can you give me an executive summary of what XML namespaces are not?

They aren't a cure of cancer, they aren't a way to win the lottery, and they aren't a direct cause of world peace. They also aren't very difficult to understand or use. Two things that XML namespaces are not have caused a lot of confusion, so we'll mention them here:

Section 2.0: Traditional Namespaces

2.1 What is a traditional namespace?

Before discussing XML namespaces, it is useful to discuss namespaces in general. In this FAQ, we will refer to such namespaces as traditional namespaces. We will refer to XML namespaces as XML namespaces. The word namespace can refer to either a traditional namespace or an XML namespace, depending on context, but will generally refer to an XML namespace.

A traditional namespace is a set of zero or more names, each of which must be unique within the namespace and constructed according to the rules (if any) of the namespace. For example, the names of element types in an XML document inhabit a traditional namespace, as do the names of tables in a relational database and the names of class variables in a Java class. Traditional namespaces also occur outside the field of computer science -- for example, the names of people could be thought to inhabit a traditional namespace, as could the names of species.

2.2 What is the relationship between different traditional namespaces?

They are disjoint -- that is, they are not related. Because of this, a name in one traditional namespace does not collide with the same name in a different traditional namespace. This property is useful to applications that have multiple sets of names. By assigning each set of names to a different traditional namespace, they can allow the same name to occur in each set of names without fear of collision.

For example, in the following XML document, there is no conflict between the three different uses of the name Value.

  <AuctionItem>
     <Title Value="486Laptop"/>
     <Category Value="Computers"/>
     <Value>$100</Value>
  </AuctionItem>

This is because an XML document has one traditional namespace for element type names and, for each element type, one traditional namespace for the names of the attributes that apply to that element type. Thus, the two Value attribute names don't conflict because each is assigned to a different traditional namespace -- the first to the attribute namespace for the Title element type and the second to the attribute namespace for the Category element type. Furthermore, neither of the Value attribute names conflicts with the Value element type name because element type names are kept in a traditional namespace that is separate from the attribute namespaces.

Other examples of applications that use multiple traditional namespaces include:

2.3 What are traditional namespaces used for?

Perhaps the most common (computer science) use of traditional namespaces is to provide a container for a set of identifiers. For example, traditional namespaces are used to contain the names (identifiers) of element types in an XML document, the names of class variables in a Java class, and the names of tables in a relational database. Traditional namespaces are useful in this regard because of their requirement that each name in the namespace be unique. Thus, when a new name (identifier) is added to the namespace, the uniqueness of the identifier can be verified by checking that the name does not already exist in the namespace.

(Note that just because a set of objects draws its names from some traditional namespace does not mean that those names uniquely identify the objects. For example, two different people can share the same name, as can two different element nodes in a DOM tree, which use element type names as their names. For the names in a traditional namespace to uniquely identify the objects in a set, the objects in the set must draw their names only from that namespace and no name can be applied to more than one object. In practice, the names from a single traditional namespace are only used to identify the objects in a single set; otherwise, additional information must be stored stating which names apply to which set.)

Section 3.0: XML Namespaces

3.1 What is the purpose of XML namespaces?

XML namespaces were originally designed to provide universally unique names for elements and attributes. In practice, they are used in XML technologies when unique names are needed, such as for complex type names in XML Schemas and function names in XQuery. This FAQ focuses on the first case, but most of what it discusses applies to the broader cases as well.

As an example of why XML namespaces are needed, consider the following two XML documents:

  <?xml version="1.0" ?>
  <Address>
     <Street>Wilhelminenstr. 7</Street>
     <City>Darmstadt</City>
     <State>Hessen</State>
     <Country>Germany</Country>
     <PostalCode>D-64285</PostalCode>
  </Address>

and:

  <?xml version="1.0" ?>
  <Server>
     <Name>OurWebServer</Name>
     <Address>123.45.67.8</Address>
  </Server>

Each document uses a different XML language and each language defines an Address element type. Each of these Address element types is different -- that is, each has a different content model, a different meaning, and is interpreted by an application in a different way. This is not a problem as long as these element types exist only in separate documents. But what if we want to use them in the same document, such as a list of departments, their addresses, and their Web servers? How does an application know which Address element type it is processing?

One solution is to simply rename one of the Address element types -- for example, we could rename the second element type IPAddress. However, this is not a useful long term solution. One of the hopes of XML is that people will standardize XML languages for various subject areas and write modular code to process those languages. By reusing existing languages and code, people can quickly define new languages and write applications that process them. If we rename the second Address element type to IPAddress, we will break any code that expects the old name.

A better answer is to assign each language (including its Address element type) to a different namespace. This allows us to continue using the Address name in each language, but to distinguish between the two different element types. The mechanism by which we do this is XML namespaces. For example, the following document uses XML namespaces to distinguish between the two different element types named Address.

  <Department>
     <Name>DVS1</Name>
     <addr:Address xmlns:addr="http://www.tu-darmstadt.de/ito/addresses">
        <addr:Street>Wilhelminenstr. 7</addr:Street>
        <addr:City>Darmstadt</addr:City>
        <addr:State>Hessen</addr:State>
        <addr:Country>Germany</addr:Country>
        <addr:PostalCode>D-64285</addr:PostalCode>
     </addr:Address>
     <serv:Server xmlns:serv="http://www.tu-darmstadt.de/ito/servers">
        <serv:Name>OurWebServer</serv:Name>
        <serv:Address>123.45.67.8</serv:Address>
     </serv:Server>
  </Department>

The first Address element type name belongs to the http://www.tu-darmstadt.de/ito/addresses XML namespace. It has an expanded (two-part) name of "http://www.tu-darmstadt.de/ito/addresses" plus "Address". (Following the convention in an article by James Clark, we write this as {http://www.tu-darmstadt.de/ito/addresses}Address.) The second Address element type name belongs to the http://www.tu-darmstadt.de/ito/servers XML namespace and has an expanded name of {http://www.tu-darmstadt.de/ito/servers}Address. Thus, each expanded name is unique, meeting the requirement that each element type in an XML document have a unique name.

(Note that by assigning each Address name to an XML namespace, we actually change the name to a two-part name consisting of the name of the XML namespace plus the name Address. This means that any code that recognizes just the name Address will need to be changed to recognize the new two-part name. However, this only needs to be done once, as the two-part name (expanded name) is universally unique. For more information about the uniqueness of expanded names, see question 12.16; for more information about processing expanded names, see question 11.1.)

3.2 What are some examples of how XML namespaces are used?

XML namespaces are being used in a number of ways. For example:

3.3 What is an XML namespace?

An XML namespace is a collection of element type and attribute names. The collection itself is unimportant -- in fact, a reasonable argument can be made that XML namespaces don't actually exist as physical or conceptual entities (see Namespace Myth #1). What is important is the name of the XML namespace, which is a URI reference. This allows XML namespaces to provide a two-part naming system for element types and attributes. The first part of the name is the URI reference used to identify the XML namespace -- the namespace name. The second part is the element type or attribute name itself -- the local part, also known as the local name. Together, they form the expanded name.

This two-part naming system is the only thing defined by the XML namespaces recommendation.

3.4 Does the XML namespaces recommendation define anything except a two-part naming system for element types and attributes?

No.

This is a very important point and a source of much confusion, so we will repeat it:

THE XML NAMESPACES RECOMMENDATION DOES NOT DEFINE ANYTHING EXCEPT A TWO-PART NAMING SYSTEM FOR ELEMENT TYPES AND ATTRIBUTES.

In particular, they do not provide or define any of the following:

3.5 What do XML namespaces actually contain?

XML namespaces are collections of names, nothing more. That is, they contain the names of element types and attributes, not the elements or attributes themselves. For example, consider the following document.

  <foo:A xmlns:foo="http://www.foo.org/">
     <B foo:C="foo" D="bar"/>
  </foo:A>

The element type name A and the attribute name C are in the http://www.foo.org/ namespace because they are mapped there by the foo prefix. The element type name B and the attribute name D are not in any XML namespace because no prefix maps them there. On the other hand, the elements A and B and the attributes C and D are not in any XML namespace, even though they are physically within the scope of the http://www.foo.org/ namespace declaration. This is because XML namespaces contain names, not elements or attributes.

XML namespaces also do not contain the definitions of the element types or attributes. This is an important difference, as many people are tempted to think of an XML namespace as a schema, which it is not. (For more information, see Namespace Myth #8.)

(For information about the structure of an XML namespace, see Namespace Myth #6.)

3.6 Are the names of all element types and attributes in some XML namespace?

No.

If an element type or attribute name is not specifically declared to be in an XML namespace -- that is, it is unprefixed and (in the case of element type names) there is no default XML namespace -- then that name is not in any XML namespace. If you want, you can think of it as having a null URI reference as its name, although no "null" XML namespace actually exists. For example, in the following, the element type name B and the attribute names C and E are not in any XML namespace:

  <foo:A xmlns:foo="http://www.foo.org/">
     <B C="bar"/>
     <foo:D E="bar"/>
  </foo:A>

For more information about unprefixed attribute names and XML namespaces, see Namespace Myth #4.

3.7 Do XML namespaces apply to entity names, notation names, or processing instruction targets?

No.

XML namespaces apply only to element type and attribute names. Furthermore, in an XML document that conforms to the XML namespaces recommendation, entity names, notation names, and processing instruction targets must not contain colons.

3.8 Who can create an XML namespace?

Anybody can create an XML namespace -- all you need to do is assign a URI reference as its name and decide what element type and attribute names are in it. The URI this is referred to must be under your control and should not be being used to identify a different XML namespace, such as by a coworker.

(In practice, most people who create XML namespaces also describe the element types and attributes whose names are in it -- their content models and types, their semantics, and so on. However, this is not part of the process of creating an XML namespace, nor does the XML namespace include or provide a way to discover such information.)

3.9 Do I need to use XML namespaces?

Maybe, maybe not.

If you don't have any naming conflicts in the XML documents you are using today, as is often the case with documents used inside a single organization, then you probably don't need to use XML namespaces. However, if you do have conflicts today, or if you expect conflicts in the future due to distributing your documents outside your organization or bringing outside documents into your organization, then you should probably use XML namespaces.

Regardless of whether you use XML namespaces in your own documents, it is likely that you will use them in conjunction with some other XML technology, such as XSL, XHTML, or XML Schemas. For example, the following XSLT (XSL Transformations) stylesheet uses XML namespaces to distinguish between element types defined in XSLT and those defined elsewhere:

  <xsl:stylesheet version="1.0"
                 xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
     <xsl:template match="Address">
     <!-- The Addresses element type is not part of the XSLT namespace. -->
     <Addresses>
        <xsl:apply-templates/>
     </Addresses>
     </xsl:template>
  </xsl:stylesheet>

3.10 What is the relationship between XML namespaces and the XML 1.0 recommendation?

Although the XML 1.0 recommendation anticipated the need for XML namespaces by noting that element type and attribute names should not include colons, it did not actually support XML namespaces. Thus, XML namespaces are layered on top of XML 1.0. In particular, any XML document that uses XML namespaces is a legal XML 1.0 document and can be interpreted as such in the absence of XML namespaces. For example, consider the following document:

  <foo:A xmlns:foo="http://www.foo.org/">
     <foo:B foo:C="bar"/>
  </foo:A>

If this document is processed by a namespace-unaware processor, that processor will see two elements whose names are foo:A and foo:B. The foo:A element has an attribute named xmlns:foo and the foo:B element has an attribute named foo:C. On the other hand, a namespace-aware processor will see two elements with expanded names {http://www.foo.org}A and {http://www.foo.org}B. The {http://www.foo.org}A does not have any attributes; instead, it has a namespace declaration that maps the foo prefix to the URI reference http://www.foo.org. The {http://www.foo.org}B element has an attribute named {http://www.foo.org}C.

Needless to say, this has led to a certain amount of confusion. One area of confusion is the relationship between XML namespaces and validating XML documents against DTDs. This occurs because the XML namespaces recommendation did not describe how to use XML namespaces with DTDs. (For more information, see section 7.) Fortunately, a similar situation does not occur with XML schema languages, as all of these support XML namespaces.

The other main area of confusion is in recommendations and specifications such as DOM and SAX whose first version predates the XML namespaces recommendation. Although these have since been updated to include XML namespace support, the solutions have not always been pretty due to backwards compatibility requirements. All recommendations in the XML family now support XML namespaces.

3.11 What are the differences between versions 1.0 and 1.1 of the XML namespaces recommendation?

There are only two substantial differences between XML namespaces 1.0 and XML namespaces 1.1:

NOTE: As of this writing (January, 2007), Namespaces in XML 1.1 does not appear to be widely implemented. Before using it, check the software you are using to see if it is supported. And if you are exchanging documents with others, make sure their software supports it as well.

Part II: Declaring and Using XML Namespaces

Section 4.0: Declaring XML Namespaces in an XML Document

4.1 How do I declare an XML namespace in an XML document?

To declare an XML namespace, you use an attribute whose name has the form:

  xmlns:<i>prefix</i>
        --OR--
  xmlns

These attributes are often called xmlns attributes and their value is the name of the XML namespace being declared; this is a URI reference. The first form of the attribute (xmlns:prefix) declares a prefix to be associated with the XML namespace. The second form (xmlns) declares that the specified namespace is the default XML namespace.

For example, the following declares two XML namespaces, named http://www.tu-darmstadt.de/ito/addresses and http://www.tu-darmstadt.de/ito/servers. The first declaration associates the addr prefix with the http://www.tu-darmstadt.de/ito/addresses namespace and the second declaration states that the http://www.tu-darmstadt.de/ito/servers namespace is the default XML namespace.

  <Department
       xmlns:addr="http://www.tu-darmstadt.de/ito/addresses"
       xmlns="http://www.tu-darmstadt.de/ito/servers">

NOTE: Technically, xmlns attributes are not attributes at all -- they are XML namespace declarations that just happen to look like attributes. Unfortunately, they are not treated consistently by the various XML recommendations, which means that you must be careful when writing an XML application.

For example, in the XML Information Set (http://www.w3.org/TR/xml-infoset), xmlns "attributes" do not appear as attribute information items. Instead, they appear as namespace declaration information items. On the other hand, DOM Level 2, DOM Level 3, and SAX 2.0 treat namespace attributes somewhat ambiguously. In SAX 2.0, an application can instruct the parser to return xmlns "attributes" along with other attributes, or omit them from the list of attributes. Similarly, while DOM Level 2 sets namespace information based on xmlns "attributes", it also forces applications to manually add namespace declarations using the same mechanism the application would use to set any other attributes. (This problem is solved in DOM Level 3 with the Document.normalizeDocument method, which adds the xmlns attributes.)

4.2 Where can I declare an XML namespace?

You can declare an XML namespace on any element in an XML document. The namespace is in scope for that element and all its descendants unless it is overridden (see question 4.5 and question 4.6) or undeclared (see question 4.7 and question 4.8). For more information about scope, see section 6.

4.3 Can I use an attribute default in a DTD to declare an XML namespace?

Yes.

For example, the following uses the FIXED attribute xmlns:foo on the A element type to associate the foo prefix with the http://www.foo.org/ namespace. The effect of this is that both A and B are in the http://www.foo.org/ namespace.

  <?xml version="1.0" ?>
  <!DOCTYPE foo:A [
     <!ELEMENT foo:A (foo:B)>
     <!ATTLIST foo:A
               xmlns:foo CDATA #FIXED "http://www.foo.org/">
     <!ELEMENT foo:B (#PCDATA)>
  ]>
  <!-- foo prefix declared through default attribute. -->
  <foo:A>
     <foo:B>abc</foo:B>
  </foo:A>

IMPORTANT: You should be very careful about placing XML namespace declarations only in external entities (external DTDs) or in parameter entities, including parameter entities in the internal subset (internal DTD). The reason for this is that non-validating parsers are not required to read external entities or parameter entities. For example, suppose the preceding DTD was placed in an external entity (foo.dtd) and that the document was processed by a non-validating parser that did not read foo.dtd. This would result in a namespace error because the foo prefix was never declared:

  <?xml version="1.0" ?>
  <!-- foo.dtd might not be read by non-validating parsers. -->
  <!DOCTYPE foo:A SYSTEM "foo.dtd">
  <!-- foo prefix not declared unless foo.dtd is read. -->
  <foo:A>
     <foo:B>abc</foo:B>
  </foo:A>

Since most real-world DTDs are external, you can avoid this problem by placing your namespace declaration in both the DTD and the document itself. For example:

DTD:
----
   <!ELEMENT foo:A (foo:B)>
   <!-- Declare the namespace in the DTD. -->
   <!ATTLIST foo:A
             xmlns:foo CDATA #FIXED "http://www.foo.org/">
   <!ELEMENT foo:B (#PCDATA)>

XML document:
-------------
   <!DOCTYPE foo:A SYSTEM "foo.dtd">
   <!-- Declare the namespace in the document. -->
   <foo:A xmlns:foo="http://www.foo.org/">
      <foo:B>abc</foo:B>
   </foo:A>

The document is always namespace valid, regardless of whether the DTD is read, because the namespace declaration is in the document itself. In addition, the document is valid against the DTD because the xmlns:foo attribute is declared in the DTD. The situation for XML Schemas is analogous. For more information about XML namespaces and DTDs, see section 7. For more information about XML namespaces and XML Schemas, see section 8.

4.4 Do the default values of xmlns attributes declared in the DTD apply to the DTD?

No.

Declaring a default value of an xmlns attribute in the DTD does not declare an XML namespace for the DTD. (In fact, no XML namespace declarations apply to DTDs.) Instead, these defaults (declarations) take effect only when the attribute is instantiated on an element. For example:

  <?xml version="1.0" ?>
  <!DOCTYPE foo:A [
     <!ELEMENT foo:A (foo:B)>
     <!ATTLIST foo:A
               xmlns:foo CDATA #FIXED "http://www.foo.org/">
     <!ELEMENT foo:B (#PCDATA)>
  ]>
  <foo:A>  <========== Namespace declaration takes effect here.
     <foo:B>abc</foo:B>
  </foo:A>  <========= Namespace declaration ends here.

For more information, see question 7.2. (Note that an earlier version of MSXML (the parser used by Internet Explorer) did use fixed xmlns attribute declarations as XML namespace declarations, but that this was removed in MSXML 4. For more information, see question 10.6.)

4.5 How do I override an XML namespace declaration that uses a prefix?

To override the prefix used in an XML namespace declaration, you simply declare another XML namespace with the same prefix. For example, in the following, the foo prefix is associated with the http://www.foo.org/ namespace on the A and B elements and the http://www.bar.org/ namespace on the C and D elements. That is, the names A and B are in the http://www.foo.org/ namespace and the names C and D are in the http://www.bar.org/ namespace.

  <foo:A xmlns:foo="http://www.foo.org/">
     <foo:B>
        <foo:C xmlns:foo="http://www.bar.org/">
           <foo:D>abcd</foo:D>
        </foo:C>
     </foo:B>
  </foo:A>

In general, this leads to documents that are confusing to read and should be avoided.

4.6 How do I override a default XML namespace declaration?

To override the current default XML namespace, you simply declare another XML namespace as the default. For example, in the following, the default XML namespace is the http://www.foo.org/ namespace on the A and B elements and the http://www.bar.org/ namespace on the C and D elements. That is, the names A and B are in the http://www.foo.org/ namespace and the names C and D are in the http://www.bar.org/ namespace.

  <A xmlns="http://www.foo.org/">
     <B>
        <C xmlns="http://www.bar.org/">
           <D>abcd</D>
        </C>
     </B>
  </A>

Using multiple default XML namespaces can lead to documents that are confusing to read and should be done carefully. For more information, see question 5.4.

4.7 How do I undeclare an XML namespace prefix?

In version 1.0 of the XML namespaces recommendation, you cannot "undeclare" an XML namespace prefix. It remains in scope until the end of the element on which it was declared unless it is overridden. Furthermore, trying to undeclare a prefix by redeclaring it with an empty (zero-length) URI reference results in a namespace error. For example:

  <foo:A xmlns:foo="http://www.foo.org/">
     <foo:B>
        <foo:C xmlns:foo="">   <==== This is an error in v1.0, legal in v1.1.
           <foo:D>abcd</foo:D>
        </foo:C>
     </foo:B>
  </foo:A>

In version 1.1 of the XML namespaces recommendation, you can undeclare an XML namespace prefix by redeclaring it with an empty name. For example, in the above document, the XML namespace declaration xmlns:foo="" is legal and removes the mapping from the foo prefix to http://www.foo.org. Because of this, the use of the foo prefix in the foo:C and foo:D elements results in a namespace error.

4.8 How do I undeclare the default XML namespace?

To "undeclare" the default XML namespace, you declare a default XML namespace with an empty (zero-length) URI reference. Within the scope of this declaration, unprefixed element type names do not belong to any XML namespace. For example, in the following, the default XML namespace is the http://www.foo.org/ for the A and B elements and there is no default XML namespace for the C and D elements. That is, the names A and B are in the http://www.foo.org/ namespace and the names C and D are not in any XML namespace.

  <A xmlns="http://www.foo.org/">
     <B>
        <C xmlns="">
           <D>abcd</D>
        </C>
     </B>
  </A>

4.9 Why are special attributes used to declare XML namespaces?

I don't know the answer to this question, but the likely reason is that the hope that they would simplify the process of moving fragments from one document to another document. An early draft of the XML namespaces recommendation proposed using processing instructions to declare XML namespaces. While these were simple to read and process, they weren't easy to move to other documents. Attributes, on the other hand, are intimately attached to the elements being moved.

Unfortunately, this hasn't worked as well as was hoped. For example, consider the following XML document:

  <foo:A xmlns:foo="http://www.foo.org/">
     <foo:B>
        <foo:C>bar</foo:C>
     </foo:B>
  </foo:A>

Simply using a text editor to cut the fragment headed by the <B> element from one document and paste it into another document results in the loss of namespace information because the namespace declaration is not part of the fragment -- it is on the parent element (<A>) -- and isn't moved.

Even when this is done programmatically, the situation isn't necessarily any better. For example, suppose an application uses DOM Level 2 to "cut" the fragment from the above document and "paste" it into a different document. Although the namespace information is transferred (it is carried by each node), the namespace declaration (xmlns attribute) is not, again because it is not part of the fragment. Thus, the application must manually add the declaration before serializing the document or the new document will be invalid. (This problem is partially resolved in DOM Level 3 with the Document.normalizeDocument method, which adds the relevant xmlns attributes. However, the existence of a method to clean up such problems points out that the mechanism isn't entirely successful.)

It is interesting to note that this really isn't any different from the situation in strongly-typed programming languages. For example, in the following code fragment, the variable total is declared as an integer in the first statement and the variable i is declared as an integer in the for clause:

   int total = 0;
   for (int i = 0; i < 10; i++)
   {
      total = total + i;
   }

Now, if we cut the statement

   total = total + i;

and paste it into a different section of code, it would cause a compile-time error. This is because we haven't declared the variables total and i in the new section of code. For people accustomed to working with strongly-typed languages, this is not a surprise and it is accepted without question.

In spite of this, our expectations about XML are different: We expect to be able to cut and paste XML fragments without having to worry about declarations that affect how the names in those fragments are resolved. This probably comes from two sources. First, this was possible before XML namespaces were introduced. Second, from a standpoint of writing applications, XML is closer to data than it is to code, and we are not accustomed to such problems when moving data around. (The closest thing I can think of is having to cast data from one type to another, but that is much simpler than worrying about XML namespace declarations.)

4.10 How do different XML technologies treat XML namespace declarations?

This depends on the technology -- some treat them as attributes and some treat them as namespace declarations. For example, SAX1 treats them as attributes and SAX2 can treat them as attributes or namespace declarations, depending on how the parser is configured. (For more information, see question 11.3 and the SAX2 documentation.) DOM Levels 1, 2, and 3 treat them as attributes, but DOM Levels 2 and 3 also interpret them as namespace declarations. (For more information, see question 11.5 and question 11.6.) XPath, XSLT, and XML Schemas treat them as namespaces declarations.

The reason that different technologies treat these differently is that many of these technologies predate XML namespaces. Thus, newer versions of them need to worry both about XML namespaces and backwards compatibility issues.

Section 5.0: Using XML Namespaces in an XML Document

5.1 How do I use prefixes to refer to element type and attribute names in an XML namespace?

Make sure you have declared the prefix (see question 4.1) and that it is still in scope (see section 6). All you need to do then is prefix the local name of an element type or attribute with the prefix and a colon. The result is a qualified name (see question 12.1), which the application parses to determine what XML namespace the local name belongs to.

For example, suppose you have associated the serv prefix with the http://www.tu-darmstadt.de/ito/servers namespace and that the declaration is still in scope. In the following, serv:Address refers to the Address name in the http://www.tu-darmstadt.de/ito/servers namespace. (Note that the prefix is used on both the start and end tags.)

  <!-- serv refers to the http://www.tu-darmstadt.de/ito/servers namespace. -->
  <serv:Address>123.45.67.8</serv:Address>

Now suppose you have associated the xslt prefix with the http://www.w3.org/1999/XSL/Transform namespace. In the following, xslt:version refers to the version name in the http://www.w3.org/1999/XSL/Transform namespace:

  <!-- xslt refers to the http://www.w3.org/1999/XSL/Transform namespace. -->
  <html xslt:version="1.0">

5.2 How do I use the default XML namespace to refer to element type names in an XML namespace?

Make sure you have declared the default XML namespace (see question 4.1) and that that declaration is still in scope (see section 6). All you need to do then is use the local name of an element type. Even though it is not prefixed, the result is still a qualified name (see question 12.1), which the application parses to determine what XML namespace it belongs to.

For example, suppose you declared the http://www.tu-darmstadt.de/ito/addresses namespace as the default XML namespace and that the declaration is still in scope. In the following, Address refers to the Address name in the http://www.tu-darmstadt.de/ito/addresses namespace.

  <!-- http://www.tu-darmstadt.de/ito/addresses is the default XML namespace. -->
  <Address>123.45.67.8</Address>

For information about how to use the default XML namespace with attribute names, see question 5.3.

5.3 How do I use the default XML namespace to refer to attribute names in an XML namespace?

You can't.

The default XML namespace only applies to element type names, so you can refer to attribute names that are in an XML namespace only with a prefix. For example, suppose that you declared the http://www.tu-darmstadt.de/ito/addresses namespace as the default XML namespace. In the following, the type attribute name does not refer to that namespace, although the Address element type name does. That is, the Address element type name is in the http://www.tu-darmstadt.de/ito/addresses namespace, but the type attribute name is not in any XML namespace.

  <!-- http://www.tu-darmstadt.de/ito/addresses is the default XML namespace. -->
  <Address type="home">

To understand why this is true, remember that the purpose of XML namespaces is to uniquely identify element and attribute names. Unprefixed attribute names can be uniquely identified based on the element type to which they belong, so there is no need identify them further by including them in an XML namespace. In fact, the only reason for allowing attribute names to be prefixed is so that attributes defined in one XML language can be used in another XML language.

For information about how to use the default XML namespace with element type names, see question 5.2. For more information about unprefixed attribute names and XML namespaces, see Namespace Myth #4.

5.4 When should I use the default XML namespace instead of prefixes?

This is purely a matter of choice, although your choice may affect the readability of the document. When elements whose names all belong to a single XML namespace are grouped together, using a default XML namespace might make the document more readable. For example:

  <!-- A, B, C, and G are in the http://www.foo.org/ namespace. -->
  <A xmlns="http://www.foo.org/">
     <B>abcd</B>
     <C>efgh</C>
     <!-- D, E, and F are in the http://www.bar.org/ namespace. -->
     <D xmlns="http://www.bar.org/">
        <E>1234</E>
        <F>5678</F>
     </D>
     <!-- Remember! G is in the http://www.foo.org/ namespace. -->
     <G>ijkl</G>
  </A>

When elements whose names are in multiple XML namespaces are interspersed, default XML namespaces definitely make a document more difficult to read and prefixes should be used instead. For example:

  <A xmlns="http://www.foo.org/">
     <B xmlns="http://www.bar.org/">abcd</B>
     <C xmlns="http://www.foo.org/">efgh</C>
     <D xmlns="http://www.bar.org/">
        <E xmlns="http://www.foo.org/">1234</E>
        <F xmlns="http://www.bar.org/">5678</F>
     </D>
     <G xmlns="http://www.foo.org/">ijkl</G>
  </A>

In some cases, default namespaces can be processed faster than namespace prefixes, but the difference is certain to be negligible in comparison to total processing time.

Section 6.0: Scope of XML Namespace Declarations

6.1 What is the scope of an XML namespace declaration?

The scope of an XML namespace declaration is that part of an XML document to which the declaration applies. An XML namespace declaration remains in scope for the element on which it is declared and all of its descendants, unless it is overridden or undeclared on one of those descendants (see questions 4.5, 4.6, and 4.8).

For example, in the following, the scope of the declaration of the http://www.foo.org/ namespace is the element A and its descendants (B and C). The scope of the declaration of the http://www.bar.org/ namespace is only the element C.

  <foo:A xmlns:foo="http://www.foo.org/">
     <foo:B>
        <bar:C xmlns:bar="http://www.bar.org/" />
     </foo:B>
  </foo:A>

Note that being in the scope of an XML namespace declaration is different from being in the XML namespace itself. Being in the scope of a declaration simply means that the declaration is available to resolve prefixes; it does not mean that a given declaration actually resolves a particular prefix. For example, two namespace declarations are in scope for the C element (http://www.foo.org/ and http://www.bar.org/), but only the declaration for the http://www.bar.org/ actually resolves the bar prefix.

6.2 Does the scope of an XML namespace declaration include the element it is declared on?

Yes.

For example, in the following, the names B and C are in the http://www.bar.org/ namespace, not the http://www.foo.org/ namespace. This is because the declaration that associates the foo prefix with the http://www.bar.org/ namespace occurs on the B element, overriding the declaration on the A element that associates it with the http://www.foo.org/ namespace.

  <foo:A xmlns:foo="http://www.foo.org/">
     <foo:B xmlns:foo="http://www.bar.org/">
        <foo:C>abcd</foo:C>
     </foo:B>
  </foo:A>

Similarly, in the following, the names B and C are in the http://www.bar.org/ namespace, not the http://www.foo.org/ namespace because the declaration declaring http://www.bar.org/ as the default XML namespace occurs on the B element, overriding the declaration on the A element.

  <A xmlns="http://www.foo.org/">
     <B xmlns="http://www.bar.org/">
        <C>abcd</C>
     </B>
  </A>

A final example is that, in the following, the attribute name D is in the http://www.bar.org/ namespace.

  <foo:A xmlns:foo="http://www.foo.org/">
     <foo:B foo:D="In http://www.bar.org/ namespace"
             xmlns:foo="http://www.bar.org/">
        <C>abcd</C>
     </foo:B>
  </foo:A>

One consequence of XML namespace declarations applying to the elements they occur on is that they actually apply before they appear. Because of this, software that processes qualified names should be particularly careful to scan the attributes of an element for XML namespace declarations before deciding what XML namespace (if any) an element type or attribute name belongs to.

6.3 If an element or attribute is in the scope of an XML namespace declaration, is its name in that namespace?

Not necessarily.

When an element or attribute is in the scope of an XML namespace declaration, the element or attribute's name is checked to see if it has a prefix that matches the prefix in the declaration. Whether the name is actually in the XML namespace depends on whether the prefix matches. For example, in the following, the element type names A, B, D, and F and the attribute names C and E are in the scope of the declaration of the http://www.foo.org/ namespace. While the names A, B, and C are in the http://www.foo.org/ namespace, the names D, E, and F are not: D and E use a different prefix (bar) and F does not have a prefix at all.

  <foo:A xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org/">
     <foo:B foo:C="foo" />
     <bar:D bar:E="bar" />
     <F>baz</F>
  </foo:A>

(See also question 3.6.)

6.4 What happens when an XML namespace declaration goes out of scope?

When an XML namespace declaration goes out of scope, it simply no longer applies. For example, in the following, the declaration of the http://www.foo.org/ namespace does not apply to the C element because this is outside its scope. That is, it is past the end of the B element, on which the http://www.foo.org/ namespace was declared.

  <!-- B is in the http://www.foo.org/ namespace;
       C is not in any XML namespace. -->
  <A>
     <B xmlns="http://www.foo.org/">abcd</B>
     <C>efgh</C>
  </A>

In addition to the declaration no longer applying, any declarations that it overrode come back into scope. For example, in the following, the declaration of the http://www.foo.org/ namespace is brought back into scope after the end of the B element. This is because it was overridden on the B element by the declaration of the http://www.bar.org/ namespace.

  <!-- A and C are in the http://www.foo.org/ namespace.
          B is in the http://www.bar.org/ namespace. -->
  <A xmlns="http://www.foo.org/">
     <B xmlns="http://www.bar.org/">abcd</B>
     <C>efgh</C>
  </A>

6.5 What happens if no XML namespace declaration is in scope?

If no XML namespace declaration is in scope, then any prefixed element type or attribute names result in namespace errors. For example, in the following, the names foo:A and foo:B result in namespace errors.

  <?xml version="1.0" ?>
  <foo:A foo:B="error" />

In the absence of an XML namespace declaration, unprefixed element type and attribute names do not belong to any XML namespace. For example, in the following, the names A and B are not in any XML namespace. For more information, see question 3.6.

  <?xml version="1.0" ?>
  <A B="no error" />

6.6 Can multiple XML namespace declarations be in scope at the same time?

Yes, as long as they don't use the same prefixes and at most one of them is the default XML namespace. For example, in the following, the http://www.foo.org/ and http://www.bar.org/ namespaces are both in scope for all elements:

  <A xmlns:foo="http://www.foo.org/"
     xmlns:bar="http://www.bar.org/">
     <foo:B>abcd</foo:B>
     <bar:C>efgh</bar:C>
  </A>

One consequence of this is that you can place all XML namespace declarations on the root element and they will be in scope for all elements. This is the simplest way to use XML namespaces.

6.7 How can I declare XML namespaces so that all elements and attributes are in their scope?

XML namespace declarations that are made on the root element are in scope for all elements and attributes in the document. This means that an easy way to declare XML namespaces is to declare them only on the root element. For example:

  <Department
         xmlns:addr="http://www.tu-darmstadt.de/ito/addresses"
         xmlns:serv="http://www.tu-darmstadt.de/ito/servers">
     <Name>DVS1</Name>
     <addr:Address>
        <addr:Street>Wilhelminenstr. 7</addr:Street>
        <addr:City>Darmstadt</addr:City>
        <addr:State>Hessen</addr:State>
        <addr:Country>Germany</addr:Country>
        <addr:PostalCode>D-64285</addr:PostalCode>
     </addr:Address>
     <serv:Server>
        <serv:Name>OurWebServer</serv:Name>
        <serv:Address>123.45.67.8</serv:Address>
     </serv:Server>
  </Department>

6.8 Does the scope of an XML namespace declaration ever include the DTD?

No.

XML namespaces can be declared only on elements and their scope consists only of those elements and their descendants. Thus, the scope can never include the DTD. For more information, see question 7.2.

Section 7.0: XML Namespaces and DTDs

7.1 Can I use XML namespaces in DTDs?

Yes and no.

In particular, DTDs can contain qualified names (see question 7.3) but XML namespace declarations do not apply to DTDs (see question 7.2).

This has a number of consequences. Because XML namespace declarations do not apply to DTDs:

  1. There is no way to determine what XML namespace a prefix in a DTD points to. Which means...

  2. Qualified names in a DTD cannot be mapped to expanded names. Which means...

  3. Element type and attribute declarations in a DTD are expressed in terms of qualified names, not expanded names. Which means...

  4. Validation cannot be redefined in terms of expanded names as might be expected.

This situation has caused numerous complaints but, as XML namespaces are already a recommendation, is unlikely to change. The long term solution to this problem is an XML schema language: all of the proposed XML schema languages provide a mechanism by which the local name in an element type or attribute declaration can be associated with an XML namespace. This makes it possible to redefine validity in terms of expanded names.

7.2 Do XML namespace declarations apply to DTDs?

No.

In particular, an xmlns attribute declared in the DTD with a default is not an XML namespace declaration for the DTD. For more information, see question 4.4. (Note that an earlier version of MSXML (the parser used by Internet Explorer) did use such declarations as XML namespace declarations, but that this was removed in MSXML 4. For more information, see question 10.6.)

7.3 Can I use qualified names in DTDs?

Yes.

For example, the following is legal:

  <!ELEMENT foo:A (foo:B)>
  <!ATTLIST foo:A
            foo:C CDATA #IMPLIED>
  <!ELEMENT foo:B (#PCDATA)>

However, because XML namespace declarations do not apply to DTDs (see question 7.2), qualified names in the DTD cannot be converted to expanded names. As a result, qualified names in the DTD have no special meaning. For example, foo:A is just foo:A -- it is not A in the XML namespace to which the prefix foo is mapped.

The reason qualified names are allowed in the DTD is so that validation will continue to work. For more information, see question 7.6.

7.4 Can the content model in an element type declaration contain element types whose names come from other XML namespaces?

Yes and no.

The answer to this question is yes in the sense that a qualified name in a content model can have a different prefix than the qualified name of the element type being declared. For example, the following is legal:

  <!ELEMENT foo:A (bar:B, baz:C)>

The answer to this question is no in the sense that XML namespace declarations do not apply to DTDs so the prefixes used in an element type declaration are technically meaningless. In particular, they do not specify that the name of a certain element type belongs to a certain namespace. Nevertheless, the ability to mix prefixes in this manner is crucial when: a) you have a document whose names come from multiple XML namespaces (see question 10.5), and b) you want to construct that document in a way that is both valid and conforms to the XML namespaces recommendation (see question 7.6).

7.5 Can the attribute list of an element type contain attributes whose names come from other XML namespaces?

Yes and no, for the reasons listed in question 7.4.

For example, the following is legal:

  <!ATTLIST foo:A 
            bar:B CDATA #IMPLIED>

7.6 How can I construct an XML document that is valid and conforms to the XML namespaces recommendation?

In answering this question, it is important to remember that:

Thus, validity is the same for a document that uses XML namespaces and one that doesn't. In particular, with respect to validity:

Because of this, XML documents that you might expect to be valid are not. For example, the following document is not valid because the element type name A is not declared in the DTD, in spite of the fact both foo:A and A share the expanded name {http://www.foo.org/}A:

  <?xml version="1.0" ?>
  <!DOCTYPE foo:A [
     <!ELEMENT foo:A EMPTY>
     <!ATTLIST foo:A
               xmlns:foo CDATA #FIXED "http://www.foo.org/"
               xmlns CDATA #FIXED "http://www.foo.org/">
  ]>
  <A />

Similarly, the following is not valid because the xmlns attribute is not declared in the DTD:

  <?xml version="1.0" ?>
  <!DOCTYPE A [
     <!ELEMENT A EMPTY>
  ]>
  <A xmlns="http://www.foo.org/>

Furthermore, documents that you might expect to be invalid are valid. For example, the following document is valid but contains two definitions of the element type with the expanded name {http://www.foo.org/}A:

  <?xml version="1.0" ?>
  <!DOCTYPE foo:A [
     <!ELEMENT foo:A (bar:A)>
     <!ATTLIST foo:A
               xmlns:foo CDATA #FIXED "http://www.foo.org/">
     <!ELEMENT bar:A (#PCDATA)>
     <!ATTLIST bar:A
               xmlns:bar CDATA #FIXED "http://www.foo.org/">
  ]>
  <foo:A>
     <bar:A>abcd</bar:A>
  </foo:A>

Finally, validity has nothing to do with correct usage of XML namespaces. For example, the following document is valid but does not conform to the XML namespaces recommendation because the foo prefix is never declared:

  <?xml version="1.0" ?>
  <!DOCTYPE foo:A [
     <!ELEMENT foo:A EMPTY>
  ]>
  <foo:A />

Therefore, when constructing an XML document that uses XML namespaces, you need to do both of the following if you want the document to be valid:

  1. Declare xmlns attributes in the DTD.
  2. Use the same qualified names in the DTD and the body of the document.

For example:

  <?xml version="1.0" ?>
  <!DOCTYPE foo:A [
     <!ELEMENT foo:A (foo:B)
     <!ATTLIST foo:A
               xmlns:foo CDATA #FIXED "http://www.foo.org/">
     <!ELEMENT foo:B EMPTY>
  ]>
  <foo:A>
     <foo:B />
  </foo:A>

While this is a minimal set of requirements to ensure validity, a better set of guidelines follows:

  1. Declare all xmlns attributes in the DTD.
  2. Use the same qualified names in the DTD and the body of the document.
  3. Use one prefix per XML namespace.
  4. Do not use the same prefix for more than one XML namespace.
  5. Use at most one default XML namespace.
  6. Declare all XML namespaces in the XML document itself.
  7. Declare all XML namespaces on the root element of the document.

As was already noted, points 1 and 2 are necessary to ensure validity.

Points 3, 4, and 5 guarantee that there is a one-to-one relationship between prefixes and XML namespaces. This guarantees that it is not possible to construct documents that use multiple prefixes for the same prefix or the same XML namespace for multiple XML namespaces, both of which are confusing to read and prone to error. They also eliminate abuses such as defining an element type or attribute with a given expanded name more than once, as was seen earlier. Unfortunately, it also means that prefixes fulfill the role normally played by namespace names -- uniquely identifying an XML namespace. Because this is contrary to the spirit of prefixes, which were designed for their flexibility, a slightly better solution is shown in question 7.7.

Point 5 ensures that the document will always be namespace valid. This is not always true if the XML namespace is declared only with a FIXED attribute in the DTD; for more information, see question 4.3.

Point 6 simplifies the DTD by allowing xmlns attributes to be declared only on the root element type(s). Otherwise, they would need to be declared on all element types, since XML namespace declarations are allowed on any element in the document.

7.7 How can I allow the prefixes in my document to be different from the prefixes in my DTD?

One of the problems with the solution proposed in question 7.6 is that it requires the prefixes in the document to match those in the DTD. Fortunately, there is a workaround for this problem, although it does require that a single prefix be used for a particular namespace name throughout the document. (This is a good practice anyway, so it's not too much of a restriction.) The solution assumes that you are using a DTD that is external to the document, which is common practice.

To use different prefixes in the external DTD and XML documents, you declare the prefix with a pair of parameter entities in the DTD. You can then override these entities with declarations in the internal DTD in a given XML document. This works because the internal DTD is read before the external DTD and the first definition of a particular entity is the one that is used. The following paragraphs describe how to use a single namespace in your DTD. You will need to modify them somewhat to use multiple namespaces.

To start with, declare three parameter entities in your DTD:

   <!ENTITY % p "" >
   <!ENTITY % s "" >
   <!ENTITY % nsdecl "xmlns%s;" >

The p entity ("p" is short for "prefix") is used in place of the actual prefix in element type and attribute names. The s entity ("s" is short for "suffix") is used in place of the actual prefix in namespace declarations. The nsdecl entity ("nsdecl" is short for "namespace declaration") is used in place of the name of the xmlns attribute in declarations of that attribute.

Now use the p entity to define parameter entities for each of the names in your namespace. For example, suppose element type names A, B, and C and attribute name D are in your namespace.

   <!ENTITY % A "%p;A">
   <!ENTITY % B "%p;B">
   <!ENTITY % C "%p;C">
   <!ENTITY % D "%p;D">

Next, declare your element types and attributes using the "name" entities, not the actual names. For example:

   <!ELEMENT %A; ((%B;)*, %C;)>
   <!ATTLIST %A;
             %nsdecl; CDATA "http://www.foo.org/">
   <!ELEMENT %B; EMPTY>
   <!ATTLIST %B;
             %D; NMTOKEN #REQUIRED
             E CDATA #REQUIRED>
   <!ELEMENT %C; (#PCDATA)>

There are several things to notice here.

Now let's see how this all works. Suppose our XML document won't use prefixes, but instead wants the default namespace to be the http://www.foo.org/ namespace. In this case, no entity declarations are needed in the document. For example, our document might be:

   <!DOCTYPE A SYSTEM "http://www.foo.org/foo.dtd">
   <A>
      <B D="bar" E="baz buz" />
      <B D="boo" E="biz bez" />
      <C>bizbuz</C>
   </A>

This document is valid because the declarations for p, s, and nsdecl in the DTD set p and s to "" and nsdecl to "xmlns". That is, after replacing the p, s, and nsdecl parameter entities, the DTD is as follows. Notice that both the DTD and document use the element type names A, B, and C and the attribute names D and E.

   <!ELEMENT  A  (( B )*,  C )>
   <!ATTLIST  A 
              xmlns  CDATA "http://www.foo.org/">
   <!ELEMENT  B  EMPTY>
   <!ATTLIST  B 
              D  NMTOKEN #REQUIRED
             E CDATA #REQUIRED>
   <!ELEMENT  C  (#PCDATA)>

But what if the document wants to use a different prefix, such as foo? In this case, the document must override the declarations of the p and s entities in its internal DTD. That is, it must declare these entities so that they use foo as a prefix (followed by a colon) and a suffix (preceded by a colon). For example:

   <!DOCTYPE foo:A SYSTEM "http://www.foo.org/foo.dtd" [
      <!ENTITY % p "foo:">
      <!ENTITY % s ":foo">
   ]>
   <foo:A>
      <foo:B foo:D="bar" E="baz buz" />
      <foo:B foo:D="boo" E="biz bez" />
      <foo:C>bizbuz</foo:C>
   </foo:A>

In this case, the internal DTD is read before the external DTD, so the values of the p and s entities from the document are used. Thus, after replacing the p, s, and nsdecl parameter entities, the DTD is as follows. Notice that both the DTD and document use the element type names foo:A, foo:B, and foo:C and the attribute names foo:D and E.

   <!ELEMENT  foo:A  (( foo:B )*,  foo:C )>
   <!ATTLIST  foo:A 
              xmlns:foo  CDATA "http://www.foo.org/">
   <!ELEMENT  foo:B  EMPTY>
   <!ATTLIST  foo:B 
              foo:D  NMTOKEN #REQUIRED
             E CDATA #REQUIRED>
   <!ELEMENT  foo:C  (#PCDATA)>

7.8 How can I validate an XML document that uses XML namespaces?

When people ask this question, they usually assume that validity is different for documents that use XML namespaces and documents that don't. In fact, it isn't -- it's the same for both. Thus, there is no difference between validating a document that uses XML namespaces and validating one that doesn't. In either case, you simply use a validating parser or other software that performs validation.

For information about how to construct an XML document that is valid and conforms to the XML namespace recommendation, see questions 7.6 and 7.7.

7.9 If I start using XML namespaces, do I need to change my existing DTDs?

Probably.

If you want your XML documents to be both valid and conform to the XML namespaces recommendation, you need to declare any xmlns attributes and use the same qualified names in the DTD as in the body of the document. (For more information, see questions 7.6 and 7.7.)

If your DTD contains element type and attribute names from a single XML namespace, the easiest thing to do is to use your XML namespace as the default XML namespace. To do this, declare the attribute xmlns (no prefix) for each possible root element type. If you can guarantee that the DTD is always read (see question 4.3), set the default value in each xmlns attribute declaration to the URI reference used as your namespace name. Otherwise, declare your XML namespace as the default XML namespace on the root element of each instance document.

If your DTD contains element type and attribute names from multiple XML namespaces, you need to choose a single prefix for each XML namespace and use these consistently in qualified names in both the DTD and the body of each document. You also need to declare your xmlns attributes in the DTD and declare your XML namespaces. As in the single XML namespace case, the easiest way to do this is add xmlns attributes to each possible root element type and use default values if possible.

Note that you should only need to make these changes once.

Section 8.0: XML Namespaces and XML Schemas

8.1 How do I use XML namespaces with XML Schemas?

A single XML Schema document declares elements and attributes for a single XML namespace, known as the target namespace. This is done with the targetNamespace attribute on the xs:schema element. For example, the following schema declares the elements A, B, and C in the http://www.foo.org/ namespace:

   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.foo.org/">
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="B"/>
               <xs:element ref="C"/>
            </xs:sequence>
         </xs:complexType>
      </xs:element>
      <xs:element name="B" type="xs:string"/>
      <xs:element name="C" type="xs:string"/>
   </xs:schema>

This does not limit schemas to a single XML namespace. In order to use elements and attributes from a different XML namespace, they must be declared in a different XML Schema document, then imported and referenced in the current XML Schema document. For example, the following schemas declare elements A and B in the http://www.foo.org/ namespace and C in the http://www.bar.org/ namespace. The content model for element A references element C.

A_B.xsd:
--------
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
              xmlns:bar="http://www.bar.org/"
              targetNamespace="http://www.foo.org/">

      <!-- Import namespace http://www.bar.org/ -->
      <xs:import namespace="http://www.bar.org/" />

      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="B"/>
      <!-- Reference C from http://www.bar.org/ -->
               <xs:element ref="bar:C"/>
            </xs:sequence>
         </xs:complexType>
      </xs:element>
      <xs:element name="B" type="xs:string"/>
   </xs:schema>

C.xsd:
------
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.bar.org/">
      <xs:element name="C" type="xs:string"/>
   </xs:schema>

Notice that the xs:import element references the schema in which C is declared by its XML namespace, not its location. This allows the schema processor to decide for itself where to retrieve an schema document. The optional schemaLocation attribute can be used to give the schema processor a hint about where to find the schema document. However, the schema processor is not required to follow the hint. For example, the following xs:import element hints that the schema document can be found in the C:\schemas directory:

   <import namespace="http://www.bar.org/"
           schemaLocation="file://localhost/C|/schemas/C.xsd" />

8.2 What are qualified and unqualified local names in XML Schemas?

In an XML Schema, elements and attributes can be declared globally or locally. Global elements and attributes are those elements and attributes defined at the outermost level of the schema -- that is, as children of the xs:schema element. Global elements can be used as the root element. Both global elements and global attributes can be referenced from the declarations of other elements in their own schema or a different schema. Local elements and attributes are those declared inside the declaration of another element. They can only be used inside the elements in which they are declared and cannot be referenced from the declarations of other elements.

For example, in the following schema, A and B are declared globally and C is declared locally. Note that the declaration of B is referenced inside the content model of A, and C is declared inside the content model of A.

   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.foo.org/">
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="B"/>
               <xs:element name="C" type="xs:string"/>
            </xs:sequence>
         </xs:complexType>
      </xs:element>
      <xs:element name="B" type="xs:string"/>
   </xs:schema>

(By contrast, all elements types defined in a DTD are global. They can be used as the root element type and can be referenced from the content models of other elements in the same DTD. All attributes defined in a DTD are local. They can only be used in the element type with which they are associated.)

The main difference between local and global elements and attributes is that a schema can have multiple local elements or attributes with the same name, while it can only have one global element or attribute with the same name. This is useful when you want to use the same name in different contexts.

For example, suppose you are defining a schema for sales orders that includes sales order numbers and line item numbers. By using local elements, you can declare two elements named Number -- one that is local to the SalesOrder element and one that is local to the LineItem element. This is useful when sales order numbers have a different format from line item numbers. For example, sales order numbers might be alphanumeric, conforming to a particular pattern, and line item numbers might be positive integers. This would not be possible if you declared a global Number element. Because you can only have one global element named Number, you could not restrict it to being an alphanumeric in the SalesOrder element and a positive integer in the LineItem element.

Whether local elements and attributes have qualified names depends on the elementFormDefault and attributeFormDefault attributes of the xs:schema element (or the form attribute on the xs:element and xs:attribute elements). By default, the value of these attributes is "unqualified", which means that local elements and attributes do not have qualified names -- that is, they do not have prefixes. For example, in the following schema, B and C are local elements that are not qualified and D is a local attribute that is not qualified:

   <!-- elementFormDefault is "unqualified"
        attributeFormDefault is "unqualified" -->
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.foo.org/"
           attributeFormDefault="unqualified"
           elementFormDefault="unqualified">
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
               <xs:element name="B" type="xs:string"/>
               <xs:element name="C" type="xs:string"/>
            </xs:sequence>
         </xs:complexType>
         <xs:attribute name="D" type="xs:string"/>
      </xs:element>
   </xs:schema>

Following is an example of a document that matches this schema. Note that B, C, and D are not prefixed.

   <foo:A xmlns:foo="http://www.foo.org/" D="dddd">
      <B>bbbb</B>
      <C>cccc</C>
   </foo:A>

In the next schema, B and C are local elements that are qualified and D is an attribute that is qualified:

   <!-- elementFormDefault is "qualified"
        attributeFormDefault is "qualified" -->
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.foo.org/"
           attributeFormDefault="qualified"
           elementFormDefault="qualified">
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
               <xs:element name="B" type="xs:string"/>
               <xs:element name="C" type="xs:string"/>
            </xs:sequence>
         </xs:complexType>
         <xs:attribute name="D" type="xs:string"/>
      </xs:element>
   </xs:schema>

Following is an example of a document that matches this schema. Note that B, C, and D are prefixed.

   <foo:A xmlns:foo="http://www.foo.org/" foo:D="dddd">
      <foo:B>bbbb</foo:B>
      <foo:C>cccc</foo:C>
   </foo:A>

Whether to use qualified (prefixed) or unqualified (unprefixed) local element and attribute names is largely a stylistic decision. That is, it only affects what an instance document looks like, not how it is validated. However, there are definite advantages and disadvantages to each approach. For example, see XML-Schemas: purpose of elementFormDefault? from Henry Thompson and Namespaces, W3C XML Schema from Matthew Fuchs. As a general rule, people set elementFormDefault to "qualified" and attributeFormDefault to "unqualified". This means all element names use prefixes (or the default namespace) and no attribute names use prefixes.

Whether a name is qualified or unqualified does not affect whether an element or attribute is local or global, nor does it affect collisions between these names. That is, you can have multiple qualified or unqualified elements or attributes that have the same name, as long as they are declared locally in different elements, and you can only have one global element or attribute with the same name.

8.3 Do I have to use XML namespaces with XML Schemas?

No.

If you don't want the elements and attributes you are declaring to be in any XML namespace, just omit the targetNamespace attribute from the xs:schema element. For example, the following XML Schema document declares the elements A, B, and C, none of which is in an XML namespace:

   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="B"/>
               <xs:element ref="C"/>
            </xs:sequence>
         </xs:complexType>
      </xs:element>
      <xs:element name="B" type="xs:string"/>
      <xs:element name="C" type="xs:string"/>
   </xs:schema>

For information about whether it is a good idea to declare elements and attributes that are not in any XML namespace, see question 3.9.

8.4 What is a chameleon schema?

A chameleon schema is an XML Schema that does not have a target namespace. It is called a chameleon schema because, when it is included into another schema, it takes on the target namespace of the latter schema. This allows schemas to be built in modular pieces and reused in other schemas without the confusion of having multiple namespaces in those schemas.

In the following example, Chameleon.xsd is included in A.xsd via the xs:include element. As a result, element C is in the http://www.foo.org/ namespace. Notice that Chameleon.xsd does not use the targetNamespace attribute, while C.xsd does.

Chameleon.xsd
-------------

   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <xs:element name="C" type="xs:string"/>
   </xs:schema>

A.xsd
-----
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.foo.org/">
      <include schemaLocation="file://localhost/C|/schemas/Chameleon.xsd" />
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="B"/>
               <xs:element ref="C"/>
            </xs:sequence>
         </xs:complexType>
      </xs:element>
      <xs:element name="B" type="xs:string"/>
   </xs:schema>

To see how C changes namespaces, consider the following two documents. The first document conforms to Chameleon.xsd; in it, the C element is not in any namespace. The second document conforms to A.xsd; in it, the C element is in the http://www.foo.org namespace.

Document conforming to Chameleon.xsd
------------------------------------

   <C>cccc</C>

Document conforming to A.xsd
----------------------------

   <foo:A xmlns:foo="http://www.foo.org/">
      <foo:B>bbbb</foo:B>
      <foo:C>cccc</foo:C>
   </foo:A>

A chameleon schema only takes on the target namespace of another schema when it is included in that schema, not when it is imported into that schema. Including is equivalent to physically cutting and pasting, which results in the target namespace declaration applying to the "cut-and-pasted" (included) schema. Importing allows the logical reuse of definitions and declarations from the imported schema, which remains physically separate.

For more information on when and how to use chameleon schemas, see W3C XML Schema Design Patterns: Avoiding Complexity by Dare Obasanjo and Zero, One, or Many Namespaces by members of the xml-dev mailing list. For an opposing viewpoint, see W3C XML Schema: DOs and DON'Ts by Kohsuke Kawaguchi.

8.5 Is everything defined or declared in an XML Schema in an XML namespace?

Strictly speaking, no.

This is because the Namespaces in XML recommendation only talks about using XML namespaces with elements and attributes. However, because items like complex types, attribute groups, model groups, and key definitions use qualified names, it is easiest to think of these names as being in an XML namespace. This is because their names are resolved using the same mechanisms as element and attribute names.

8.6 Is there a one-to-one relationship between XML namespaces and XML Schemas?

No.

As was shown in question 8.1, a schema may use elements or attributes from multiple XML namespaces. And although a given XML Schema document can only declare elements and attributes in a single XML namespace, the relationship between XML namespaces and XML Schema documents is not one-to-one. This is because multiple documents can all declare elements and attributes in the same XML namespace. When this is done, one XML Schema document can include another XML Schema document that has the same target namespace with the xs:include element.

For more information, see Namespace Myth #8.

8.7 How do I validate documents that use XML namespaces against XML Schemas?

To validate a document against an XML Schema, you must use a parser (or other processor) that supports XML Schemas. The processor checks that the document follows the rules in the schema.

Validating against a schema is called schema validation. Validating against a DTD is simply called validation. (In practice, schema validation is often called validation and people understand whether a document is being validated against a DTD or an XML Schema.)

Although there are a number of differences between schema validation and validation, the main difference between the two with respect to XML namespaces is that schema validation resolves qualified names into expanded names before comparing them, while validation simply compares the qualified names. As a result, a document being validated against an XML Schema can use any prefix in qualified names, while a document being validated against a DTD must use the prefix that is used in the DTD.

For example, the following document is schema valid against the following XML Schema, but invalid against the following DTD. This is because the prefix in the document resolves to the target namespace in the XML Schema, but does not match the prefix used in the DTD. For more information about validating documents that use XML namespaces against DTDs, see question 7.6, question 7.7, and question 7.8.

XML document:
-------------
   <bar:A xmlns:bar="http://www.foo.org/">
      <bar:B>bbbb</bar:B>
      <bar:C>cccc</bar:C>
   </bar:A>

XML Schema:
-----------
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.foo.org/">
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
            <xs:sequence>
               <xs:element ref="B"/>
               <xs:element ref="C"/>
            </xs:sequence>
         </xs:complexType>
      </xs:element>
      <xs:element name="B" type="xs:string"/>
      <xs:element name="C" type="xs:string"/>
   </xs:schema>

DTD:
----
   <!ELEMENT foo:A (foo:B, foo:C)>
   <!ELEMENT foo:B (#PCDATA)>
   <!ELEMENT foo:C (#PCDATA)>

Section 9.0: XML Namespaces and Validation

9.1 How do I validate documents that use XML namespaces?

Strictly speaking, validity is an XML 1.0 concept that means to check that an XML document conforms to the rules in a DTD. In a more general sense, validation means to check that an XML document conforms to the rules in any XML schema, regardless of the schema language used. Because DTDs do not support XML namespaces and the other major XML schema languages (XML Schemas, RELAX NG, Schematron) do support XML namespaces, validation therefore falls into two categories: validating against a DTD and validating against all other XML schema languages.

When an XML document is validated against a DTD, any qualified names in the document are not resolved into expanded names before validation. Instead, they are compared on a character-by-character basis with the names in the DTD. Thus, the prefixes in the XML document must match the prefixes in the DTD and validation against a DTD, while possible, does not really behave as one would expect with respect to XML namespaces. For more information, see question 7.6, question 7.7, and question 7.8.

When an XML document is validated against XML Schemas, RELAX NG, Schematron, or any other XML schema language that supports XML namespaces, qualified names are resolved into expanded names as part of the validation process. Because of this, prefixes in the XML document do not need to match prefixes in the XML schema. This is what one expects. For more information on validating documents against XML Schemas, see question 8.7.

9.2 What is the Namespace-based Validation Dispatching Language (NVDL)?

The Namespace-based Validation Dispatching Language (NVDL) is an ISO/IEC standard for validating documents against multiple schemas. The basic idea is that a document is split into subtrees, with the elements and attributes in each subtree sharing a single XML namespace. An NVDL script then maps each XML namespace to the schema used to validate the elements and attributes in that namespace.

For example, the following XHTML document contains an embedded Scalable Vector Graphics (SVG) document:

   <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:svg="http://www.w3.org/2000/svg">
      <head>
         <title>XHTML with embedded SVG</title>
      </head>
      <body>
         <p>Following this paragraph is an 
            SVG fragment that defines a circle.</p>
         <svg:svg width="400" height="400" version="1.1">
            <svg:circle cx="200" cy="200" r="100" />
         </svg:svg>
      </body>
   </html>

Because XHTML does not include an svg:svg element, you cannot successfully validate this document against the XHTML schema. However, with NVDL, you can specify that the XHTML elements (http://www.w3.org/1999/xhtml namespace) be validated against the XHTML schema and the SVG elements (http://www.w3.org/2000/svg namespace) be validated against the SVG schema. The NVDL processor will separately pass (dispatch) the XHTML subtree (omitting the subtree headed by the svg:svg element) and SVG subtree to the validation routine. Because each subtree is valid by itself, the document as a whole is valid.

The most important feature of NVDL is that schemas do not have to include specific places where elements and attributes from another schema can be inserted. (For example, the xs:any element in XML Schemas is used to do this.) Instead, you just insert the elements and attributes in an XML document wherever you want and create an NVDL script to specify how each subtree will be validated. This leaves the original schemas unchanged -- which is especially important for industry standard schemas -- and still allows you to validate documents.

Other features of NVDL include:

For more information about NVDL, see http://www.nvdl.org/. For a simple example using UBL, see Simple working demonstration of NVDL - ISO/IEC 19757-4 by G. Ken Holman.

Section 10.0: Using Documents that use XML Namespaces

10.1 How do I create documents that use XML namespaces?

The same as you create documents that don't use XML namespaces. If you're currently using Notepad on Windows or emacs on Linux, you can continue using Notepad or emacs. If you're using an XML editor that is not namespace-aware, you can also continue to use that, as qualified names are legal names in XML documents and xmlns attributes are legal attributes. And if you're using an XML editor that is namespace-aware, it will probably provide features such as automatically declaring XML namespaces and keeping track of prefixes and the default XML namespace for you.

10.2 How can I check that a document conforms to the XML namespaces recommendation?

Unfortunately, I know of no software that only checks for conformance to the XML namespaces recommendation. It is possible that some namespace-aware validating parsers (such as those from DataChannel (Microsoft), IBM, Oracle, or Sun) check XML namespace conformance as part of parsing and validating. Thus, you might be able to run your document through such parsers as a way of testing conformance.

Note that writing an application to check conformance to the XML namespaces recommendation is not as easy as it might seem. The problem is that most parsers do not make DTD information available to the application, so it might not be possible to check conformance in the DTD. Also note that writing a SAX 1.0 application that checks conformance in the body of the document (as opposed to the DTD) should be an easy thing to do.

10.3 Can I use the same document with both namespace-aware and namespace-unaware applications?

Yes.

This situation is quite common, such as when a namespace-aware application is built on top of a namespace-unaware parser. Another common situation is when you create an XML document with a namespace-unaware XML editor but process it with a namespace-aware application.

Using the same document with both namespace-aware and namespace-unaware applications is possible because XML namespaces use XML syntax. That is, an XML document that uses XML namespaces is still an XML document and is recognized as such by namespace-unaware software.

The only thing you need to be careful about when using the same document with both namespace-aware and namespace-unaware applications is when the namespace-unaware application requires the document to be valid. In this case, you must be careful to construct your document in a way that is both valid and conforms to the XML namespaces recommendation. (It is possible to construct documents that conform to the XML namespaces recommendation but are not valid and vice versa.) For information about how to do this, see question 7.6.

10.4 What software is needed to process XML namespaces?

From a document author's perspective, this is generally not a relevant question. Most XML documents are written in a specific XML language and processed by an application that understands that language. If the language uses an XML namespace, then the application will already use that namespace -- there is no need for any special XML namespace software.

For information about the software application writers use to process XML namespaces, see section 11.

10.5 How can I use XML namespaces to combine documents that use different element type and attribute names?

Before we answer this question, we need to clear up a common misconception about XML namespaces. It is often believed that XML namespaces provide some sort of magic that allows you to automatically combine XML documents that use separate sets of element types and attributes. This is not true. Although XML namespaces provide some of the tools you need to do this, you still need to do most of the work yourself, as you will see in the answer to this question.

To combine documents that use separate sets of element types and attributes, all you really need to do is decide where the elements and attributes go in the final document. For example, does element type A from the first document go inside element type B? Is it a sibling? Or are they completely unrelated? Although the procedure for actually combining two documents can be easily automated, deciding how to combine them is not likely to ever be automated. Instead, it is a strictly human problem, requiring somebody to make choices.

For example, suppose we have a document containing addresses:

  <Address>
     <Street>Wilhelminenstr. 7</Street>
     <City>Darmstadt</City>
     <State>Hessen</State>
     <Country>Germany</Country>
     <PostalCode>D-64285</PostalCode>
  </Address>

and a document containing Web server information:

  <Server>
     <Name>OurWebServer</Name>
     <Address>123.45.67.8</Address>
  </Server>

Now suppose we would like a document of departments, their addresses, and their Web servers, which we can make from the above documents plus a little additional information:

  <Departments>
     <Department>
        <Name>DVS1</Name>
        <Address>
           <Street>Wilhelminenstr. 7</Street>
           <City>Darmstadt</City>
           <State>Hessen</State>
           <Country>Germany</Country>
           <PostalCode>D-64285</PostalCode>
        </Address>
        <Server>
           <Name>OurWebServer</Name>
           <Address>123.45.67.8</Address>
        </Server>
     </Department>
     ...
  </Departments>

Unfortunately, we have a problem: there are two Address element types and two Name element types. (Although the Name element types both have a content model of PCDATA, they have different meanings -- one is the name of the department and the other is the name of the server -- so we would like to recognize them as different element types.)

To solve these conflicts, we can use XML namespaces. We assign the address information to the http://www.tu-darmstadt.de/ito/addresses namespace, the server information to the http://www.tu-darmstadt.de/ito/servers namespace, and the newly added departmental information to the http://www.tu-darmstadt.de/ito/depts namespace. Thus, our new document looks like:

  <dept:Departments
        xmlns:dept="http://www.tu-darmstadt.de/ito/depts
        xmlns:addr="http://www.tu-darmstadt.de/ito/addresses
        xmlns:serv="http://www.tu-darmstadt.de/ito/servers>
     <dept:Department>
        <dept:Name>DVS1</dept:Name>
        <addr:Address>
           <addr:Street>Wilhelminenstr. 7</addr:Street>
           <addr:City>Darmstadt</addr:City>
           <addr:State>Hessen</addr:State>
           <addr:Country>Germany</addr:Country>
           <addr:PostalCode>D-64285</addr:PostalCode>
        </addr:Address>
        <serv:Server>
           <serv:Name>OurWebServer</serv:Name>
           <serv:Address>123.45.67.8</serv:Address>
        </serv:Server>
     </dept:Department>
     ...
  </dept:Departments>

Although we could have assigned only the conflicting element type names to XML namespaces, it is generally a better idea to keep the names of related element types in a single XML namespace. This avoids questions of having to remember which names have been placed in XML namespaces and which haven't, as well as avoiding future conflicts that might occur when these types are used elsewhere. (This does not necessarily mean that the names of all related element types and attributes should be placed in a single XML namespace. If you have a large and complex set of element types and attributes and expect to reuse subsets of it elsewhere, it might make more sense to place the names of each reusable subset in its own XML namespace.)

This example was fairly simple in that it did not require us to change any existing content models. However, suppose we wanted to keep information only about servers: their name, IP address, and physical location. In this case, we might want to add the Address element type that describes street address to the content of the Server element type:

  <serv:Servers
        xmlns:addr="http://www.tu-darmstadt.de/ito/addresses
        xmlns:serv="http://www.tu-darmstadt.de/ito/servers2>
     <serv:Server>
        <serv:Name>OurWebServer</serv:Name>
        <serv:Address>123.45.67.8</serv:Address>
        <addr:Address>
           <addr:Street>Wilhelminenstr. 7</addr:Street>
           <addr:City>Darmstadt</addr:City>
           <addr:State>Hessen</addr:State>
           <addr:Country>Germany</addr:Country>
           <addr:PostalCode>D-64285</addr:PostalCode>
        </addr:Address>
     </serv:Server>
     ...
  </serv:Servers>

Notice that we have changed the name of the XML namespace for the server information to http://www.tu-darmstadt.de/ito/servers2. This is because we changed the content model of the Server element type. In other words, the content models of the two Server element types are different, so they are two different element types with the same name and should reside in separate XML namespaces. Had we not made this change, software searching for the old Server element type would have incorrectly processed the new Server element type and vice versa.

As you can see, there is nothing magic about combining documents. It is simply a matter of deciding how to fit them together and, although there are likely to be tools in the future that make this as easy as drag-and-drop, the decisions about exactly how to combine them are likely to always require human intervention.

You can also see that XML namespaces played a vital role in this process -- they allowed us to combine the documents without changing the local names of any of the element types. This is important, as without XML namespaces we would endlessly have to invent new ways of renaming simple element types like Address. However, it is also important to understand that resolving duplicate names is the only role XML namespaces played in this process -- the rest was left to the people making the decisions.

10.6 How do I use XML namespaces with Internet Explorer 5.0 and/or the MSXML parser?

WARNING! The following applies only to earlier versions of MSXML. It does not apply to MSXML 4, which is the currently shipping version [July, 2002].

An early version of the MSXML parser, which was shipped as part of Internet Explorer 5.0, required that every XML namespace prefix used in an element type or attribute declaration had to be "declared" in the attribute declaration for that element type. This had to be done with a fixed xmlns attribute declaration. For example, the following was accepted by MSXML and both xmlns:foo attributes were required:

   <!ELEMENT foo:A (#PCDATA)>
   <!ATTLIST foo:A
             xmlns:foo CDATA #FIXED "http://www.foo.org/">
   <!ELEMENT foo:B (#PCDATA)>
   <!ATTLIST foo:B
             xmlns:foo CDATA #FIXED "http://www.foo.org/">

MSXML returned an error for the following because the second foo prefix was not "declared":

   <!ELEMENT foo:A (#PCDATA)>
   <!ATTLIST foo:A
             xmlns:foo CDATA #FIXED "http://www.foo.org/">
   <!ELEMENT foo:B (#PCDATA)>

The reason for this restriction was so that MSXML could use expanded names to match element type and attribute declarations to elements and attributes during validation. Although this would have simplified many of the problems of writing documents that are both valid and conform to the XML namespaces recommendation (see question 7.6), some users complained about it because it was not part of the XML namespaces recommendation. In response to these complaints, Microsoft removed this restriction in later versions, which are now shipping. Ironically, the idea was later independently derived as a way to resolve the problems of validity and namespaces. However, it has not been implemented by anyone.

Section 11.0: Processing XML Namespaces in XML Applications

11.1 How do applications process documents that use XML namespaces?

Applications process documents that use XML namespaces in almost exactly the same way they process documents that don't use XML namespaces. For example, if a namespace-unaware application adds a new sales order to a database when it encounters a SalesOrder element, the equivalent namespace-aware application does the same. The only difference is that the namespace-aware application:

11.2 How do I use XML namespaces with SAX 1.0?

The easiest way to use XML namespaces with SAX 1.0 is to use John Cowan's Namespace SAX Filter. Unfortunately, this does not appear to be available any more (see http://www.ccil.org/~cowan/XML). This is a SAX filter that keeps track of XML namespace declarations, parses qualified names, and returns element type and attribute names as expanded names in the form:

  <i>URI</i>^<i>local-name</i>

For example:

  http://www.tu-darmstadt.de/ito/sales^SalesOrder

Your application can then base its processing on these longer names. For example, the code:

   public void startElement(String elementName, AttributeList attrs)
      throws SAXException
   {
      ...
      if (elementName.equals("SalesOrder"))
      {
         // Add new database record.
      }
      ...
   }

might become:

   public void startElement(String elementName, AttributeList attrs)
      throws SAXException
   {
      ...
      if (elementName.equals("http://www.tu-darmstadt.de/sales^SalesOrder"))
      {
         // Add new database record.
      }
      ...
   }

or:

   public void startElement(String elementName, AttributeList attrs)
      throws SAXException
   {
      ...
      // getURI() and getLocalName() are utility functions
      // to parse expanded names.

      if (getURI(elementName).equals("http://www.tu-darmstadt.de/ito/sales"))
      {
         if (getLocalName(elementName).equals("SalesOrder"))
         {
            // Add new database record.
         }
      }
      ...
   }

If you do not want to use the Namespace SAX Filter (or can't get it), then you will need to do the following in addition to identifying element types and attributes by their expanded names:

11.3 How do I use XML namespaces with SAX 2.0?

SAX 2.0 primarily supports XML namespaces through the following methods:

For example, the namespace-unaware SAX 1.0 code:

   public void startElement(String elementName, AttributeList attrs)
      throws SAXException
   {
      ...
      if (elementName.equals("SalesOrder"))
      {
         // Add new database record.
      }
      ...
   }

might become:

   public void startElement(String namespaceURI,
                            String localName,
                            String qualifiedName,
                            Attributes attrs)
      throws SAXException
   {
      ...
      if (namespaceURI.equals("http://www.tu-darmstadt.de/sales") &amp;&amp;
          localName.equals("SalesOrder"))
      {
         // Add new database record.
      }
      ...
   }

Although the above methods are sufficient for most applications, SAX 2.0 also supports the following:

For complete details, see the description of namespace handling in the SAX 2.0 specification.

11.4 How do I use XML namespaces with DOM Level 1?

This depends on what DOM Level 1 implementation you are using. If you are using a namespace-aware DOM implementation, such as those from Data Channel (Microsoft), IBM, Oracle, or Sun, then all you need to do is use the methods provided by those implementations to retrieve the namespace name and local names. For example, the namespace-unaware code to read from a document:

  // Check the local name.
  // getNodeName() is a DOM Level 1 method.

  if (elementNode.getNodeName().equals("SalesOrder"))
  {
     // Add new database record.
  }

might become the following namespace-aware code when using Oracle's DOM implementation:

  // Check the XML namespace name (URI reference).
  // getNamespace() and NSElement are Oracle-specific.

  String SALES_NS = "http://www.tu-darmstadt.de/ito/sales";
  if ((NSElement)elementNode).getNamespace().equals(SALES_NS))
  {

     // Check the local name.
     // getLocalName() is Oracle-specific.

     if ((NSElement)elementNode.getLocalName().equals("SalesOrder"))
     {
        // Add new database record.
     }
  }

Because DOM Level 1 does not include XML namespace support, each DOM Level 1 implementation provides a slightly different interface for accessing XML namespace information. Most of these implementations include some combination of methods for getting the qualified name, namespace name, local name, and prefix. Therefore, if you are writing a DOM-neutral application, you will need to define your own XML namespace interface and write converters for each DOM implementation you support. Fortunately, this is easy to do.

If you are using a namespace-unaware DOM implementation, such as Docuverse version 1 or OpenXML version 1 (these may support XML namespaces in a later version), you will need to perform namespace processing yourself. Although this is largely the same as in a SAX 1.0 application (see question 11.2) -- checking for xmlns attributes on each Element node and converting qualified names on Element and Attr nodes to expanded names -- it is potentially more difficult to determine what XML namespace declarations are in scope for any given node. If your application traverses the DOM tree in order from the root, this is fairly easy, as you can maintain prefix-to-URI reference mappings as you go. However, if you access the tree randomly, you may want to construct a parallel tree with mapping information before you do any other processing or rebuild the DOM tree using prefixes that map to known URI references.

11.5 How do I use XML namespaces with DOM Level 2?

DOM Level 2 supports XML namespaces through a number of new methods and attributes. The most important of these are the namespaceURI and localName attributes in the Node interface; these allow applications to identify nodes by their namespace name and local name rather than by qualified name. For example, the namespace-unaware code to read from a document:

  // Check the local name.
  // getNodeName() is a DOM Level 1 method.

  if (elementNode.getNodeName().equals("SalesOrder"))
  {
     // Add new database record.
  }

might become the following namespace-aware code:

  // Check the XML namespace name (URI reference).
  // getNamespaceURI() is a DOM Level 2 method.

  String SALES_NS = "http://www.tu-darmstadt.de/ito/sales";
  if (elementNode.getNamespaceURI().equals(SALES_NS))
  {

     // Check the local name.
     // getLocalName() is a DOM Level 2 method.

     if (elementNode.getLocalName().equals("SalesOrder"))
     {
        // Add new database record.
     }
  }

The situation when creating or modifying a document is more complex. This is because DOM Level 2 does not automatically maintain XML namespace declarations. That is, it does not automatically add the xmlns attributes used to declare XML namespaces. Instead, you must do this yourself. For example, suppose you have a DOM tree that represents the following document, and you want to add <bar:C>baz</bar:C> as a child of foo:B, where the bar prefix corresponds to the http://www.foo.org/bar namespace.

  <foo:A xmlns:foo="http://www.foo.org/foo">
     <foo:B>
     </foo:B>
  </foo:A>

The following code can be used to do this:

   // Create a text node.

   Text text = document.createTextNode("baz");

   // Create the bar:C element and add the text node

   Element elementbarC = document.createElementNS("http://www.foo.org/bar",
                                                  "bar:C");
   elementbarC.appendChild(text);

   // Add the bar:C element as a child of foo:B

   elementfooB.appendChild(elementbarC);

Unfortunately, if the DOM tree is serialized at this point, the result will be the following, which does not declare the http://www.foo.org/bar namespace.

  <foo:A xmlns:foo="http://www.foo.org/foo">
     <foo:B>
        <bar:C>baz</bar:C>   <=== Error! bar prefix never declared
     </foo:B>
  </foo:A>

To solve this problem, you must explicitly add an xmlns:bar attribute to declare the http://www.foo.org/bar namespace. (Unlike SAX 2.0, DOM Level 2 treats namespace declarations (xmlns attributes) as normal attributes.)

   // Create a text node.

   Text text = document.createTextNode("baz");

   // Create the bar:C element and add the text node

   Element elementbarC = document.createElementNS("http://www.foo.org/bar",
                                                  "bar:C");
   elementbarC.appendChild(text);

   // Add an xmlns:bar attribute to the bar:C element. The first argument
   // is the namespace associated with the xmlns prefix, the second
   // argument is the attribute name, and the third argument is the value
   // of the attribute (the namespace being declared).

   elementbarC.setAttributeNS("http://www.w3.org/2000/xmlns/",
                              "xmlns:bar",
                              "http://www.foo.org/bar");

   // Add the bar:C element as a child of foo:B

   elementfooB.appendChild(elementbarC);

The DOM tree will now be serialized as follows:

  <foo:A xmlns:foo="http://www.foo.org/foo">
     <foo:B>
        <bar:C xmlns:bar="http://www.foo.org/bar">baz</bar:C>
     </foo:B>
  </foo:A>

A similar situation occurs when copying nodes from one document to another. In particular, if an element or attribute being copied relies on a namespace declared in an ancestor element, the namespace will need to be redeclared in the new document.

For complete details, see the DOM Level 2 recommendation.

11.6 How do I use XML namespaces with DOM Level 3?

DOM Level 3 supports namespaces in the same way as DOM Level 2, except that it adds a few new methods and supports version 1.1 of the Namespaces in XML recommendation. The most important new method is Document.normalizeDocument which, among other things, cleans up namespace declarations. Thus, it is no longer necessary to explicitly add namespace declarations (xmlns attributes). Instead, you can call Document.normalizeDocument and the DOM implementation will do it for you. (Exactly what is done depends on a number of configuration parameters. See DOMConfiguration for details.)

For example, the DOM Level 2 code in question 11.5 to add an element in a new namespace to an existing DOM tree becomes:

   // Create a text node.

   Text text = document.createTextNode("baz");

   // Create the bar:C element and add the text node

   Element elementbarC = document.createElementNS("http://www.foo.org/bar",
                                                  "bar:C");
   elementbarC.appendChild(text);

   // Add the bar:C element as a child of foo:B

   elementfooB.appendChild(elementbarC);

   // Call Document.normalizeDocument to add a declaration (xmlns attribute) for the
   // http://www.foo.org/bar namespace.

   document.normalizeDocument();

For complete details, see Appendix A: Changes of the DOM Level 3 recommendation.

11.7 Can an application process documents that use XML namespaces and documents that don't use XML namespaces?

Yes.

This is a common situation for generic applications, such as editors, browsers, and parsers, that are not wired to understand a particular XML language. Such applications simply treat all element type and attribute names as qualified names. Those names that are not mapped to an XML namespace -- that is, unprefixed element type names in the absence of a default XML namespace and unprefixed attribute names -- are simply processed as one-part names, such as by using a null XML namespace name.

Note that such applications must decide how to treat documents that do not conform to the XML namespaces recommendation. For example, what should the application do if an element type name contains a colon (thus implying the existence of a prefix), but there are no XML namespace declarations in the document? The application can choose to treat this as an error, or it can treat the document as one that does not use XML namespaces, ignore the "error", and continue processing.

11.8 Can an application be both namespace-aware and namespace-unaware?

Yes.

However, there is generally no reason to do this. The reason is that most applications understand a particular XML language, such as one used to transfer sales orders between companies. If the element type and attribute names in the language belong to an XML namespace, the application must be namespace-aware; if not, the application must be namespace-unaware. For example, such an application should never need to recognize the element type names SalesOrder and {http://www.tu-darmstadt.de/ito/sales}SalesOrder.

For a few applications, being both namespace-aware and namespace-unaware makes sense. For example, a parser might choose to redefine validity in terms of expanded names (see Namespace Myth #9) and have both namespace-aware and namespace-unaware validation modes. However, such applications are uncommon.

11.9 What does a namespace-aware application do when it encounters an error?

The XML namespaces recommendation does not specify what a namespace-aware application does when it encounters a document that does not conform to the recommendation. Therefore, the behavior is application-dependent. For example, the application could stop processing, post an error to a log and continue processing, or ignore the error.

Part III: Names, Prefixes, and URIs

Section 12.0: Names

12.1 What is a qualified name?

A qualified name is a name of the following form. It consists of an optional prefix and colon, followed by the local part, which is sometimes known as a local name.

  <i>prefix</i>:<i>local-part</i>
        --OR--
  <i>local-part</i>

For example, both of the following are qualified names. The first name has a prefix of serv; the second name does not have a prefix. For both names, the local part (local name) is Address.

  serv:Address
  Address

In most circumstances, qualified names are mapped to expanded names. For more information, see question 12.6.

12.2 What is a QName?

A QName is a qualified name. The term comes from the BNF used in the Namespaces in XML recommendation, where QName is the name of the non-terminal used to give the syntax for a qualified name.

Unfortunately, the term QName is commonly used as a shorthand for expanded name (see question 12.12). This probably derives from the QName data type in XML Schemas, which has expanded names as its value space and qualified names as its lexical space.

12.3 What characters are allowed in a qualified name?

The prefix can contain any character that is allowed in the Name [5] production in XML 1.0 except a colon. The same is true of the local name. Thus, there can be at most one colon in a qualified name -- the colon used to separate the prefix from the local name.

12.4 Where can qualified names appear?

Qualified names can appear anywhere an element type or attribute name can appear: in start and end tags, as the document element type, and in element type and attribute declarations in the DTD. For example:

  <!DOCTYPE foo:A [
     <!ELEMENT foo:A (foo:B)>
     <!ATTLIST foo:A
               foo:C CDATA #IMPLIED>
     <!ELEMENT foo:B (#PCDATA)>
  ]>
  <foo:A xmlns:foo="http://www.foo.org/" foo:C="bar">
     <foo:B>abcd</foo:B>
  </foo:A>

Qualified names cannot appear as entity names, notation names, or processing instruction targets.

12.5 Can qualified names be used in attribute values?

Yes, but they have no special significance. That is, they are not necessarily recognized as such and mapped to expanded names. For example, the value of the C attribute in the following is the string "foo:D", not the expanded name {http://www.foo.org/}D.

  <foo:A xmlns:foo="http://www.foo.org/">
     <foo:B C="foo:D"/>
  </foo:A>

In spite of this, there is nothing to stop an application from recognizing a qualified name in an attribute value and processing it as such. This is being done in various technologies today. For example, in the following XML Schemas definition, the attribute value xs:string identifies the type of the foo attribute as the expanded name {http://www.w3.org/1999/XMLSchema}string.

   <xs:attribute name="foo" type="xs:string" />

There are two potential problems with this. First, the application must be able to retrieve the prefix mappings currently in effect. Fortunately, both SAX 2.0 and DOM Levels 2 and 3 support this capability. Second, any general purpose transformation tool, such as one that writes an XML document in canonical form and changes namespace prefixes in the process, will not recognize qualified names in attribute values and therefore not transform them correctly. Although this may be solved in the future by the introduction of the QName (qualified name) data type in XML Schemas, it is a problem today.

12.6 How are qualified names mapped to names in XML namespaces?

If a qualified name in the body of a document (as opposed to the DTD) includes a prefix, then that prefix is used to map the local part of the qualified name to an expanded name -- that is, a name in an XML namespace. (Note that the prefix must be in scope -- see section 6.) For example, in the following, the prefix foo is used to map the local names A, B, and C to names in the http://www.foo.org/ namespace:

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

If a qualified name in the body of a document does not include a prefix and a default XML namespace is in scope then one of two things happens. If the name is used as an element tag, it is mapped to a name in the default XML namespace. If it is used as an attribute name, it is not in any XML namespace (see Namespace Myth #4). For example, in the following, A and B are in the http://www.foo.org/ namespace and C is not in any XML namespace:

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

If a qualified name in the body of a document does not include a prefix and no default XML namespace is in scope, then that name is not in any XML namespace. For example, in the following, A, B, and C are not in any XML namespace:

  <?xml version="1.0" ?>
  <A C="bar">
     <B>abcd</B>
  </A>

Qualified names in the DTD are never mapped to names in an XML namespace because they are never in the scope of an XML namespace declaration. (For more information, see question 7.2.)

12.7 What is a prefixed name?

A prefixed name is a qualified name (see question 12.1) that contains a prefix.

12.8 What is an unprefixed name?

An unprefixed name is a qualified name (see question 12.1) that does not contain a prefix.

12.9 Are unprefixed names in an XML namespace?

Only if they are used in the body of a document (as opposed to the DTD) as an element tag and a default XML namespace is in scope. For more information, see question 5.2.

12.10 What is a local name?

This is another term for the local part of a qualified name. For more information, see question 12.1.

12.11 What is a namespace name?

This is the name used to identify a namespace. It is a URI reference. For more information, see question 14.1.

12.12 What is an expanded name?

An expanded name is a two part name consisting of an XML namespace name and a local name. For example, in the following, the expanded name is the namespace name "http://www.tu-darmstadt.de/ito/servers" plus the local name "Address":

  <serv:Address xmlns:serv="http://www.tu-darmstadt.de/ito/servers">
     123.45.67.8
  </serv:Address>

The ability to specify expanded names is the only function of XML namespaces.

12.13 What is an expanded QName?

An expanded QName is an expanded name. The term comes from the XQuery recommendation, which presumably uses the term instead of expanded name because it deals with other names as well.

12.14 What is a universal name?

A universal name is an expanded name. The term comes from an article by James Clark and was used in an earlier version of this FAQ. (The first edition of the Namespaces in XML 1.0 recommendation did not provide a term for this concept; the term expanded name was introduced in the second edition.)

12.15 How are expanded names represented?

There is no standard way to represent a expanded name. However, three representations are common.

The first representation keeps the XML namespace name and the local name separate. For example, many DOM Level 1 implementations have different methods for returning the XML namespace name and the local name of an element or attribute node.

The second representation concatenates the namespace name and the local name with caret (^). The result is a universally unique (see question 12.16) name, since carets are not allowed in URI references or local names. This is the method used by John Cowan's Namespace SAX Filter, which was written to handle XML namespaces in SAX 1.0. For example, the expanded name that has the URI reference http://www.tu-darmstadt.de/ito/servers and the local name Address would be represented as:

  http://www.tu-darmstadt.de/ito/servers^Address

The third representation, which we use in this FAQ, was used in an article by James Clark. It places the XML namespace name in braces and concatenates this with the local name. This notation is suggested only for documentation and I am aware of no code that uses it. For example, the above name would be represented as:

  {http://www.tu-darmstadt.de/ito/servers}Address

12.16 Are expanded names universally unique?

No, but it is reasonable to assume they are.

Expanded element type and attribute names are not guaranteed to be universally unique -- that is, unique within the space of all XML documents -- because it is possible for two different people, each defining their own XML namespace, to use the same URI reference and the same element type or attribute name. However, this occurs only if:

The first case means somebody is cheating when assigning URIs (a process governed by trust) and the second case means that two people within an organization are not paying attention to each other's work. For widely published element type and attribute names, neither case is very likely. Thus, it is reasonable to assume that expanded names are universally unique. (Since both cases are possible, applications that present security risks should be careful about assuming that expanded names are universally unique.)

For information about the ability of expanded names to uniquely identify element types and attributes (as opposed to the names themselves being unique), see Namespace Myth #2.

Section 13.0: XML Namespace Prefixes

13.1 What is an XML namespace prefix?

An XML namespace prefix is a prefix used to specify that a local element type or attribute name is in a particular XML namespace. For example, in the following, the serv prefix specifies that the Address element type name is in the http://www.tu-darmstadt.de/ito/addresses namespace:

  <serv:Addresses xmlns:serv="http://www.tu-darmstadt.de/ito/addresses">

13.2 What characters are allowed in an XML namespace prefix?

The prefix can contain any character that is allowed in the Name [5] production in XML 1.0 except a colon.

Of note, the xml prefix can only be bound to the http://www.w3.org/XML/1998/namespace namespace name. The xmlns prefix cannot be used except to declare namespaces; for example, xmlns:xmlns = "http://www.w3.org/2000/xmlns/" is not a legal namespace declaration.

13.3 Are prefixes significant?

No.

For example, the following are equivalent:

  <serv:Addresses xmlns:serv="http://www.tu-darmstadt.de/ito/addresses">

and

  <foo:Addresses xmlns:foo="http://www.tu-darmstadt.de/ito/addresses">

However, prefixes provide a visual cue to readers. Because of this, software (especially editors) should consider preserving prefixes. For example, this is much easier to read:

  <xsl:stylesheet version="1.0"
                  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                  xmlns:html="http://www.w3.org/TR/xhtml1/strict">
  <xsl:template match="/">
     <html:html>
        <html:head><html:title>Title</html:title></html:head>
        <html:body>
           <xsl:apply-templates/>
        </html:body>
  </xsl:template>
  ...
  </xsl:stylesheet>

than this:

  <aaa:stylesheet version="1.0"
                  xmlns:aaa="http://www.w3.org/1999/XSL/Transform"
                  xmlns:bbb="http://www.w3.org/TR/xhtml1/strict">
  <aaa:template match="/">
     <bbb:html>
        <bbb:head><bbb:title>Title</bbb:title></bbb:head>
        <bbb:body>
           <aaa:apply-templates/>
        </bbb:body>
  </aaa:template>
  ...
  </aaa:stylesheet>

or (much worse yet) this:

  <html:stylesheet version="1.0"
                  xmlns:html="http://www.w3.org/1999/XSL/Transform"
                  xmlns:xsl="http://www.w3.org/TR/xhtml1/strict">
  <html:template match="/">
     <xsl:html>
        <xsl:head><xsl:title>Title</xsl:title></xsl:head>
        <xsl:body>
           <html:apply-templates/>
        </xsl:body>
  </html:template>
  ...
  </html:stylesheet>

In spite of this, people are likely to read significance into prefixes, so it is a good idea to use prefixes appropriate to their XML namespace, such as xslt for the XSLT namespace.

Finally, although prefixes are not significant in element and attribute names, they may be significant when used elsewhere in an XML document, such as in a DTD (see question 7.6) or an attribute value. Because such usage is common -- for example, XML Schemas uses qualified names in attribute values -- it is tempting to think that it is defined by the XML namespaces recommendation. This is not the case: the XML namespaces recommendation only defines the use of prefixes in element and attribute names. The use of prefixes elsewhere in an XML document is defined outside the XML namespaces recommendation and is entirely the responsibility of the defining application. For more information, see question 12.5.

13.4 Can I use the same prefix for more than one XML namespace?

Yes.

For example, in the following, B is in the http://www.foo.org/ namespace and C is in the http://www.bar.org/ namespace:

  <A>
     <foo:B xmlns:foo="http://www.foo.org/">abc</foo:B>
     <foo:C xmlns:foo="http://www.bar.org/">abc</foo:C>
  </A>

Remember, however, that the prefix in an XML namespace declaration overrides the same prefix if that prefix is declared on an ancestor. For example, in the following, C is in the http://www.bar.org/ namespace, not the http://www.foo.org/ namespace:

  <A>
     <foo:B xmlns:foo="http://www.foo.org/">
        <foo:C xmlns:foo="http://www.bar.org/">abc</foo:C>
     </foo:B>
  </A>

In general, it is a good idea to use a prefix for only one XML namespace, as this reduces confusion when reading the document. In spite of this, there is a very real possibility that the same prefix will be used for multiple XML namespaces when combining fragments from different documents. For more information, see question 4.9.

13.5 Can I use more than one prefix for the same XML namespace?

Yes.

For example, in the following, both B and C are in the http://www.foo.org/ namespace:

  <A xmlns:foo="http://www.foo.org/"
     xmlns:bar="http://www.foo.org/">
     <foo:B>abc</foo:B>
     <bar:C>abc</bar:C>
  </A>

More reasonably, this situation might arise when copying or cutting and pasting fragments from one document to another, where each document uses a different prefix for the same namespace. For example, suppose the http://www.foo.org/ namespace uses the foo prefix in one document and the bar prefix in another document. Copying an element from one document to the other might result in a document such as the following. Although this may be confusing to read, it is perfectly legal.

  <A xmlns:foo="http://www.foo.org/">
     <foo:B>abc</foo:B>
     <bar:C xmlns:bar="http://www.foo.org/">abc</bar:C>
  </A>

In general, it is a good idea to use only one prefix for an XML namespace, as this reduces confusion when reading the document.

13.6 How are prefixes declared?

Prefixes are declared in an XML namespace declaration (xmlns attribute). For more information, see question 4.1.

13.7 Can I undeclare a prefix -- that is, dissociate a prefix from an XML namespace?

Yes and no. This is supported in version 1.1, but not in version 1.0. As of this writing [January, 2007], most software appears to support version 1.0, so you should not count on this ability. For information about how to undeclare a prefix, see question 4.7.

Note that in both version 1.0 and 1.1, you can override a prefix (see question 4.5) or let the XML namespace declaration that declares the prefix go out of scope (see question 6.4). You can also undeclare the default XML namespace (see question 4.8).

13.8 What happens if I use a prefix that is not declared?

This results in a namespace error. For example, the following document does not conform to the XML namespaces recommendation.

  <?xml version="1.0" ?>
  <foo:A />

However, the XML namespaces recommendation does not specify what a namespace-aware application does when it encounters a non-conformant document, so the behavior is application-dependent. For example, the application could stop processing, post an error to a log and continue processing, or ignore the error.

13.9 What happens if there is no prefix on an element type name?

If a default XML namespace declaration is in scope, then the element type name is in the default XML namespace. Otherwise, the element type name is not in any XML namespace. For example, in the following, B and C are in the http://www.foo.org/ namespace and A is not in any XML namespace:

  <A>
     <B xmlns="http://www.foo.org/">
        <C>abc</C>
     </B>
  </A>

13.10 What happens if there is no prefix on an attribute name?

The attribute name is not in any XML namespace. That is, the default XML namespace does not apply to unprefixed attribute names.

For more information, see Namespace Myth #4.

Section 14.0: XML Namespace Names (URIs)

14.1 What is an XML namespace name?

An XML namespace name is a URI reference that uniquely identifies the namespace. URI references are used because they are widely understood and well documented. (Note that URI references are different from URIs in that they allow fragment identifiers (#).) Because people may only allocate URIs under their control, it is easy to ensure that no two XML namespaces are identified by the same URI reference.

Note: Version 1.1 of the XML namespaces recommendation uses IRI (Internationalized Resource Identifiers) references instead of URI references.

14.2 What is an XML namespace URI?

An XML namespace URI is an XML namespace name. Although the term is not formally defined in the Namespaces in XML recommendation, it is commonly used.

14.3 What characters are allowed in XML namespace names?

XML namespace names can contain any characters allowed in a URI reference. URI references are compared on a character-by-character basis, so capitalization and use of percent signs (%) are significant. For example, the following all identify the same resource according to the URI specification, but are different namespace names:

   http://www.example.org/wine

   http://www.example.org/wine#

   http://www.Example.org/wine

   http://www.example.org/win%65

14.4 Can I use a relative URI reference as a namespace name?

In version 1.1, the answer is no.

In version 1.0, the answer is yes. However, such usage is deprecated, so you should never do it.

The original XML namespaces recommendation does not explicitly disallow the use of relative URI references as namespace names. Instead, it states that two namespace names are identical if their URI references match character for character. It then notes that non-identical URI references might be functionally equivalent, such as when they differ only in case. Combined with the URI specification (RFC2396), which states that relative URI references take on the base URI of their containing document, this provided a loophole with which to use relative URI references.

When this was discovered more than a year after the recommendation was released it proved hugely controversial. For example, some people wanted to use relative URI references as namespace names so that elements and attributes would have different XML namespace names depending on what document they were in. The objection to this was that it would undermine the purpose of XML namespaces. That is, XML namespaces would no longer provide universally unique names.

After more than two months of discussion, it was decided that relative URI references are not expanded when used as namespace names and that their use was deprecated. That is, suppose that the following document has a URI of "http://www.foo.org/xml/relativeExample.xml".

  <A xmlns:foo="../relativeURI">
     <foo:B>abc</foo:B>
     <bar:C>abc</bar:C>
  </A>

Although the URI reference "../relativeURI" does expand to the URI reference "http://www.foo.org/relativeURI", the name of the XML namespace associated with the foo prefix is "../relativeURI", not the expanded URI reference.

It was also decided that:

For the archives of the mailing list discussing the use of relative URI references as namespace names, see http://lists.w3.org/Archives/Public/xml-uri/. For the results of the W3C XML Plenary Ballot on the use of relative URI references in XML namespace names, see http://www.w3.org/2000/09/xppa.

14.5 What does the URI reference used as an XML namespace name point to?

The URI reference used as an XML namespace name is simply an identifier. It is not guaranteed to point to anything and, in general, it is a bad idea to assume that it does. This point causes a lot of confusion, so we'll repeat it here:

URI REFERNECESs USED AS XML NAMESPACE NAMES ARE JUST IDENTIFIERS. THEY ARE NOT GUARANTEED TO POINT TO ANYTHING.

While this might be confusing when URLs are used as namespace names, it is obvious when other types of URI references are used as namespace names. For example, the following namespace declaration uses an ISBN URN:

   xmlns:xbe="urn:ISBN:0-7897-2504-5"

and the following namespace declaration uses a UUID URN:

   xmlns:foo="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

Clearly, neither namespace name points to anything on the Web.

NOTE: Namespace names that are URLs may point to RDDL documents, although this does not appear to be widely implemented. For details, see the next question.

NOTE: An early version of the W3C's XML Schemas used namespace names to point to an XML Schema document containing the definitions of the element types and attributes named in the namespace. However, this proved very controversial and the idea has been withdrawn.

14.6 Can I resolve the URI reference used as an XML namespace name?

Yes.

You can also eat a tractor, but that doesn't mean it's a good idea. The URI references used as XML namespace names are not guaranteed to point to anything, so there is generally no reason to resolve them. Furthermore, there is nothing in the processing of XML namespaces that requires you to resolve these URI references. Finally, as was noted in the previous question, many types of namespace names are unresolvable on the Web.

That said, some people have advocated placing RDDL (Resource Directory Description Language, pronounced "riddle") documents at the locations pointed to by namespace names. A RDDL document "provides a text description of some class of resources and of individual resources related to that class", including such things as a human-readable description of what the namespace describes and links to resources such as schemas (in a variety of languages), stylesheets, and code. RDDL documents apparently are being used, although it is not clear how widely.

For more information about RDDL and the ideas behind it, see:

14.7 Are any XML namespace names reserved?

Yes.

The namespace name http://www.w3.org/XML/1998/namespace is, by definition, bound to the xml prefix. It cannot be undeclared or bound to any other prefix, nor can the xml prefix be bound to any other namespace name. Note that it is not necessary to declare this namespace, although it is legal to do so.

The namespace name http://www.w3.org/2000/xmlns/ is, by definition, bound to the xmlns prefix. It cannot be declared or undeclared, nor can the xmlns prefix be bound to any other namespace name.

14.8 Why does the XML namespaces recommendation use both prefixes and namespace names? Why not use one or the other?

Using only namespace names doesn't work for technical reasons: URI references can contain characters not allowed in XML names. For example, suppose the namespaces recommendation only used URI references. This would lead to documents such as:

   <http://www.foo.org/:foo>
      <http://www.foo.org/:bar />
   </http://www.foo.org/:foo>

This document is illegal because the slash (/) character is not allowed in element names. Two additional problems are that (a) it is impossible to distinguish the colon (:) in the URL from the colon used to separate the namespace name from the local name, and (b) it is impossible to distinguish the slash in the URL from the slash used to end the empty {http://www.foo.org}bar element. A non-technical problem is that the element names are difficult to read.

Using only prefixes doesn't work for political reasons: there is no naming authority that assigns prefixes, so there is nothing to prevent two people from choosing the same prefix. For example, two different companies creating schemas for sales orders might both want to use the "order" prefix. Without a central naming authority, this dispute could not be resolved. Using URI references avoids this problem, as URIs are controlled by existing organizations, such as domain name registries and the International ISBN Agency.

Part IV: Miscellaneous

Section 15.0: Politics and Revolutions

15.1 Why are XML namespaces so hard to understand?

XML namespaces really aren't that hard to understand -- all the recommendation specifies is a way to map qualified (prefixed) names to universal names. That's it. Nothing else. Unfortunately, most people who learn about XML namespaces have a past history with naming conventions and bring a lot of ideas with them. These ideas make it hard to understand XML namespaces.

Even the term namespaces causes problems. An XML namespace is a collection of names, but the Namespaces in XML recommendation doesn't even talk about this collection beyond its initial definition. (In fact, this collection is so irrelevant that it isn't even mentioned in version 1.1 of the recommendation.) We all would have been much better off if the recommendation had been called "Universal names in XML" or something similar that emphasized the idea of universally unique names, rather any collection of such names.

That said, we can now discuss the main tripping points when learning XML namespaces. There are two primary points that confuse people:

There are a number of other confusing points as well:

For more sources of confusion, see Namespaces a Mess? by Michael Kay.

15.2 Are there any alternatives to XML namespaces?

Yes. You could resolve name clashes by simply renaming the offending element types or attributes and then, during processing, using architectural forms to transform them to names that are recognizeable by different modules in the application. Although you may have to rename some element types or attributes, you won't have to change your application modules. A discussion of architectural forms is beyond the scope of this paper. For more information, see Architectural Forms and SGML/XML Architectures on Robin Cover's XML Cover Pages.

As to the actual syntax used by XML namespaces, the idea of declaring XML namespace prefixes in a processing instruction at the start of an XML document is occasionally raised. Processing instructions were used in an early draft of the XML namespaces specification and have the advantage of simplicity (see question 4.9). They were later replaced with the more flexible xmlns attributes. Although you might be tempted to strike out on your own and use processing instructions or some other strategy, this is probably a bad idea, although not necessarily for technical reasons. The real problem is that XML namespaces are already widely used and supported, so any XML documents you produce will be non-standard and non-portable.

15.3 How controversial are XML namespaces?

The need for XML namespaces and the basic idea that a two-part naming system (or something similar) is needed is not controversial. However, the design of XML namespaces -- that is, the way XML namespaces are declared and used in an XML document -- has, at times, been very controversial. (If you want to see just how controversial, go to the archives of the XML-DEV mailing list and search on the word "namespace" or look at some of the articles on Robin Cover's Namespaces in XML page.)

In spite of these problems, and the fact that XML namespaces will always have some very vocal detractors, most people have accepted and are using them. Furthermore, virtually all commercial XML tools and technologies support them.

Section 16.0: XML Namespace Resources

16.1 What resources are available for learning about XML namespaces?

Recommendations and other somewhat official stuff:

Links to articles about XML namespaces:

Articles about XML namespaces:

More links are welcome.

16.2 What utilities are available for working with XML namespaces?

Virtually all XML software now supports XML namespaces.

Section 17.0: Comments, Complaints, and Suggestions

If you have comments, complaints, or suggestions for new questions, you can mail them to me (Ronald Bourret) at rpbourret@rpbourret.com.

Thanks to Petter Astrom, Juergen Auer, Adrian Boyko, Tim Bray, Derek Denny-Brown, Bob DuCharme, Jean-Paul Coenen, Ken Goldman, Sam Hunting, Madhav Lakkapragada, Andrew Layman, Gustaf Liljegren, Christopher Lott, Marc McDonald, Anders Moller, Randy Nichols, Jim Palmer, Ganesan Radhakrishnan, Arjun Ray, Aron Roberts, Wayne Steele, Richard Tobin, Erik Wilde, and Diwakar Yammanuru for their input.