12.3. Namespaces

Namespaces identify the particular markup vocabulary from which element-type names and attribute names are derived. They are important because, for example, when using links, the idea of embedding linked content from other documents raises the problem of possible duplicate element-type names and attribute names with different meanings. For instance, if the element-type name “body” was used in two different ways, such as by an auto parts manual and by a physician's desktop reference, how should this be handled?

It is essential that element-type names and attribute names be distinguishable in the way that, for example, the particular meaning of element in chemical element is distinguishable from its meaning in markup element. Another way to think of the issue is in terms of surnames. For example, lots of folks are named John, and an inconvenience (especially for those named John) can arise from the somewhat unsavory uses of john but a surname (like Gardner or Jacobjingleheimerschmidt) disambiguates “a john” from “John Smith,” “John Doe,” or “the john.” Namespaces allow a unique identification of a name by providing a way for them to be differentiated.

12.3.1. Theory of a Namespace

A namespace is, well, a space for a name. Element-type names or an attribute names are qualified with a prefix, a sort of short name or alias for the namespace. Each namespace is declared prior to using its prefix, either in the same element in which it is used or in an ancestor element. The declaration of the namespace contains a URI that (hopefully) points to something that regulates that namespace.

Any XSLT element-type name is qualified with a namespace, and as such, it is called a QName. A QName is an element-type name preceded by a prefix, with a separating colon. In essence, if an element-type name has a colon (:), you can be sure it is a QName and, accordingly, indicates an element with a namespace. Element-type names without colons are not QNames, then, and can be referred to as no-colon names, or NCNames.

When declaring a namespace, you must specify what the prefix of the namespace will be, and the name of the namespace, which is usually a URI (Uniform Resource Identifier) giving at least in human terms information that identifies the namespace according to its lineage or pedigree. The URI could also point to a DTD or Schema for the declared namespace.

A namespace declaration is similar to a DOCTYPE declaration, only it is found in a different part of the XML document instance. It is not a child of the root; it is an attribute on an element. The examples in this chapter concern the declarations of XSLT namespaces, but those that might be found in XML documents will be similar. It is not the purpose of this chapter to provide a comprehensive guide to writing namespaces, but rather, to enable you to effectively recognize and use them with XSLT. Namespaces become very important for distinguishing extensions to XSLT that different XSLT processors implement, and as such are discussed further in Chapter 12.

12.3.2. Anatomy of a Namespace

A namespace must be declared before it can be used. Declaring a namespace such as xmlns:xsl="http://www.w3.org/1999/XSL/Transform" defines a prefix and the value of the namespace name, which is usually a URI pointing to the namespace owner. The prefix (xsl, in this example) follows the XML namespace declaration, xmlns. The XML namespace declaration is the reserved attribute name, xmlns (which happens to be the prefix for the xmlns namespace), followed by the : separator. Immediately following the separator is the prefix being defined, followed by an equal sign, which separates it from the address or URI of the namespace.

The address or URI of the namespace is only used to identify the namespace; whether it resolves to a location or a schema is irrelevant. It is only intended to be a unique value that can be used to differentiate elements from two separate sources that may happen to have the same name.

Figure 12-1 illustrates an example of a namespace declaration. Notice that there is what appears to be a Web address (or URI) for the name of the namespace. In fact, this particular namespace name is a specific Web address; if you type it into a browser, you'll get a Web page on the W3C Web site. This namespace URI is not actually controlling the content of the document in relation to any specification, but it serves as a placeholder for the future of such an engine. The Namespaces recommendation does not preclude that the URI be a specific address.

A namespace declaration, unless it is xml or xmlns, must be declared in the element it is used in or in an ancestor of that element. The xmlns namespace declaration attribute is therefore allowed in any XML element. To actually use a namespace in an element tag, the prefix (xsl, in this example) should appear before the element-type name, with a colon (:) between them:

<xsl:template match="body">

12.3.3. Default Namespace

In any XSLT stylesheet there is a default namespace that does not need to be declared. The XML namespace, for example, is implicitly declared (see Section 12.3.7) and can be used anywhere in the stylesheet (as seen using the xml:space attribute). The default namespace for an XSLT stylesheet can be changed by declaring a new namespace and removing its prefix from the declaration.

In Example 12-1, the XHTML^[2] namespace is declared and made the default namespace of the document by removing the prefix.

^[2] . For more on XHTML, see http://www.w3.org/TR/xhtml1/. However, be aware that there is now only one XHTML, but the example in the W3C specification for XSLT reflects a prior phase, since rescinded, in which XHTML had three possible namespaces.

Example 12-1. An LRE stylesheet declaring the XHTML namespace as the default namespace.

<html xsl:version="1.0"
             xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
             xmlns="http://www.w3.org/TR/XHTML">
      <head>
             <title>My document title.</title>
      </head>
      <body>
             <p>My document content.</p>
      </body>
</html>

12.3.4. Qualified Names (QNames) and No-Colon Names (NCNames)

