This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: key(). ( Re: Saxon VS XT )
- To: "'xsl-list at mulberrytech dot com'" <xsl-list at mulberrytech dot com>
- Subject: RE: key(). ( Re: Saxon VS XT )
- From: Kay Michael <Michael dot Kay at icl dot com>
- Date: Mon, 7 Aug 2000 10:34:28 +0100
- Reply-To: xsl-list at mulberrytech dot com
> 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