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

The change to make this legal in XSLT 2.0 involves no new instructions, so it isn't possible to write an

instruction to define what an XSLT 1.0 processor should do with this code: There's no suitable instruction to contain it. The only way of defining fallback behavior in this case is to test the XSLT version using the
system-property()
function. The following stylesheet (
lookup.xsl
) will work with both XSLT 1.0 and XSLT 2.0. This accesses a lookup table defined as a global variable in the stylesheet. With a 2.0 processor, it accesses the variable containing the lookup table directly. With a 1.0 processor, it does it by using the
document(”)
construct to read the stylesheet as a secondary input document.

The code prevents an XSLT 2.0 processor executing the 1.0 code by means of the
use-when
attribute, which a 1.0 processor will ignore in forward-compatibility mode. The same technique can't be used to prevent a 1.0 processor executing the 2.0 code, so this uses a runtime check instead.

In theory, an XSLT 1.0 processor could legitimately reject the above stylesheet at compile time, regardless of whether it specifies
version=“1.0”
or
version=“2.0”
, but fortunately the XSLT 1.0 processors that I've tried accept it without quibble.

In this example I used the standard
document()
function to provide fallback processing that works with all XSLT 1.0 processors. In more complex examples, the fallback processing might need to use vendor extensions such as Microsoft's
msxml:node-set()
extension function. In this situation different fallback mechanisms would be needed for different processors.

See Also

Extensibility
in Chapter 3, page 134

Literal Result Elements
in Chapter 3, page 112

element-available()
function in Chapter 7, page 764

system-property()
function in Chapter 7, page 890

use-when
attribute described under

, page 478

xsl:for-each

The

instruction selects a sequence of items using an XPath expression and performs the same processing for each item in the sequence.

Changes in 2.0

There are no changes to the syntax of this instruction in XSLT 2.0. However, the ability to process sequences of atomic values as well as sequences of nodes greatly increases its power.

Format

Position

is an instruction, which is always used within a sequence constructor.

Attributes

Content

Zero or more

elements, followed by a sequence constructor.

Effect

The effect of the

instruction is to evaluate the sequence constructor that it contains once for each item in the selected sequence of items. The following sections describe how this is done.

The select Attribute

The
select
attribute is mandatory. The expression defines the items that will be processed. This may be any XPath expression, because every XPath expression returns a sequence. It is quite legitimate, and occasionally useful, to select a single item or an empty sequence.

The expression will often be a path expression, which may select nodes relative to the context node (the node currently being processed). Alternatively, it may make an absolute selection from the root node, or it may simply select the nodes by reference to a variable initialized earlier. By referencing a tree-valued variable, or by using the
document()
function (described in Chapter 13, page 754), it may also select the root node of another XML document.

The

instruction can also be used to process a sequence of atomic values. The following example causes five empty


elements to be output:

The sequence constructor contained within the

element is evaluated once for each item in the
select
sequence. Within this sequence constructor, the context item is the item being processed (one of the selected items); the
position()
function gives the position of that item in order of processing (the first item processed has
position()=1
, and so on), and the
last()
function gives the number of items being processed.

Although there is a defined order of processing, each item in the sequence is processed independently of the others; there is no way that the processing of one item can influence the way other items are processed. This also means that you can't break out of the loop. Think of the items as being processed in parallel. If you need the processing of an item to depend in some way on previous items, there are two ways you can achieve this: you can look at earlier items in the input sequence (for example by using the preceding-sibling axis), or you can abandon use of

, and use recursion instead.

A common mistake is to forget that

changes the context item. For example, the following code will probably produce no output:

Why? Because within the

element, the context node is a

element, so the

instruction is trying to display another

element that is a child of the first one. What the author probably intended was:

Sorting

If there are no child

instructions, the selected items are processed in the order of the sequence produced by evaluating the
select
expression. If the
select
expression is a path expression, the nodes will be in
document order
. In the normal case where the nodes all come from the same input document, this means they will be processed in the order they are encountered in the original source document: for example, an element node is processed before its children. Attribute nodes belonging to the same element, however, may be processed in any order, because the order of attributes in XML is not considered significant. If there are nodes from several different documents in the sequence, which can happen when you use the
doc()
or
document()
functions (described in Chapter 13), the relative order of nodes from different documents is not defined, though it is consistent if the same set of nodes is processed more than once.