W3C home > Mailing lists > Public > xsl-editors@w3.org > April to June 2001

RE: additions to XSLT

From: Arunprasad P. Marathe <amarathe@opentext.com>
Date: Mon, 18 Jun 2001 18:17:50 -0400 (EDT)
To: <mhkay@iclway.co.uk>, <xsl-editors@w3.org>
Cc: "Self" <amarathe@opentext.com>
Message-ID: <COELJNKNFDMBPGCAGCELAEIKCBAA.amarathe@opentext.com>

>> I think that it would be a good idea to extend XLST such that
>> template rules can be applied to intermediate trees that are produced
>> by other template rules in the same stylesheet. That is, template
>> rules don't necessarily have to refer to the (same) input tree.
>This facility is available in the published XSLT 1.1 working draft, through
>the ability to use a result tree fragment as the input to
>xsl:apply-templates. Although XSLT 1.1 is no longer being pursued, the
>functionality is automatically on the requirements list for XSLT 2.0.

I read in the XLST 1.1 working draft that the result tree fragment data
type has been removed from XLST 1.1.

I think that the ability to modify intermediate trees shall take XLST
away from the stylesheet-type of processing and bring it closer to a query
language-type of processing. I am sure you are aware that there is a
lot of overlap between the capabilities of XLST and XQuery, and XSLT
people argue (rightly, it seems to me) that an enhanced version of XSLT
could have served as a good starting point for an XML query language.
I think that it might still be possible to sell XLST+ as the XML
query language. The ability of process intermediate trees should
provide the XSLT compilers with opportunities for optimizations such
as logical rewrites---an important selling point of query languages.
For example, given a tree manipulation A(B(T)), an XSLT compiler
might be able to infer that it is equivalent to B(A(T)), and if the
equivalent form is more efficient to evaluate than the original one,
might choose to evaluate the second expression rather than the first.

>> Here is a second suggestion for a possible extension to XSLT. It
>> would be quite useful if a stylesheet can operate on more than one
>> input trees at a time. For example, in the tree manipulation that I
>> mentioned above, suppose that the operator A operates on two trees.
>> Then I should be able to write a stylesheet that implements the tree
>> expression A(B(C(A(T1,T2))),T3), where T1, T2, and T3 are trees.
>An XSLT 1.0 stylesheet can operate on multiple input documents either
>through the use of the document() function or through document-valued
>stylesheet parameters; I'm not sure what else you are looking for?
>There are also mentions in the published XSLT 2.0 requirements of the
>desirability of finding some way of associating different sets of template
>rules with different input documents within a single transformation. If you
>have any ideas as to how this might be done, your ideas will be welcome.

That capability would be quite useful. One way to do that might be
to assign separate namespace prefixes for different documents. Headers
of template rules can then refer to specific document/documents. A
template rule applies to all of the documents referred to in its
header. To <xsl:apply-templates>, an attribute that identifies
document(s) can be added, specifying the document(s) on which
recursive template rule applications happen.

On an unrelated note, supporting updates will be a nice addition to
XSLT. XQuery does not support updates, but I have read one proposal
(a paper in the recent SIGMOD 2001 conference) for adding them. It
seems to me that XSLT is well-suited to perform tree updates.


Arun Marathe                   PhD (Waterloo)
Open Text Corporation
185 Columbia Street West
Waterloo, ON N2L 5Z5, Canada
519-888-7111 x2649
Received on Tuesday, 19 June 2001 04:48:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:21 UTC