Re: how to estimate speed of a transformation

> 
> >  keys must be recomputed on any new node-set(),
> hopefully though the system only computes the key on a document that is
> actually used as the context for the key() function (otherwise keys
> would get very coslky indeed in some setups)
> 
> typically for example I have a very big source file and some smaller
> "mapping" files that I use as lookup tables, I use xsl:key in the
> assumption that the system doesn't try to index my main source file as I
> never use key() directly on that.
> 
> Even though I hope that's the case, I don't think the spec can/should
> mandate that.

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).

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?

Would not it be easier to say 'key() is not implemented' than 'key() is implemented but
unusable'?

David Tolpin

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