DO NOT REPLY [Bug 22311] - XPath expresssion does not work against cloned node

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22311

XPath expresssion does not work against cloned node





------- Additional Comments From keshlam@us.ibm.com  2003-08-12 21:49 -------
The problem isn't so much the API as the fact that we're having to invent a 
meaning for a use-case XPath didn't anticipate. XPath was architected to run 
against complete documents. Running it against isolated nodes, out of context, 
is going to change the meaning of some operators. The problem is figuring out 
what interpretation makes most sense in terms of both clarity and efficiency.

For example: If a path starts with / or //, that runs relative to the XPath root 
of the document -- which in DOM terms means the Document node. When your node 
isn't actually part of the document tree, that probably isn't what you intended. 
We could interpret / as the root of the subtree, but that would mean that an 
orphan <foo> element would match / but wouldn't match /foo... which is 
unintuitive. A workaround would be to say that it's your responsibility to put 
the orphaned element in a DocumentFragment before calling us, so the 
DocumentFragment becomes the root node and everything works more-or-less 
normally from there. (Of course allowing for either of these means / will run 
more slowly than it should, since we can no longer take the quick 
get-owner-document jump to reach the root of the tree.)

I believe that last actually is closest to what we're currently doing -- but I'd 
have to wade through the code again to be sure.