Namespaces contain two rather esoteric parts: QNames and NCNames. An NCName is a no-colon name, or a name without a colon, while a QName is a name with a colon. Strangely enough, each part of a qualified name (the parts around the colon) is an NCName. So if iowa:season is a QName, iowa and season individually are both NCNames. However, they each have their own signification.

A QName has two parts: an optional prefix and a local part. The prefix is associated with a namespace, which is expanded into a URI using the namespace declared for that prefix. The local part is the name of the object in the document instance. The prefix and the local part are separated by a colon. With or without a prefix, both element-type names and attribute names are QNames.

The name of an XSLT object is the combination of the expanded prefix (if used) and the local part of the QName, and is referred to as the expanded name. If a QName does not have a prefix, the local part is considered the name of the XSLT object. The default namespace defined in the stylesheet is not used as a prefix for QNames that do not have prefixes.This discussion on names and prefixes may be quite confusing, but suffice it to say that the names of most objects in XSLT are governed by the XML naming rules for names:

Combining characters and extenders are special characters derived from the Unicode character database (listed in Appendix B of the XML specification).

In addition to element-type names and attribute names, internal XSLT objects must be named using QNames. Internal XSLT objects are defined by the XSLT specification as one of six types: specifically, a named template, a mode, an attribute set, a key, a decimal-format, and a variable or parameter.

12.3.5. The XSL Namespace

The document element (<xsl:stylesheet> or <xsl:transform>) of an XSLT stylesheet contains a namespace declaration that defines the document as an XSLT stylesheet. This namespace always uses the same format. Once the namespace has been declared, XSLT elements are recognized by the processor using the “xsl” prefix in the element-type name. Notice from the examples used previously that each instruction and top-level XSLT element contains the “xsl” prefix followed by a colon, as in <xsl:template>. If these elements did not have the prefix, the processor would assume them to be LREs and this would either invalidate the stylesheet, or send the LREs to the output.

The declaration of the XSL namespace for any XSLT stylesheet occurs as an attribute in the document element. The prefix for the XSLT namespace is xsl, reflecting the relationship of XSLT to XSL (XSLT is part of XSL). The declaration is made as follows:

<xsl:stylesheet
       xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      version="1.0">

Notice in this case that the namespace is actually being declared in an attribute on an element that is already using the prefix. Although it may appear that the prefix is being used before it is declared, this is a perfectly valid way to declare and use a namespace.

The namespace declaration is preceded by the reserved namespace declaration attribute name xmlns. XSLT processors recognize the xmlns attribute as the beginning of a declaration for a namespace. The following attribute model definition shows the appropriate structure of the xmlns attribute.

ATTRIBUTE: xmlns:xsl CDATA #FIXED
VALUE = "http://www.w3.org/1999/XSL/Transform"

The prefix xmlns is used only for namespace bindings and is not itself bound to any namespace name. (W3C REC-xml-names-19990114, Namespaces in XML, Section 4)

Following the xmlns namespace declaration, the prefix that will be used for the given namespace is given, followed by an equals sign and the value of the attribute, which is a URI.

12.3.6. Using Other Namespaces

XSLT, as an “extensible” language, can be extended to include elements other than those in the base set specified by the W3C. For instance, James Clark's XT has several functions that were added beyond the basic set specified in version 1.0 of the XSLT specification. Because these additional functions are commonly used, we might want to declare a namespace for XT extensions in the document element as follows:

<xsl:stylesheet
         xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
         version="1.0"
         xmlns:xt="http://www.jclark.com/xt">
					

Thereafter, any extension elements used in the stylesheet would have the xt namespace prefix, while the normal XSLT elements would still have the xsl namespace prefix. Because the XT namespace is declared on the document element, all elements in the document can use the declared namespace if required.

12.3.7. The Default XML Namespace

XSLT stylesheets, being part of XML, have a default XML namespace that does not need to be declared.

There are two XML-specific attributes that use the XML namespace and can be used in XSLT: xml:lang and xml:space. The xml:space attribute is discussed in detail in Section Section 2.1.3.1 in connection with the document element. The xml:lang is not treated specially by XSLT since there is an XSLT-specific attribute (lang) that covers the same functionality. The XSLT lang attribute is discussed in Chapter 9.

12.3.8. Declaring the Extension Namespace and Its Applicability

As elsewhere in this book, the easiest way to explain how an extension element namespace applies is to look at the logical structure of the XSLT stylesheet as an XML document instance. When an extension element namespace is declared in the document element, that namespace declaration applies to the entire stylesheet. It does not, however, apply to imported or included stylesheets. Thus, if you wanted it to apply James Clark's XT to an entire XSLT stylesheet, you could declare the namespace for it, as shown below.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                 version="1.0"
                 xmlns:xt=http://www.jclark.com/xt>

If you were using only one particular extension element in the context of only one template rule, you might declare the namespace only on that element, as shown below using the Saxon namespace.

<xsl:template match="something" saxon:trace="yes"
      xmlns:saxon="http://icl.com/saxon">

