XML Namespaces

An important property of XML documents is that they can be composed to create new documents. This is the most basic mechanism for reusing XML. Unfortunately, simple composition creates the problems of recognition and collision.

To illustrate these problems, consider a scenario where SkatesTown wants to receive its purchase orders via the XML messaging system of XCommerce Messaging, Inc. The format of the messages is simple:

<message from="..." to="..." sent="...">
   <text>
      This is the text of the message.
   </text>
   <!-- A message can have attachments -->
   <attachment>
      <description>Brief description of the attachment.</description>
      <item>
         <!-- XML of attachment goes here -->
      </item>
   </attachment>
</message>

Listing 2.5 shows a complete message with a purchase order attachment.

Listing 2.5 Message with Purchase Order Attachment

<message from="bj@bjskates.com" to="orders@skatestown.com"
   sent="2001-10-05">
   <text>
      Hi, here is what I need this time. Thx, BJ.
   </text>
   <attachment>
      <description>The PO</description>
      <item>
         <po id="43871" submitted="2001-10-05">
            <billTo id="addr-1">
               <company>The Skateboard Warehouse</company>
               <street>One Warehouse Park</street>
               <street>Building 17</street>
               <city>Boston</city>
               <state>MA</state>
               <postalCode>01775</postalCode>
            </billTo>
            <shipTo href="addr-1"/>
            <order>
               <item sku="318-BP" quantity="5">
                  <description>
                     Skateboard backpack; five pockets
                  </description>
               </item>
               <item sku="947-TI" quantity="12">
                  <description>
                     Street-style titanium skateboard.
                  </description>
               </item>
               <item sku="008-PR" quantity="1000"/>
            </order>
         </po>
      </item>
   </attachment>
</message>

It is relatively easy to identify the two problems mentioned earlier in the composed document:

Recognition— How does an XML processing application distinguish between the XML elements that describe the message and the XML elements that are part of the purchase order?
Collision— Does the element description refer to attachment descriptions in messages or order item descriptions? Does the item element refer to an item of attachment or an order item?

Very simple applications might not be bothered by these problems. After all, the knowledge of what an element means can reside in the application logic. However, as application complexity increases and the number of applications that need to work with some particular composed document type grows, the need to clearly distinguish between the XML elements becomes paramount. The XML Namespaces specification brings order to the chaos.

Namespace Mechanism

The problem of collision in composed XML documents arises because of the likelihood of elements with common names (description, item, and so on) to be reused in different document types. This problem can be addressed by qualifying an XML element name with an additional identifier that is much more likely to be unique within the composed document. In other words:

Qualified name (a.k.a. QName) = Namespace identifier + Local name

This approach is similar to how namespaces are used in languages such as C++ and C# and to how package names are used in the Java programming language.

The problem of recognition in composed XML documents arises because no good mechanism exists to identify all elements belonging to the same document type. Given namespace qualifiers, the problem is addressed in a simple way—all elements that have the same namespace identifier are considered together.

For identifiers, XML Namespaces uses Uniform Resource Identifiers (URIs). URIs are described in RFC 2396. URIs are nothing fancy, but they are very useful. They can be locators, names, or both. URI locators are known as Uniform Resource Locators (URLs), a term familiar to all using the Web. URLs are strings such as http://www.skatestown.com/services/POSubmission and mailto:orders@skatestown.com.

Uniform Resource Names (URNs) are URIs that are globally unique and persistent . Universally Unique Identifiers (UUIDs) are perfect for use as URNs. UUIDs are 128-bit identifiers that are designed to be globally unique. Typically, they combine network card (Ethernet) addresses with a high-precision timestamp and an increment counter. An example URN using a UUID is urn:uuid:2FAC1234-31F8-11B4-A222-08002B34C003. UUIDs are used as unique identifiers in Universal Description Discovery and Integration (UDDI) as detailed in Chapter 7, "Discovering Web Services."

Namespace Syntax

Because URIs can be rather long and typically contain characters that are not allowed in XML element names, the syntax of including namespaces in XML documents involves two steps:

A namespace identifier is associated with a prefix, a name that contains only legal XML element name characters with the exception of the colon (:).
Qualified names are obtained as a combination of the prefix, the colon character, and the local element name, as in myPrefix:myElementName.

Listing 2.6 shows an example of the composed XML document using namespaces.

Listing 2.6 Message with Namespaces

<msg:message from="bj@bjskates.com" to="orders@skatestown.com"
   sent="2001-10-05" xmlns:msg="http://www.xcommercemsg.com/ns/message"
   xmlns:po="http://www.skatestown.com/ns/po">
   <msg:text>
      Hi, here is what I need this time. Thx, BJ.
   </msg:text>
   <msg:attachment>
      <msg:description>The PO</msg:description>
      <msg:item>
         <po:po id="43871" submitted="2001-10-05">
            <po:billTo id="addr-1">
               <po:company>The Skateboard Warehouse</po:company>
               <po:street>One Warehouse Park</po:street>
               <po:street>Building 17</po:street>
               <po:city>Boston</po:city>
               <po:state>MA</po:state>
               <po:postalCode>01775</po:postalCode>
            </po:billTo>
            <po:shipTo href="addr-1"/>
            <po:order>
               <po:item sku="318-BP" quantity="5">
                  <po:description>
                     Skateboard backpack; five pockets
                  </po:description>
               </po:item>
               <po:item sku="947-TI" quantity="12">
                  <po:description>
                     Street-style titanium skateboard.
                  </po:description>
               </po:item>
               <po:item sku="008-PR" quantity="1000"/>
            </po:order>
         </po:po>
      </msg:item>
   </msg:attachment>
