Namespace Syntax (XML in a Nutshell, 2nd Edition)

4.2. Namespace Syntax

Namespaces disambiguate elements with the same name from each other by assigning elements and attributes to URIs. Generally, all the elements from one XML application are assigned to one URI, and all the elements from a different XML application are assigned to a different URI. These URIs are sometimes called namespace names. The URIs partition the elements and attributes into disjoint sets. Elements with the same name but different URIs are different elements. Elements with the same name and the same URIs are the same. Most of the time there's a one-to-one mapping between namespaces and XML applications, though a few applications use multiple namespaces to subdivide different parts of the application. For instance, XSL uses different namespaces for XSL Transformations (XSLT) and XSL Formatting Objects (XSL-FO).

4.2.1. Qualified Names, Prefixes, and Local Parts

Since URIs frequently contain characters such as /, %, and ~ that are not legal in XML names, short prefixes such as rdf and xsl stand in for them in element and attribute names. Each prefix is associated with a URI. Names whose prefixes are associated with the same URI are in the same namespace. Names whose prefixes are associated with different URIs are in different namespaces. Prefixed elements and attributes in namespaces have names that contain exactly one colon. They look like this:

rdf:description
xlink:type
xsl:template

Everything before the colon is called the prefix. Everything after the colon is called the local part. The complete name including the colon is called the qualified name, QName, or raw name. The prefix identifies the namespace to which the element or attribute belongs. The local part identifies the particular element or attribute within the namespace.

In a document that contains both SVG and MathML set elements, one could be an svg:set element, and the other could be a mathml:set element. Then there'd be no confusion between them. In an XSLT stylesheet that transforms documents into XSL formatting objects, the XSLT processor would recognize elements with the prefix xsl as XSLT instructions and elements with the prefix fo as literal result elements.

Prefixes may be composed from any legal XML name character except the colon. Prefixes beginning with the three letters xml (in any combination of case) are reserved for use by XML and its related specifications. Otherwise, you're free to name your prefixes in any way that's convenient. One further restriction namespaces add to XML 1.0 is that the local part may not contain any colons. In short, the only legal uses of a colon in XML are to separate a namespace prefix from the local part in a qualified name or for the attributes XML itself defines, such as xml:space and xml:lang.

4.2.2. Binding Prefixes to URIs

Each prefix in a qualified name must be associated with a URI. For example, all XSLT elements are associated with the http://www.w3.org/1999/XSL/Transform URI. The customary prefix xsl is used in place of the longer URI http://www.w3.org/1999/XSL/Transform.

TIP: You can't use the URI in the name directly. For one thing, the slashes in most URIs aren't legal characters in XML names. However, it's occasionally useful to refer to the full name without assuming a particular prefix. One convention used on many XML mailing lists and in XML documentation is to enclose the URI in curly braces and prefix it to the name. For example, the qualified name xsl:template might be written as the full name {http://www.w3.org/1999/XSL/Transform}template. Another convention is to append the local name to the namespace name after a sharp sign so that it becomes a URI fragment identifier. For example, http://www.w3.org/1999/XSL/Transform#template. However, both forms are only conveniences for communication among human beings when the URI is important but the prefix isn't. Neither an XML parser nor an XSLT processor will accept or understand the long forms.

Prefixes are bound to namespace URIs by attaching an xmlns:prefix attribute to the prefixed element or one of its ancestors. (The prefix should be replaced by the actual prefix used.) For example, the xmlns:rdf attribute of this rdf:RDF element binds the prefix rdf to the namespace URI http://www.w3.org/TR/REC-rdf-syntax#:

<rdf:RDF xmlns:rdf="http://www.w3.org/TR/REC-rdf-syntax#">
 <rdf:Description
      about="http://www.cafeconleche.org/examples/impressionists.xml">
    <title> Impressionist Paintings </title>
    <creator> Elliotte Rusty Harold </creator>
    <description>
      A list of famous impressionist paintings organized
      by painter and date
    </description>
    <date>2000-08-22</date>
  </rdf:Description>
</rdf:RDF>

