Read XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition Online
Authors: Michael Kay
Note the empty template rule that matches the
//title
, this could accidentally match a
An embedded stylesheet module will generally be used as the principal stylesheet module. The standard doesn't explicitly say whether or not an embedded stylesheet can be included or imported into another. In practice, the details of what is supported are likely to vary from one product to another; few of the current products have much to say about embedded stylesheets in their documentation.
If namespace declarations occur outside the embedded stylesheet, they will still be in scope within the embedded stylesheet, which may result in extra namespace nodes being copied into the result tree. You can suppress such namespaces, using the
exclude-result-prefixes
attribute on the
xmlns:prefix = “”
. (With XML 1.0, the only namespace that can be undeclared is the default namespace.)
Declarations
All elements that are immediate children of the
top-level elements
. The top-level elements that are defined in the XSLT specification, and whose names are in the XSLT namespace, are called
declarations
. Those that are not defined in the XSLT specification are called user-defined data elements, and I will consider these in two categories: elements defined by the vendor of the XSLT processor and elements defined by the stylesheet author.
It is not permitted to have text nodes as immediate children of the
Top-level elements can appear in any order in the stylesheet, except that if there are any
Let's now examine the three categories of elements that may appear as children of
XSLT-Defined Declarations
An XSLT-defined declaration must be one of the following:
No other XSLT element (that is, no other element with the namespace URI
http://www.w3.org/1999/XSL/Transform
) may be used as a child of an
The
The following table gives a quick introduction to the purpose of each of these declarations.
Declaration | Effect |
Defines a named set of attribute nodes that can be added to any element in the result tree | |
Defines how individual characters in the result tree are to be output by the serializer | |
Defines a display format for numbers, used by the format-number() function described in Chapter 13 | |
Defines a stylesheet function that can be invoked from any XPath expression | |
Incorporates declarations from another stylesheet module, with lower precedence than the declarations in the importing module | |
Incorporates definitions from an XML Schema | |
Incorporates declarations from another stylesheet module, with the same precedence as the declarations in the including module | |
Defines a key that may be referenced using the key() function (described in Chapter 13) to give fast access to elements if their key values are known | |
Defines a translation from namespaces used in the stylesheet to namespaces used in the result tree | |
Defines how a result tree should be serialized | |
Defines a stylesheet parameter, a value that can be set from outside the stylesheet and accessed from anywhere within it | |
Defines a list of elements that contain whitespace text nodes that need to be retained | |
Defines a list of elements that contain whitespace text nodes that must be removed | |
Defines a template that can be invoked either when specific nodes are matched, or explicitly by name | |
Defines a global variable whose value can be accessed from anywhere in the stylesheet |
The meaning of each of these elements is explained in full detail in Chapter 6.
Implementor-Defined Declarations
An implementor-defined declaration must belong to a namespace with a non-null URI, different from the XSLT namespace. This will generally be a namespace defined by the vendor: for example with the Saxon product, the relevant namespace URI is
http://saxon.sf.net/
. The meaning of elements in this category is entirely at the discretion of the vendor, though the specification states a rule that such elements must not be used to change the meaning of any standard XSLT constructs,
except to the extent that the behavior is implementation defined
. This is a very important caveat, because there are a great many things in XSLT that are implementation defined, and this clause allows vendors to use top-level elements to give the user control over the choices that are exercised. For example, they might be used to control the following:
Note that these top-level elements are not technically extension instructions, so their namespace does not have to be declared in the
extension-element-prefixes
attribute for them to be effective.
Several vendors supply top-level elements that allow you to define extension functions that can be invoked from XPath expressions in the stylesheet (for example, Microsoft has an element called
If the processor doesn't recognize the namespace used for an implementor-defined declaration, it simply ignores it. This means you can safely mix different vendors' extensions in the same stylesheet.
User-Defined Top-Level Elements
A
user-defined top-level element
must also belong to a namespace with a non-null URI, different from the XSLT namespace, and preferably different from the namespace URI used by any vendor. These elements are ignored by the XSLT processor.
With XSLT 1.0, user-defined top-level elements were useful as a place to put lookup data, error messages, and the like. It is possible to reference these elements from within the stylesheet, by treating the stylesheet as an additional source document, and loading it using the
document()
function, which is described in Chapter 13. If the first argument to this function is an empty string, it is interpreted as a reference to the stylesheet module in which the
document()
function appears.
So, for example, if the stylesheet contains a user-defined top-level element as follows: