bseddon
commented
6 years ago I agree with this. The issue is that the grammar definition does not provide information to the PathNodeExpr instance to let it know when the relative path expression should be evaluated from the root (see XPath.y lines 528 and 533) or when it should be evaluate using the location of the context item (line 541).
In addition to the effect in a query like like the one provided by @pavelblk the effect can be seen in this query if the context node is not already the document root:
/myRootNode
In the conformance test cases the context item is always the root node so the issue never arises. However if the context node is some other node, such as the document element, then there is a problem.
A way to resolve this is to modify the PathNodeExpr class to add a new property to indicate whether the expression should be evaluated from the root or not. Then further update this class so that when the tail is created in the Execute() method (line 141) it is passed either the root node or the current context item depending upon the value of the property.
XPath.y can then be updated to set the new property of PathNodeExpr in the cases of '/' RelativePathExpr or DOUBLE_SLASH RelativePathExpr.
I've implemented such a change in my version of the source and it appears to work. If and when I have chance to run through all the conformance tests I'll submit a pull request.
StefH
pavelblk
vwegert
arkiaconsulting
cbridet
I found the wrong context handling. Exmaple:
//element1[not(@attr=//element2/@attr)]"//element2" will be started not from document root "//element2" processing as ".//element2"Solution for current release:
//element1[not(@attr=ancestor::*[not(parent::*)]//element2/@attr)]