XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (198 page)

The

element describes the mapping in terms of prefixes, but it is primarily the namespace URI of the elements and attributes that it affects, rather than their prefixes. However, the way that the rules are drawn up means that in most cases (certainly when the same namespaces are in scope for the

instruction and for the literal result element itself) the element in the result document will end up using the prefix defined in the
result-prefix
attribute (or no prefix, if this is specified as
#default
).

The substitution of one namespace URI for another affects the names of literal result elements themselves, and the names of all attributes of literal result elements. It also affects the URIs of namespace nodes copied into the result tree from a literal result element. It does not affect elements created using

, attributes created using

, or nodes copied using

.

There was often confusion among XSLT 1.0 users about what namespaces they should expect to find declared in the result document, and different processors handled this differently. In XSLT 2.0, the rules have been clarified. Namespaces find their way from the stylesheet into the result document whenever a literal result element is evaluated. XSLT 2.0 states clearly that if the literal result element has a namespace node with the URI associated with the
stylesheet-prefix
of an

instruction, it is not copied to the result tree as it normally would be; if it has a namespace node with the URI associated with the
result-prefix
of an

instruction, then this namespace node is copied, even if the URI is one such as
http://www.w3.org/1999/XSL/Transform
that would normally not be copied. These rules are designed to produce the result that most users would expect: a literal result element

will produce an element in the result tree that will normally be serialized as

; the
xsl
namespace will be declared in the result document, and the
out
namespace will not be declared.

If there are several

elements that specify the same
stylesheet-prefix
, the one with highest import precedence is used; a compile-time error is reported if there is more than one at the highest import precedence.

The aliasing of namespace URIs applies at the point when a literal result element in the stylesheet is evaluated to create an element node in a result sequence. It applies whether or not this element is written to a final result tree. This means that if you examine a temporary document into which literal result elements have been copied, the corresponding elements and attributes will use the namespace URI associated with the result prefix, not the stylesheet prefix.

Aliasing of namespaces happens before the namespace fixup process described under

on page 310.

Usage and Examples

The main justification for this facility is to enable stylesheets to be written that generate stylesheets as output. This is not as improbable a scenario as it sounds; there are many possible reasons for using such applications (sometimes referred to as
meta-stylesheets
), including the following:

• There are many proprietary template languages currently in use. Translating these templates into XSLT stylesheets creates an attractive migration route, and there is no reason why these translators should not be written in XSLT.
  
• There may be a continuing need for a template language, which is less complex and powerful than XSLT, for use by nonprogrammers. Again, these simple templates can easily be translated into XSLT stylesheets.
  
• There are some parts of an XSLT stylesheet that cannot easily be parameterized. For example, it is not possible to construct an XPath expression programmatically and then execute it (XSLT is not a reflexive language). The requirement to do this arises when visual tools are developed to define queries and reports interactively. One way of implementing such tools is to construct a customized stylesheet from a generic stylesheet, and again this is a transformation that can be assisted by using XSLT.
  
• You might have developed a large number of stylesheets that all have some common characteristic; for example, they might all generate HTML that uses the
  
  tag. As the
  
  tag is deprecated, you now want to modify these stylesheets to use
  
  
  . Why not write an XSLT transformation to convert them?
  
• There are tools that make it possible to generate XSLT stylesheets from a schema (see for example Schematron at
  http://xml.ascc.net/resource/schematron/
  ). Because both the schema and the stylesheet are XML documents, this is an XML-to-XML transformation, so it should be possible to write it in XSLT.
  

In fact, having gone through all the trouble of defining XSLT stylesheets as well-formed XML documents, it would be very surprising if it were impossible to manipulate them using XSLT itself.

However, it is possible to create stylesheets as output without recourse to

: just avoid using literal result elements, and use instructions such as

instead. I personally find this approach less confusing, although the stylesheet ends up being more verbose.

There may be other situations where

is useful. The XSLT specification mentions one, the need to avoid using namespace URIs that have recognized security implications in the area of digital signatures. Another might arise if stylesheets and other documents are held in a configuration management system; there might be a need to ensure that namespaces recognized by the configuration management system, for example to describe the authorship and change history of a document, are not used directly in the stylesheet.

Aliasing the XML Namespace

It's possible to define an alias for the
xml
namespace. For example, the following stylesheet (
xml-space.xsl
):

produces the following output:

This is useful because it gets an
xml:space=“preserve”
attribute into the result document without affecting the way that whitespace is handled in the stylesheet.