Overview of Namespaces

As you saw in the previous chapter, the primary units of content in XML are elements and attributes. Authors distinguish among different types of elements and attributes by assigning them unique names . When applications process a document, they associate element content with the corresponding element name and attribute content with the corresponding attribute name .

As people started to use XML, they realized that organizations and application often use the same name to describe different concepts. When these organizations want to exchange information using XML, conflicts may occur. A single document often combines information intended for multiple organizations and applications. For example, most mail order vendors do not charge customers until they ship the ordered goods. Enforcing this policy requires processing the same information with an Accounting application for billing purposes and a Fulfillment application for shipping purposes.

But what if the Accounting and Fulfillment applications use the term "status" to signify different meanings? Both applications want their respective status data associated with the "Status" element name. Such a naming collision has the potential to make life very uncomfortable for developers responsible for specifying the formats of affected documents.

XML Namespaces , a W3C Recommendation, enables developers to avoid naming collisions by assigning element and attribute names to namespaces . Accounting and Fulfillment departments could each have separate namespaces. Developers can thereby qualify the use of the "Status" element name with the appropriate namespace.

How It Works

Figure 3-2 illustrates how namespaces can resolve the conflict between the Accounting and Fulfillment applications. A Reconciliation Document consolidates billing and shipping information about a given order. When the billing status is "invoiced" and the shipping status is "shipped," the document goes to both the Accounting and Fulfillment applications.

Figure 3-2. Resolving a Conflict with Namespaces

When the Accounting application processes the document, it wants to use "Status" as a keyword to signify billing status. When the Fulfillment application processes the document, it wants to use "Status" as a keyword to signify shipping status. Moreover, the same problem extends to other keywords. Example 3-1 shows how to solve this problem using XML Namespaces.

Example 3-1

 <Reconciliation  xmlns:acct=http://www.foocompany.com/names/acct-REV10  xmlns:ful="http://www.foocompany.com/names/ful-REV10">  <acct:Customer>   <acct:Name>Bar Corporation</acct:Name>   <acct:Addressee>    Accounts PayableBar Corporation   </acct:Addressee>   <acct:Order acct:reference="5566-1010">    <acct:Status>invoice</acct:Status>   </acct:Order>  </acct:Customer>  <ful:Customer>   <ful:Name>Bar Corporation</ful:Name>   <ful:Addressee>    Loading DockBar Corporation   </ful:Addressee>   <ful:Order ful:reference="A9875656">    <ful:Status>shipped</ful:Status>   </ful:Order>  </ful:Customer> </Reconciliation> 

As you can see, attaching the namespace identifier to an element or attribute name with a colon associates that namespace with that element or attribute. Before you use a namespace, you associate the namespace prefix with the namespace name , using the reserved XML attribute "xmlns." The namespace name is a Uniform Resource Identifier ( URI ) , essentially indicating that the owner of an Internet resource is the owner of the namespace. In this case, "acct" signifies the namespace owned by the Accounting department of Foo Company, and "ful" signifies the namespace owned by the Fulfillment department of Foo Company. The example uses the common convention of declaring all namespaces in the document element. This convention enables human readers and software processors to determine easily all the namespaces that may be used subsequently.

Attaching the appropriate prefix to all element and attribute names can be cumbersome. To avoid this chore, you can also set a default namespace, which applies to all contained names, as shown in Example 3-2.

Example 3-2

 <Reconciliation  <Customer   xmlns="http://www.foocompany.com/names/acct-REV10">   <Name>Bar Corporation</Name>   <Addressee>    Accounts PayableBar Corporation   </Addressee>   <Order reference="5566-1010">    <Status>invoice</Status>   </Order>  </Customer>  <Customer   xmlns="http://www.foocompany.com/names/ful-REV10">   <Name>Bar Corporation</Name>   <Addressee>    Loading DockBar Corporation   </Addressee>   <Order reference="A9875656">    <Status>shipped</status>   </Order>  </Customer> </Reconciliation> 

In Example 3-2, we first set a default Accounting namespace by specifying the value of the "xmlns" attribute without attaching a namespace prefix. All names within the first "Customer" element automatically use the Accounting namespace. Then we set a default namespace Fulfillment for the second Customer element. You can also set a default namespace and then use the syntax in Example 3-1 to specify a different namespace for particular elements or attributes. The combination of the two mechanisms for specifying namespaces delivers a convenient and flexible way to avoid naming collisions.

Practical Usage

In practice, the most important application of XML Namespaces comes when using the related feature standards. For example, a given document may have wrapper tags from an XML messaging standard, tags for domain-specific XML content, and tags from the XLink standard, specifying links to other documents. Without XML Namespaces, it would be impossible to ensure that the correct type of processing component received the elements intended for it. As you will see in the subsequent sections of this chapter, each of the other feature standards has its own namespace to avoid this problem.

In deciding whether to define your own namespaces, consider that the need for them increases in direct proportion to the number of different groups that will use a document format. In the case of industry-specific standards, this need is obviously quite high. The industry standards body does not want the format it defines to conflict with any of the internally defined formats of its members . An enterprisewide format for a large multinational corporation would also almost certainly need to use XML Namespaces so that it would not conflict with any local formats. However, a format intended for use by two parties, each of which plans to construct a dedicated application, might be able to get away without XML Namespaces. But it would probably be a good idea to use them anyway, in case the parties decide to expand the number of participants . A format used only by a single application for internal purposes almost certainly does not need XML Namespaces.

If you work for a software vendor that uses XML in a product, you will want to define a namespace if your XML features are visible to external developers or applications. Typically, using the Internet domain name for your company, the name of the product, and a version identifier will be sufficient.

If you work for a large enterprise that uses XML in an integration or e-commerce application, the proper approach for constructing namespaces is less clear. Of course, you use the domain name of your company for the first part of the namespace and a version identifier for the last part. But the middle part takes some thought. You can use a path that mirrors your organizational chart, but organizational charts may change rather often. If your enterprise has an organizational directory based on a standard data model such as X.500 or LDAP , you may be able to leverage that. In any case, an officially designated person should coordinate the policy used by all groups developing XML applications.