Re: XPath on DOM nodes not inserted in the owner document

Martin Honnen wrote:
> 
> The XPath data model is defined on a complete document tree and only for 
> nodes in that document tree. The W3C DOM Level 3 XPath note however 
> defines XPath on DOM nodes and with the DOM you can have nodes that are 
> not (currently) inserted in the DOM document tree (e.g. by creating a 
> node with a factory method like createElement and not inserting it in 
> the document or by taking a node in the document and calling 
> node.parentNode.removeChild on the node). Is there any specification 
> that defines how the XPath data model with things like the root node 
> denoted by '/' applies to DOM nodes that have parentNode as being null?
> 
> Mozilla and Opera 9 behave differently here, with Mozilla the XPath / 
> evaluated relatively to a node with no parent node does not find any 
> node while with Opera 9 the node itself is returned as the "root node".

Have you tested in recent nightlies? We have actually changed our 
behavior here to make it more predictable. Each orphaned subtree is more 
or less considered its own document. So evaluating '/' in that subtree 
will return the root of that subtree.

Similarly, if the expression 'id("hi")' is evaluated with the context 
node living in an orphaned subtree it will only search for nodes in that 
same orphaned subtree.

This affects XSLT patterns too. In a subtree with a root element named 
'god' both XSLT patterns '/' and 'god' will match that node. This 
becomes an issue when using the XSLTProcessor object.

Finally, XSLT keys are affected. Evaluating the key() function when the 
context node is in an orphaned subtree, only nodes in that subtree will 
be returned. This is very similar to id(). Note that this doesn't 
necessarily mean that only descendants of the context node are returned 
from id() and key().

If this does not work as described on trunk, please file a bug.

/ Jonas