Henry Zongaro wrote: > I just wanted to clarify the remarks that I made during the defect review > meeting. Another user ran into this problem trying to do the same sort of > things with the node-set function key, and that's why I opened the Jira > issue. What I said about XSLT 2.0 was that the fact that it allows the > key function to return nodes from temporary trees would be an argument in > favour of doing the same thing in XSLT 1.0 if the key function is > evaluated with a context node that is in a tree returned by the node-set > extension function.
Thanks for that explanation, but it still sounds like you're under the impression that supporting keys on converted result tree fragments / temporary trees is an enhancement or questionable interpretation of XSLT 1.0. It's true the spec is a little loose with its use of the term "document" at times, but it is very clear about the fact that it operates on the XPath/XSLT node tree models only. I don't think it's a stretch to say that a root node "is" a document, in this model. So, once the fragment becomes a real node-set consisting of a single root node, it is indistinguishable from any other document, as far as the processor is concerned. That it was generated internally and not obtained from parsing a byte stream isn't relevant. Given the way key() is specified, then, it is reasonable to expect that a conforming XSLT 1.0 processor, for purposes of keys, would treat it no differently than any other. What XSLT 2.0 does is immaterial. So, I would consider it higher priority than a feature request; it's a real implementation gap, if not a "bug". However, there are generally workarounds (inefficient) for most key-related operations, so it's not as high a priority as other issues. Thanks, Mike
