XML Namespaces

Inexperienced programmers sometimes overlook XML's ability to partition a single document into multiple sections or to represent multiple concepts in a single document by using namespaces. These collections of tag and attribute names are bound together using prefixes, and kept separate from tags and attributes in other namespaces.

In Listing 14.9, the single company document in Listing 14.3 is extended by adding starting salary information and putting directory information in its own namespace.

Listing 14.9. ExtendedCompany.xmlThe <company> EnTRy with Starting Salary Information Added

 <company   xmlns:directory="http://www.mycompany.com/directory"   xmlns:salary="http://www.mycompany.com/salary">   <directory:employee ssn="123-45-6789">     <directory:first-name>Ed</directory:first-name>     <directory:last-name>Johnson</directory:last-name>     <directory:department>Human Resources</directory:department>   </directory:employee>   <directory:employee ssn="541-29-8376">     <directory:first-name>Maria</directory:first-name>     <directory:last-name>Smith</directory:last-name>     <directory:department>Accounting</directory:department>   </directory:employee>   <directory:employee ssn="568-73-1924">     <directory:first-name>Eric</directory:first-name>     <directory:last-name>Masters</directory:last-name>     <directory:department>Accounting</directory:department>   </directory:employee>   <salary:starting-salaries>     <salary:low>32000</salary:low>     <salary:avg>56000</salary:avg>     <salary:high>78000</salary:high>   </salary:starting-salaries> </company> 

Namespaces are also important to XML schemas, as you will see later. In essence, namespaces separate parts of an XML document that serve distinct functionality.

In Listing 14.9, we declare two namespaces: one for elements concerning a company's directory entry, and another for the company's starting salary information. As a result, while I'm storing only one document, that document can store two different kinds of information together, with two completely separate schemas.

Another benefit of namespaces has to do with portability. Listing 14.10 shows another XML document with the same information as in Listing 14.9, but using different namespace prefixes.

Listing 14.10. ExtendedCompany2.xmlAnother XML Document with Different Namespace Prefixes

 <company   xmlns:dir="http://www.mycompany.com/directory"   xmlns:sal="http://www.mycompany.com/salary">   <dir:employee ssn="123-45-6789">     <dir:first-name>Ed</dir:first-name>     <dir:last-name>Johnson</dir:last-name>     <dir:department>Human Resources</dir:department>   </dir:employee>   <dir:employee ssn="541-29-8376">     <dir:first-name>Maria</dir:first-name>     <dir:last-name>Smith</dir:last-name>     <dir:department>Accounting</dir:department>   </dir:employee>   <dir:employee ssn="568-73-1924">     <dir:first-name>Eric</dir:first-name>     <dir:last-name>Masters</dir:last-name>     <dir:department>Accounting</dir:department>   </dir:employee>   <sal:starting-salaries>     <sal:low>32000</sal:low>     <sal:avg>56000</sal:avg>     <sal:high>78000</sal:high>   </sal:starting-salaries> </company> 

Listings 14.9 and 14.10 are the exact same document, even though the namespace prefixes are different. What makes the namespaces unique is not the prefix before the name, but rather the URI (Uniform Resource Identifier) to which you bind the prefix. (In Listings 14.9 and 14.10, the URIs were http://www.mycompany.com/directory and http://www.mycompany.com/salary.) When two different documents bind two distinct prefixes to the same URI, then those two prefixes represent the same namespace.

NOTE

The difference between a URI and a URL is very small. A URL (Uniform Resource Locator) is always a Web address. A URI is a more general term for any unique identifier used to identify something. A URL is a type of URI.

The URIs used in the xmlns attributes in Listings 14.9 and 14.10 do not have to point to anything in particular. Parsers will not retrieve anything from the URI specified at that address. The namespace URI is merely a unique identifier for that namespace that keeps one namespace separate from another. That said, it's usually a good idea to use the namespace URI to point to one of two things:

• Your company's home page. In cases where multiple companies use XML to transfer and store information in a single document, the namespace URI can be a way to self-document the relationship of nodes to companies.

• A Web address at your company that gives information about the schema. This is a way of linking your XML file directly to its documentation. Although parsers will not use the document at this address, someone who reads the file and wants to know what's going on will be able to visit the URL and find out. (The W3C does this.)

The Default Namespace

Most developers are surprised to learn that even if no namespaces are declared in their document, they are still using a namespace. Even Listing 14.1 had a namespace. The only difference between the namespace in Listing 14.1 and the ones in Listing 14.9 are that the namespaces in Listing 14.9 are explicitly declared.

A namespace without a prefix is called a default namespace. Any tags that are not part of an explicitly declared namespace are part of this default namespace. To bind the default namespace to a URI, use the following syntax:

 <element xmlns="http://www.mycompany.com" /> 

When to Use Namespaces

Namespaces are not always useful, but here are some situations when you should consider using a namespace:

• When you are writing a solution to communicate between companies (or even divisions within a company). Separating namespaces lets each company or division define its own functionality and own rules for interaction.

• When you are using XML to control the behavior of a modular application. Separating functionality into discrete namespaces lets you change parts of the application without affecting others, especially when a schema change is involved. Usually you will want to use one namespace per module.

This list is not exhaustive; it is only meant to give you an idea of some of the situations in which namespaces are useful.

Because the rest of the chapter focuses on schemas, we will be making heavy use of namespaces. In the next chapter, you will also get a real-world idea of how namespaces make XSLT possible.