Chapter 10. Controlling Namespaces

10.1. Namespaces Present Two Challenges to Schema Languages

Namespace prefixes should only be considered to be local shortcuts to replace the URI references that are the real identifiers for a namespace. The following documents should, therefore, be considered strictly equivalent by namespace-aware applications:

<?xml version="1.0"?>
<library xmlns="http://dyomedea.com/ns/library">
  <book id="b0836217462">
    <title>
      Being a Dog Is a Full-Time Job
    </title>
    <authors>
      <person id="CMS">
        <name>
          Charles M Schulz
        </name>
      </person>
    </authors>
  </book>
</library>

In the document above, the namespace "http://dyomedea.com/ns/library" is defined as the default namespace and applies to all the elements within the document. Next, we'll show a namespace-equivalent, but very different-looking, document:

<?xml version="1.0"?>
<!-- Namespace: http://dyomedea.com/ns/library -->
<lib:library xmlns:lib="http://dyomedea.com/ns/library">
  <lib:book id="b0836217462">
    <lib:title>
      Being a Dog Is a Full-Time Job
    </lib:title>
    <lib:authors>
      <lib:person id="CMS">
        <lib:name>
          Charles M Schulz
        </lib:name>
      </lib:person>
    </lib:authors>
  </lib:book>
</lib:library>

The namespace "http://dyomedea.com/ns/library" is defined as mapping to the prefix lib and is used as a prefix for all the elements within the document. Next, we'll create another namespace-equivalent document using a different prefix.

<?xml version="1.0"?>
<!-- Namespace: http://dyomedea.com/ns/library -->
<l:library xmlns:l="http://dyomedea.com/ns/library">
  <l:book id="b0836217462">
    <l:title>
      Being a Dog Is a Full-Time Job
    </l:title>
    <l:authors>
      <l:person id="CMS">
        <l:name>
          Charles M Schulz
        </l:name>
      </l:person>
    </l:authors>
  </l:book>
</l:library>

The namespace "http://dyomedea.com/ns/library" is defined as mapping to the prefix l and is used as a prefix for all the elements within the document. Finally, we'll mix all of these possibilities in a single document still namespace-equivalent to the others.

<?xml version="1.0"?>
<!-- Namespace: http://dyomedea.com/ns/library -->
<l:library xmlns:l="http://dyomedea.com/ns/library">
  <l:book id="b0836217462" xmlns:lib="http://dyomedea.com/ns/library">
    <l:title>
      Being a Dog Is a Full-Time Job
    </l:title>
    <lib:authors>
      <l:person id="CMS" xmlns="http://dyomedea.com/ns/library">
        <name>
          Charles M Schulz
        </name>
      </l:person>
    </lib:authors>
  </l:book>
</l:library>

The same namespace is defined and used as l, lib, and even as a default namespace, depending on its location in the document. This last example is, of course, an extreme case that isn't recommended. This document conforms to the namespaces recommendation, however, and the specification states that it is strictly equivalent to the three previous ones.

DTDs are not aware of the namespaces. Since the colon (:) is allowed in the XML names, lib:person, l:person, and person are three different, valid names for a DTD. Furthermore, a DTD sees namespace declaration attributes (xmlns, xmlns:l, xmlns:lib) as ordinary attributes that need to be declared.

A XML document using namespaces is a well-formed XML 1.0 document and it is perfectly possible to write a DTD to describe it. Nevertheless, you must define the prefixes that can be used and the location where the namespace declarations must be inserted. This is acceptable only if you can fully control or specify the authoring processes of the documents.

The second and larger issue is design. Since XML is often used as the glue between different applications, it is becoming increasingly important to be able to define modular vocabularies that can live together in the same document, and namespaces were invented to make this possible. To take advantage of this feature, it is often necessary to define open vocabularies that will define places where external elements and attributes from external namespaces may be included without breaking the applications.

Imagine a marketing department wants to add the type of cover and the number of pages to the information about a particular book. A neat way to do this--if this new information is specific to their needs and we don't want to break the existing applications--is to create a new namespace:

<?xml version="1.0"?>
<!-- Namespace: http://dyomedea.com/ns/library --> 
<library xmlns="http://dyomedea.com/ns/library"
  xmlns:mkt="http://dyomedea.com/ns/library/mkt">
  <book id="b0836217462">
    <title>
      Being a Dog Is a Full-Time Job
    </title>
    <authors>
      <person id="CMS">
        <name>
          Charles M Schulz
        </name>
      </person>
    </authors>
    <mkt:cover>
      Paperback
    </mkt:cover>
    <mkt:pages>
      128
    </mkt:pages>
  </book>
</library>

However, if we want to keep our schema independent of the marketing application, we need a flexible way to open it and say "accept any element from the marketing namespace at the end of our book element." Also, even if there might be other applications that work with our vocabulary, we can say to accept any element from any other namespace at the end of our book element.