If your XSLT stylesheet uses <xsl:fallback> with element-available() and function-available() to provide contingencies for unsupported elements or functions, you might more likely use the extension-element-prefixes attribute in the document element to provide a list of the possible namespaces, so that all possible processors are covered. This makes an XSLT stylesheet truly portable.

It is important to remember that conforming XSLT processors are not required to signal an error if an unsupported extension is encountered. Therefore, as you are fine-tuning or debugging a stylesheet, be sure and check that any extensions you are using are supported before assuming it's a deficiency in your stylesheet composition skills! At the same time, because some XSLT processors do not support the entire W3C specification, but may also have their own extension functions and/or elements, it can be confusing to trace the source of incorrect output. Comparing your chosen components to those supported by your particular processor is the first step in resolving an issue.

12.3.9. Processor Extensions, Java Additions, and Future W3C XSLT Specifications

In spite of the title of this section, we are not forecasting the future of XSLT. However, there is a crossover between the wish list for future XSLT specifications both publicly discussed and formally specified in the XSLT specification and the actual extensions provided by most mainstream XSLT processors.

The specification lists some 22 targeted goals as possible future additions to the current XSLT W3C specification. Among them are items such as IDREF functionality, which could serve, for instance, as a complement to the id() function. Other items are DTD and/or schema support, entity reference support, conditional expressions, case-insensitive comparisons, increased access to RTFs, and more.

However, the extensibility of XSLT has made it possible that “the future is now” on some wish list items, depending on what processor you choose. One of the most frequently requested and widely implemented extensions to XSLT is the ability for a single XSLT stylesheet to create several different output files. For instance, Xalan implements this as <xalan:write>, Saxon as <saxon:output>, and XT as <xt:document> extension instruction elements. This raises the issue of portability because the same functionality is available from each XSLT processor, but in different syntax. Thus, a portable XSLT stylesheet would need to use <xsl:fallback> to support the various processors on which it might be run to insure comparable results. These types of shared extensions, as well as the unique offerings with specific XSLT implementations, are discussed individually with the respective processors in which they are implemented.

Another item on the wish list is a common Java binding mechanism for external functions written in Java. Currently, four of the processors we discuss have very similar approaches to this: Xalan (with a few variations), Saxon, XT, and Oracle. The details of each are best explained in the product documentation that accompanies them. Additional information can be obtained through the respective Web sites for each XSLT processor.

12.3.10. Conforming XSLT Processors and the OASIS XSLT Conformance Committee

Throughout this book, we frequently use the phrase “conforming XSLT processor,” or “processor that conforms to the W3C specification for XSLT.” Just what does conforming mean, and who decides whether the processor conforms?

Until very recently, there has not been a specific way to assign a label of “conforming” to any XSLT processor that had any industry acceptance. However, one of the ongoing efforts of the Organization for the Advancement of Structured Information Standards, OASIS, has been the chartering of conformance committees and establishment of conformance testing parameters.

These conformance committees are not evaluative bodies in the sense that the committee members pass judgment on one software implementation or another. Quite the contrary, the committees are charged with the task of detailed research into the full implications of what a W3C specification means, both in its prescribed and proscribed behavioral descriptions for any software implementation. From this research is derived a set of conformance tests and prescriptions for how they are to be implemented, and their results evaluated. Industry implementations may then access these tests and apply them to their own software, or to the software they are evaluating, to determine levels of conformance and desirability. It is not a “speed test” or memory footprint test as much as a finely tuned filter for finding precise levels of granularity in subtle nuances of how every implication of the specification is or is not met by a given software implementation.

Currently, G. Ken Holman of Crane Softwrights Ltd., a leading developer who uses XSLT and the author of a comprehensive, regularly updated resource on XSLT, is the chair of the XSLT/XPath Conformance Technical Committee. Representatives from the National Institute for Standards in Technology (NIST) a branch of the U.S. government in addition to established experts in markup technology such as Mulberry Technologies, which, among other things, is home to the XSL-list email list (http://www.mulberrytech.com/) and representatives from industry, such as IBM and Sun Microsystems, fill the seats on the committee. These are collaborative efforts of voluntary service that serve the wider needs of the XML community. For instance, a rich set of thousands of detailed XSLT tests was contributed through David Marston, the IBM/Lotus representative, while many tests are being received from other sources such as Sun and Microsoft, among others.

The test suite, which will be available at http://www.oasis-open.org/, allows users and corporations to access an independent, nonprofit-generated set of tests for evaluating XSLT software under consideration for use in whatever XML deployment they are designing. Similarly, programmers of XSLT processors have a ready benchmark by which to progressively evaluate the robustness of their implementations. OASIS will ultimately address the gamut of XML-related technologies and provide a valuable resource to the information industry. You are encouraged to utilize the committee's work in evaluating software. It is a useful learning exercise as well to run these tests, as they cover the specification in greater detail than does any single publication on XSLT or XPath.