Hi,
You're in murky waters here, because from what I can see on the exslt web
site, there is very little information available about what this behavior
might be. And, since turning a result tree fragment into node-set is not
allowed in XSLT 1.0, you won't get any help there.
Probably what's going on is Xalan-J is re-using DTM IDs. Xalan-C does the
same sort of thing, by re-using memory that was previously allocated for a
result tree fragment that's no longer in scope. The question is, do you
want to give what may be critical performance enhancements for the ability
to perform operations that are not officially allowed? If this operation
_were_ allowed, could know if a result tree fragment were used this way,
and make sure stylesheets which use generate-id behave properly. Of
course, that might be a problem in a stylesheet that created lots of result
tree fragments, because you could theoretically run out of IDs.
Dave
bSpot
<[EMAIL PROTECTED]> To: [EMAIL PROTECTED]
cc: (bcc: David N
Bertoni/Cambridge/IBM)
11/20/2003 05:14 Subject: exslt:nodeSet and
generate-id
PM
Hello, friends of the mighty XSLT!
I wonder if there's someone here who could answer this question:
For any result-tree-fragment f, what is the URI of the document that ownes
the
nodes returned by exslt:nodeSet(f)?
This is particulary interesting to me, because I tried to use the
generate-id() function (which, if I'm right, determines the equality of
nodes
based on the URI of the document they belong to) on some nodes gained in
this
way and experienced certain irregularities in the results returned. In
particular, *sometimes* nodes gained by different calls to exslt:nodeSet
get
the same id, *sometimes* they don't, and I can not yet describe the
circumstances of either behaviour.
Well... TIA
bSpot
