RE: key(). ( Re: Saxon VS XT )

["Paulo Gaspar" <paulo dot gaspar at krankikom dot de>]

Still curious on the other thing Michael:

As I referred, I am playing with that idea of using indexing in 
order to transform a very long XML source stream (even using a 
local disk temporary storage).

The theory sounds nice to me... but I never built a XSLT engine.

Does it sound like something that might be done or is it just 
nonsense?


Thanks,
Paulo


> -----Original Message-----
> From: owner-xsl-list@mulberrytech.com
> [mailto:owner-xsl-list@mulberrytech.com]On Behalf Of Kay Michael
> Sent: Monday, August 07, 2000 11:34
> To: 'xsl-list@mulberrytech.com'
> Subject: RE: key(). ( Re: Saxon VS XT )
> 
> 
> > 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
> 


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list