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