</msg:message>

In this example, the elements prefixed with msg are associated with a namespace whose identifier is http://www.xcommercemsg.com/ns/message, and those prefixed with po are associated with a namespace whose identifier is http://www.skatestown.com/ns/po. The prefixes are linked to the complete namespace identifiers by the attributes on the top message element beginning with xmlns: (xmlns:msg and xmlns:po). XML processing software will have access to both the prefixed name and to the mapping of prefixes to complete namespace identifiers.

Adding a prefix to every single element in the document somewhat decreases readability and increases document size. Therefore, XML Namespaces let you use a default namespace in a document. Elements belonging to the default namespace do not require prefixes. Listing 2.7 makes the msg namespace the default.

Listing 2.7 Using Default Namespaces

<message from="bj@bjskates.com" to="orders@skatestown.com"
   sent="2001-10-05" xmlns ="http://www.xcommercemsg.com/ns/message"
   xmlns:po="http://www.skatestown.com/ns/po">
   <text>
      Hi, here is what I need this time. Thx, BJ.
   </text>
   <attachment>
      <description>The PO</description>
      <item>
         <po:po id="43871" submitted="2001-10-05">
            ...
         </po:po>
      </item>
   </attachment>
</message>

Default namespaces work because the content of any namespace-prefixed element is considered to belong to the namespace of its parent element unless, of course, the element is explicitly defined to be in another namespace with its own xmlns-type attribute. We can use this to further clean up the composed XML document by moving the PO namespace declaration to the po element (see Listing 2.8).

Listing 2.8 Using Nested Namespace Defaulting

<message from="bj@bjskates.com" to="orders@skatestown.com"
   sent="2001-10-05" xmlns="http://www.xcommercemsg.com/ns/message">
   <text>
      Hi, here is what I need this time. Thx, BJ.
   </text>
   <attachment>
      <description>The PO</description>
      <item>
         <po:po id="43871" submitted="2001-10-05"
            xmlns:po="http://www.skatestown.com/ns/po">
            <billTo id="addr-1">
               ...
            </billTo>
            <shipTo href="addr-1"/>
            <order>
               ...
            </order>
         </po:po>
      </item>
   </attachment>
</message>

This example shows an efficient, readable syntax that completely eliminates the recognition and collision problems. XML processors can identify the namespace of any element in the document.

Namespace-Prefixed Attributes

Attributes can also have namespaces associated with them. Initially, it might be hard to imagine why a capability like this would be useful for XML applications. The common use-case scenario is the desire to extend the information provided by an XML element without having to make changes directly to its document type.

A concrete example might involve SkatesTown wanting to have an indication of the priority of certain items in purchase orders. High-priority items could be shipped immediately, without waiting for any back-ordered items to become available and complete the whole order. Item priorities are not something that SkatesTown's automatic order processing software understands. They are just a hint for the fulfillment system on how it should react in case of back-ordered items.

A simple implementation could involve extending the item element with an optional priority attribute. However, this could cause a problem for the order processing software that does not expect to see such an attribute. A better solution is to attach priority information to items using a namespace-prefixed priority attribute. Because the attribute will be in a namespace different from that of the item element, the order processing software will simply ignore it.

The example in Listing 2.9 uses this mechanism to make the backpacks high priority and the promotional materials low priority. By default, any items without a priority attribute, such as the skateboards, are presumed to be of medium priority.

Listing 2.9 Adding Priority to Order Items

<message from="bj@bjskates.com" to="orders@skatestown.com"
   sent="2001-10-05" xmlns="http://www.xcommercemsg.com/ns/message">
   <text>
      Hi, here is what I need this time. Thx, BJ.
   </text>
   <attachment>
      <description>The PO</description>
      <item>
         <po:po id="43871" submitted="2001-10-05"
            xmlns:po="http://www.skatestown.com/ns/po">
            xmlns:p="http://www.skatestown.com/ns/priority">
            ...
            <po:order>
               <po:item sku="318-BP" quantity="5" p:priority="high">
                  <po:description>
                     Skateboard backpack; five pockets
                  </po:description>
               </po:item>
               <po:item sku="947-TI" quantity="12">
                  <po:description>
                     Street-style titanium skateboard.
                  </po:description>
               </po:item>
               <po:item sku="008-PR" quantity="1000" p:priority="low"/>
            </po:order>
         </po:po>
      </item>
   </attachment>
</message>

Dereferencing URIs

All the examples in this section have used namespace URIs that are URLs. A natural question arises: What is the resource at that URL? The answer is that it doesn't matter. XML Namespaces does not require that a resource be there. The URI is used entirely for identification purposes.

This could cause problems for applications that see an unknown namespace in an XML document and have no way to obtain more information about the elements and attributes that belong to that namespace. Later in this chapter, in the section on XML Schemas, you will see a mechanism that addresses this issue.