Subject: RE: key(). ( Re: Saxon VS XT ) From: Kay Michael <Michael.Kay@xxxxxxx> Date: Mon, 7 Aug 2000 10:34:28 +0100 |
> Funny how this is the similar to what you are talking > about: by analyzing the XSLT a XSLT engine should be > able to decide what hash tables/indexes to build for a > fast execution of the transformation. I'm inclined to agree. xsl:key and the key() function seems to hark back to pre-relational days where access paths were all defined explicitly by the programmer. SQL allows you to explicitly create an index (using CREATE INDEX) but it doesn't allow the query to be written differently depending on whether there is an index or not, it relies on the optimiser to detect where indexes will be useful to the query. That's no excuse for not implementing the facility now that it's been specified, though! But if I ever have time, it would be nice to experiment with automatic creation and use of keys based on the actual XSL. An obvious and trivial example is to index elements by name whenever you see "//X" written somewhere in the stylesheet. Mike Kay XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: key(). ( Re: Saxon VS XT ), Ben Robb | Thread | RE: key(). ( Re: Saxon VS XT ), Paulo Gaspar |
RE: More arbitrary sorting, Kay Michael | Date | Re: Urgent !!! '&' being replaced , Mahesh Nanavate |
Month |