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 [EMAIL PROTECTED] 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.
