xsl:sequence element is used to construct arbitrary sequences.
It may select any sequence of nodes and/or atomic values, and essentially adds these to the result
sequence. The input may be specified either by a
select attribute, or by the instructions
contained in the
xsl:sequence instruction, or both (the
is processed first). Nodes and atomic values are included in the result sequence directly. Unlike
xsl:copy-of, no copy is made.
as attribute may be used to define the required type of the sequence. The actual
value is converted to the required type if necessary, using the conversions that are permitted on
function calls. (Specifically, atomization of nodes, casting of untyped atomic values, and numeric
promotion.) If the type cannot be converted, a run-time error occurs.
There are two main usage scenarios. The first is copying atomic values into a tree. For example:
<xsl:sequence select="1 to 5"/>
<xsl:sequence select="6 to 10"/>
which produces the output
<e>1 2 3 4 5<br/>6 7 8 9 10</e>.
The second, more important, is constructing a sequence-valued variable. A variable
is sequence-valued if the variable binding element (e.g.
has non-empty content, an
as attribute, and no
<xsl:variable name="seq" as="xs:integer *">
<xsl:for-each select="1 to 5">>
<xsl:sequence select=". * ."/>
This produces the sequence (1, 4, 9, 16, 25) as the value of the variable.
xsl:sequence instruction may be used to produce any sequence of nodes and/or
If nodes are constructed within a sequence-valued variable, they will be parentless. For
example, the following code creates a variable whose value is a sequence of three parentless
<xsl:variable name="seq" as="attribute() *">
It is quite legitimate to have two attributes in the sequence with the same name; there is
no conflict until an attempt is made to add them both to the same element. The attributes can
be added to an element by using
<xsl:copy-of select="$seq"/> within an
xsl:element instruction or within a literal result element. At this stage the usual
rule applies: if there are duplicate attributes, the last one wins.
From release 8.1 Saxon no longer allows an
xsl:sequence element to have any
child instructions, other than optional
xsl:fallback instructions. This is a change
to the specification made after the November 2003 draft was published, in response to last-call
At present it is probably more efficient in Saxon to use XPath facilities (
expressions, etc) to construct sequences, rather than doing it at the XSLT level.