Bindings have scope within the element where they're declared and within its contents. The xmlns:rdf attribute declares the rdf prefix for the rdf:RDF element, as well as its child elements. An RDF processor will recognize rdf:RDF and rdf:Description as RDF elements because both have prefixes bound to the particular URI specified by the RDF specification. It will not consider the title, creator, description, and date elements to be RDF elements because they do not have prefixes bound to the http://www.w3.org/TR/REC-rdf-syntax# URI.

The prefix can be declared in the topmost element that uses the prefix or in any ancestor thereof. This may be the root element of the document, or it may be an element at a lower level. For instance, the Dublin Core elements could be attached to the http://purl.org/dc/ namespace by adding an xmlns:dc attribute to the rdf:Description element, as shown in Example 4-3, since all Dublin Core elements in this document appear inside a single rdf:Description element. In other documents that spread the elements out more, it might be more convenient to put the namespace declaration on the root element. If necessary, a single element can include multiple namespace declarations for different namespaces.

Example 4-3. A document containing both SVG and XLinks

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<catalog>

  <rdf:RDF xmlns:rdf="http://www.w3.org/TR/REC-rdf-syntax#">
    <rdf:Description xmlns:dc="http://purl.org/dc/"
       about="http://www.cafeconleche.org/examples/impressionists.xml">
      <dc:title> Impressionist Paintings </dc:title>
      <dc:creator> Elliotte Rusty Harold </dc:creator>
      <dc:description>
        A list of famous impressionist paintings organized
        by painter and date
      </dc:description>
      <dc:date>2000-08-22</dc:date>
    </rdf:Description>
  </rdf:RDF>

  <painting>
    <title>Memory of the Garden at Etten</title>
    <artist>Vincent Van Gogh</artist>
    <date>November, 1888</date>
    <description>
      Two women look to the left. A third works in her garden.
    </description>
  </painting>

  <painting>
    <title>The Swing</title>
    <artist>Pierre-Auguste Renoir</artist>
    <date>1876</date>
    <description>
      A young girl on a swing. Two men and a toddler watch.
    </description>
  </painting>

  <!-- Many more paintings... -->

</catalog>

A DTD for this document can include different content specifications for the dc:description and description elements. A stylesheet can attach different styles to dc:title and title. Software that sorts the catalog by date can pay attention to the date elements and ignore the dc:date elements.

In this example, the elements without prefixes, such as catalog, painting, description, artist, and title, are not in any namespace. Furthermore, unprefixed attributes (such as the about attribute of rdf:Description in the previous example) are never in any namespace. Being an attribute of an element in the http://www.w3.org/TR/REC-rdf-syntax# namespace is not sufficient to put the attribute in the http://www.w3.org/TR/REC-rdf-syntax# namespace. The only way an attribute belongs to a namespace is if it has a declared prefix, like xlink:type and xlink:href.

It is possible to redefine a prefix within a document so that in one element the prefix refers to one namespace URI, while in another element it refers to a different namespace URI. In this case, the closest ancestor element that declares the prefix takes precedence. However, in most cases redefining prefixes is a very bad idea that only leads to confusion and is not something you should actually do.

4.2.3. Namespace URIs

Many XML applications have customary prefixes. For example, SVG elements often use the prefix svg, and RDF elements often have the prefix rdf. However, these prefixes are simply conventions and can be changed based on necessity, convenience, or whim. Before a prefix can be used, it must be bound to a URI like http://www.w3.org/2000/svg or http://www.w3.org/1999/02/22-rdf-syntax-ns#. It is these URIs that are standardized, not the prefixes. The prefix can change as long as the URI stays the same. An RDF processor looks for the RDF URI, not any particular prefix. As long as nobody outside the w3.org domain uses namespace URIs in the w3.org domain, and as long as the W3C can keep a careful eye on what its people are using for namespaces, all conflicts can be avoided.

