Resolution of XSLT issue 99: Constructing Sequences in XSLT

This note responds to an issue originally raised on 11 Jan 2002 by Jeni
Tennison, which is archived at:

http://lists.w3.org/Archives/Public/xsl-editors/2002JanMar/0050.html

The XSL WG has considered the proposal on a number of occasions, and we have
finally decided not to take this route. The reasons are as follows:


The essence of the proposal is that it moves some of the functionality which
we currently provide in XPath to the XSLT level. In particular, it provides
XSLT instructions to construct sequences (of atomic values and nodes). 

The proposal has advantages and disadvantages.

On the plus side, it cuts out the duplication of control structures between
XSLT and XPath. At present, XSLT and XPath each have their own mechanisms
for iteration, conditional evaluation, and subroutine call. The proposal
requires all iteration and conditional evaluation to happen at the XSLT
level, while continuing to allow function callbacks from XPath to XSLT. The
effect is to reduce the size of the XPath language without a corresponding
increase in the size of XSLT.

On the minus side, the boundary between XSLT and XPath becomes less
clear-cut, and harder to explain. At present, XSLT instructions are
concerned either with creating nodes and constructing trees, or with
controlling the execution of other instructions (iteration, conditionals,
calls). XSLT instructions at present can only return newly constructed
nodes; XPath expressions never do so (except by making a function call to
XSLT). This has the merit that the stylesheet tree always acts as a template
for the construction of the result tree, which is a model that users find
easy to understand.

Under the proposal, it would not always be obvious when XSLT instructions
are building a tree and when they are building a sequence. For example,
consider:

<xsl:template name="x">
  <xsl:text>[</xsl:text>
  <xsl:value-of select="$param"/>
  <xsl:text>]</xsl:text>
</xsl:template>

If this is called while constructing a tree, it returns a single text node.
If it could also be called while constructing a sequence, it would return a
sequence of three text nodes. Users might easily change the implementation
of the template (for example, to use concat()), without realising the
consequences for some callers.

There are arguments in favour of keeping XPath as small as possible (and
therefore putting functionality at the XSLT level wherever there is a
choice), but there are also arguments the other way:

(a) There are advantages both to implementors and to users in maximising the
common subset that XSLT shares with XQuery, and this argument leads to such
shared functionality sitting in XPath. 

(b) Functionality available in XPath (such as conditional expressions) is
usable in contexts such as key definitions and sort keys, where otherwise a
call-back from XPath to XSLT would be needed. 

(c) Functionality implemented at the XPath level is probably easier to
optimize, because within the context of an XPath expression, there are no
side-effects, whereas XSLT instructions have the side-effect of writing
nodes to the result tree.

(d) Functionality implemented at the XPath level is available in standalone
XPath environments, for example XPath used within the context of XPointer or
DOM. Since the XPath data model relies critically on sequences, some
mechanism for constructing sequences is needed that is not dependent on
XSLT.

Finally, there are pragmatic considerations. Although it would almost
certainly be possible to design a language along the lines of Jeni
Tennison's proposal that met all the XSLT/XPath 2.0 requirements, it would
require a lot of rework and a lot of negotiation between the XSL and XQuery
working groups. If the current language were badly broken, we would be
justified in tackling this rework. But the current language works, and we
want to get it finished. In fact, if we did embark on making the changes
required by this proposal, there is a serious prospect that we would end up
with a language in which we had added sequence construction to XSLT but
failed to remove anything from XPath. We would thus have increased
duplication between the languages instead of reducing it.

Michael Kay
on behalf of XSL WG

(Welcome to the group, Jeni!)

Received on Friday, 27 September 2002 11:34:49 UTC