This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: Possible new key() function (Was: Re: Finding the maxim un number of nodes)
- To: "'xsl-list at lists dot mulberrytech dot com'" <xsl-list at lists dot mulberrytech dot com>, Kay Michael <Michael dot Kay at icl dot com>
- Subject: RE: Possible new key() function (Was: Re: [xsl] Finding the maxim un number of nodes)
- From: Kay Michael <Michael dot Kay at icl dot com>
- Date: Wed, 10 Jan 2001 10:14:39 -0000
- Reply-To: xsl-list at lists dot mulberrytech dot com
> In case existing XSLT processors already did such optimisations by
> default then nobody would have cared...
I think XSLT optimisation technology is still very immature, certainly in
comparison with SQL which has developed over 30 years now.
>
> 1. Is this automatic optimisation possible at all?
Yes, I think there is enormous scope for optimisations. As with SQL, the
main problem is ensuring that the cost of doing the optimisation doesn't
exceed the savings achieved; this makes it hard to do optimisations that
depend on the content of the source document. But that still leaves a lot of
scope.
>
> 2. In my opinion it is too late and probably it would be harmful to
> remove the key() function from XSLT. A whole "culture" has
> been already established using the key() function
>
Yes, we already have a legacy problem with this new technology. One of the
things that is imprinted on my mind from my undergraduate days is David
Wheeler's dictum: compatibility means deliberately repeating other people's
mistakes.
Mike Kay
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list