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

BOOK: XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition
11.19Mb size Format: txt, pdf, ePub
ads

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.
BOOK: XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition
11.19Mb size Format: txt, pdf, ePub
ads

Other books

Final Empire by Blake Northcott
Deluge by Anne McCaffrey
Starfall by Michael Cadnum
War-N-Wit, Inc. - The Witch by Roughton, Gail
Poison Shy by Stacey Madden
Mercy by David L Lindsey
The Infinity Tattoo by Eliza McCullen