I said that the processor looks in the schema for an appropriate element declaration, but where does it find the schema? It knows the namespace of the element name at this stage, so if a schema for this target namespace has been imported using
(see page 368), then there is no problem. Otherwise, the specification leaves things rather open. It recognizes that some processors are likely to have some kind of catalog or repository that enables the schema for a given namespace to be found without difficulty, and it allows this to happen where the implementation supports it. You can also create an
xsi:schemaLocation
attribute node on the element being validated, to provide guidance on where a schema document might be found. In other cases, the implementation is allowed to report an error.
If neither the
type
nor
validation
attribute is present, then the system behaves as if the
validation
attribute were present and had the value given by the
default-validation
attribute of the containing
element. If no default is specified at that level, the effect is the same as
validation=“strip”
.
XSLT does not provide any way to request validation of an element against a local element or type definition in a schema. The way around this is to request validation only when you create an element for which there is a top-level definition in the schema. This will then implicitly validate the whole subtree contained by that element, including elements that have local definitions in the schema. Alternatively, many locally declared elements make use of a globally defined type, and you can then use the
type
attribute to validate against the type definition.
Usage and Examples
In most cases, elements in a result tree can be generated either using literal result elements in the stylesheet, or by copying a node from the source document using
.
The only situations where
is absolutely needed are therefore where the element name in the result document is not fixed and is not the same as an element in the source document.
Using
rather than a literal result element can also be useful where different namespaces are in use. It allows the namespace URI of the generated element to be specified explicitly, rather than being referenced via a prefix. This means the namespace does not have to be present in the stylesheet itself, thus giving greater control over exactly which elements the namespace declarations are attached to. With a literal result element, all in-scope namespaces from the stylesheet are copied to the result document unless you exclude them using
[xsl:]exclude-result-prefixes
; this does not happen for
.
Example: Converting Attributes to Child Elements
This example illustrates how
can be used to create element nodes whose names and content are taken from the names and values of attributes in the source document.
Source
The source document
book.xml
contains a single
element with several attributes:
author=“Michel Beaudouin-Lafon”
translator=“Jack Howlett”
publisher=“Chapman & Hall”
isbn=“0 412 55800 9”
date=“1994”/>
Stylesheet
The stylesheet
atts-to-elements.xsl
handles the book element by processing each of the attributes in turn (the expression
@*
selects all the attribute nodes). For each one, it outputs an element whose name is the same as the attribute name and whose content is the same as the attribute value.
The stylesheet is as follows:
xmlns:xsl=“http://www.w3.org/1999/XSL/Transform”
version=“2.0”
>
This selects all the attributes of the
element (using the expression
@*
), and for each one, it generates an element whose name is the same as the name of that attribute, and whose content is the value of that attribute.
Output
The XML output (on my system) is shown below. The stylesheet isn't guaranteed to produce exactly this output, because the order of attributes is undefined. This means that the
loop might process the attributes in any order, so the order of child elements in the output is also unpredictable. With Saxon, it actually depends on which XML parser you are using.
Michel Beaudouin-Lafon
1994
0 412 55800 9
Chapman & Hall
Object-oriented Languages
Jack Howlett
See Also
on page 254
on page 287
xsl:fallback
The
instruction is used to define processing that should occur if no implementation of its parent instruction is available.
Changes in 2.0
None.
Format
Position
is an instruction. It is generally used within a sequence constructor. However, some new XSLT 2.0 instructions (
,
) allow an
element as a child even though they do not contain a sequence constructor. This is to allow fallback behavior to be defined for use when these instructions are encountered by an XSLT 1.0 processor.
Attributes
None.
Content
A sequence constructor.
Effect
There are two circumstances where
can be useful:
- In a stylesheet that uses XSLT features defined in version 2.0, to indicate what should happen if the stylesheet is used with an XSLT 1.0 processor. For example, the XSLT 2.0 specification introduces the new instruction
. If you want to use the
instruction in a stylesheet, and also want to specify what an XSLT 1.0 processor that doesn't understand this instruction should do, you can define the required behavior using
. XSLT 1.0 was carefully designed with extensibility in mind, so every XSLT 1.0 processor should implement this fallback behavior correctly even though the new XSLT 2.0 instructions were not defined at the time the processor was written.
- In a stylesheet that uses extension elements provided by a vendor, by the user, or by a third party, to indicate what should happen if the stylesheet is used with an XSLT processor that does not support these extensions.
If the
instruction is encountered in a sequence constructor that the processor can evaluate normally, it is ignored, along with its contents.
An instruction (as distinct from a literal result element) is an element that occurs in a sequence constructor and is either:
- in the XSLT namespace, or
- in a namespace designated as an extension namespace by its inclusion in the
[xsl:]extension-element-prefixes
attribute of the element itself or a containing element. This attribute must be in the XSLT namespace if its parent element is
not
in the XSLT namespace, and vice versa.