- 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>
>> 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 --------------------------------------------- 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