RE: how to estimate speed of a transformation

> While I think that key() is a low-level hack which stands out 
> of the rest of the design, it is definitely useful for many 
> applications (it is, however. easy to imagine optimization 
> for this particular case and eliminate xsl:key/key at all - 
> 'select' that compares a value for equality can build a hash 
> table upon the first invocation if there are other  'select' 
> which contain the same expression with a different value).

There was a fair bit of research work done in the 1970s on automating
the decision on which fields in a database to index, and by and large,
it wasn't very successful. At any rate, most database products today
still demand that you make these decisions manually.

For XSLT it's even harder, because you don't generally have any learning
time: the tree is built once and used once in most situations. Building
an index the first time that an expression is used that could use it
could be horribly expensive, because it might never be used again. One
could make some better guesses based on static analysis of the
stylesheet, perhaps combined with some volumetric analysis of the tree
as it is read, but it's still an area where humans can do better.

What should be feasible in principle is keeping xsl:key as the hint that
you want an index, but losing key() as specific syntax for using the
index. It should be possible to make use of the index automatically -
this is where SQL systems have developed a lot of optimization
techniques.
> 
> Why don't you think it (delayed construction of the hash 
> table) should not be relied upon 
> if all usable implementations do it, and an implementation 
> that does not do it is hardly usable for the very kind of 
> applications 'key' is designed for?
> 

Implementors are permitted to produce lousy implementations of any
feature in the spec. No spec can prevent that. Why is this feature any
different from others?

Michael Kay


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