This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Possible new key() function
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: [xsl] Re: Possible new key() function
- From: "Dave Gomboc" <dave at cs dot ualberta dot ca>
- Date: Tue, 9 Jan 2001 11:13:23 -0700
- References: <200101091324.IAA24445@biglist.com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
> Date: Tue, 9 Jan 2001 10:14:30 -0000
> From: Kay Michael <Michael.Kay@icl.com>
> Subject: RE: Possible new key() function (Was: Re: [xsl] Finding the
maxim un number of nodes)
>
> > > In this case xsl:key will know in advance about all possible
> > > operators and could build the indexes in an optimal way in order
to
> > > guarantee most efficient key() performance.
>
> The more I listen to this discussion, the more convinced I am that SQL
got
> it right and XSLT got it wrong: keys should be used implicitly, behind
the
> scenes, when the optimizer decides and not when the user decides.
Rather
> than having new variants on the key() function, we should do away with
the
> function entirely.
>
> Mike Kay
+1. IIRC, your Saxon is already implicitly building keys in some cases,
and XSLT is still a relatively (e.g. to SQL) immature technology.
Perhaps it's even early enough that W3C would change course on this?
Dave Gomboc
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list