The XPath spec expects that the data model (our adapter implementation) respect the XPath data model spec. Among other things, this mandates a separation between regular element nodes, and the document node:
<foo>text</foo>
. In our model those correspond to AST nodes.<? ?>
delimited nodes, eg FXML imports)The point is, that equating the node that is at the top of a tree and the document node doesn't respect this specification. Our Jaxen adapter does this at the moment, and for that reason, there is yet another inconsistency between our XPath implementations. The document node contains a root element node - this is why the XPath kind test form document-node(element(CompilationUnit))
exists.
/
(a single slash) is perfectly valid and yields the special document node (!= root element).UserClass
) implicitly uses the child
axis (so is equivalent to child::UserClass
)/UserClass
expands to /child::UserClass
. The problem is that our implementation considers that /
, the document node, is the root UserClass
. So /child::UserClass
actually only yields UserClass that are children of the root of the AST -> meaning, not the root UserClass, but only nested classes. So to actually get the root element you have to use /self::UserClass
/
evaluates to a DocumentNode instance whose only child is the root UserClass. So /UserClass
actually yields the top-level class.This is yet another nail in the coffin of our Jaxen adapter.
Anyway we should be paying attention to that when refactoring XPath support, and in particular:
/
evaluates to the synthetic document node(/)[self::document-node()]
yields a non-empty sequence(/)[self::document-node(element(CompilationUnit))]
yields a non-empty sequenceRetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4