Namespace URIs do not necessarily point to any actual document or page. In fact, they don't have to use the http scheme. They might even use some other protocol like mailto in which URIs don't even point to documents. However, if you're defining your own namespace using an http URI, it would not be a bad idea to place some documentation for the specification at the namespace URI. The W3C got tired of receiving broken-link reports for the namespace URIs in their specifications, so they added some simple pages at their namespace URIs. For more formal purposes that offer some hope of automated resolution and other features, you can place a Resource Directory Description Language (RDDL) document at the namespace URI. This possibility will be discussed further in Chapter 14. You are by no means required to do this, though. Many namespace URIs lead to 404-Not Found errors when you actually plug them into a web browser. Namespace URIs are purely formal identifiers. They are not the addresses of a page, and they are not meant to be followed as links.

Parsers compare namespace URIs on a character-by-character basis. If the URIs differ in even a single normally insignificant place, then they define separate namespaces. For instance, http://www.w3.org/1999/02/22-rdf-syntax-ns#, http://WWW.W3.ORG/1999/02/22-rdf-syntax-ns#, http://www.w3.org/1999/02/22-rdf-syntax-ns/, and http://www.w3.org/1999/02/22-rdf-syntax-ns/index.rdf all point to the same page. However, only the first is the correct namespace name for the RDF. These four URLs identify four separate namespaces.

4.2.4. Setting a Default Namespace with the xmlns Attribute

You often know that all the content of a particular element will come from a particular XML application. For instance, inside an SVG svg element, you're only likely to find other SVG elements. You can indicate that an unprefixed element and all its unprefixed descendant elements belong to a particular namespace by attaching an xmlns attribute with no prefix to the top element. For example:

<svg xmlns="http://www.w3.org/2000/svg"
     width="12cm" height="10cm">
  <ellipse rx="110" ry="130" />
  <rect x="4cm" y="1cm" width="3cm" height="6cm" />
</svg>

Here, although no elements have any prefixes, the svg, ellipse, and rect elements are in the http://www.w3.org/2000/svg namespace.

The attributes are a different story. Default namespaces only apply to elements, not to attributes. Thus in the previous example the width, height, rx, ry, x, and y attributes are not in any namespace.

You can change the default namespace within a particular element by adding an xmlns attribute to the element. Example 4-4 is an XML document that initially sets the default namespace to http://www.w3.org/1999/xhtml for all the XHTML elements. This namespace declaration applies within most of the document. However, the svg element has an xmlns attribute that resets the default namespace to http://www.w3.org/2000/svg for itself and its content. The XLink information is included in attributes, however, so these must be placed in the XLink namespace using explicit prefixes.

Example 4-4. An XML document that uses default namespaces

<?xml version="1.0"?>
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:xlink="http://www.w3.org/1999/xlink">
  <head><title>Three Namespaces</title></head>
  <body>
    <h1 align="center">An Ellipse and a Rectangle</h1>
    <svg xmlns="http://www.w3.org/2000/svg"
         width="12cm" height="10cm">
      <ellipse rx="110" ry="130" />
      <rect x="4cm" y="1cm" width="3cm" height="6cm" />
    </svg>
    <p xlink:type="simple" xlink:href="ellipses.html">
      More about ellipses
    </p>
    <p xlink:type="simple" xlink:href="rectangles.html">
      More about rectangles
    </p>
    <hr/>
    <p>Last Modified May 13, 2000</p>
  </body>
</html>

The default namespace does not apply to any elements or attributes with prefixes. These still belong to whatever namespace to which their prefix is bound. However, an unprefixed child element of a prefixed element still belongs to the default namespace.

4.2.5. Attribute Declarations for xmlns

When namespaces are only being used to identify the elements and attributes from a particular XML application, and not to distinguish different elements with the same name, a DTD can attach a fixed xmlns attribute to the primary container elements for an application so that everything is placed in the right namespace without explicit xmlns attributes in the document. For example, this ATTLIST declaration fixes the default namespace of all svg elements as http://www.w3.org/2000/:

<!ATTLIST svg xmlns CDATA #FIXED "http://www.w3.org/2000/">

This allows you to omit xmlns attributes from all your svg elements.

A document does not need to be valid to take advantage of this. All that's required is that the parser read the DTD. All parsers will read the internal DTD subset and process any such ATTLIST declarations they find there. A few nonvalidating parsers may skip external DTD subsets, and thus get confused. Ideally, you should use a parser that can validate so that it will at least be able to read the external DTD subset, though you might use it with validation turned off.