- From: Kay, Michael <Michael.Kay@softwareag.com>
- Date: Fri, 27 Sep 2002 17:34:45 +0200
- To: public-qt-comments@w3.org
- Cc: jeni@jenitennison.com, w3c-xsl-wg@w3.org
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