[jira] [Commented] (JXPATH-188) Ancestor: not reverse axis in case of org.w3c.dom documents
[
https://issues.apache.org/jira/browse/JXPATH-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15053036#comment-15053036
]
Michele Vivoda commented on JXPATH-188:
---
No problem at all for the test.
Interesting that now parent is a reverse axes, it must be needed now for
something, since for XPath I have read that for one-node axes it does not
matter whether they are reverse or not.
I found why selectSingleNode is wrong in JXPath, it does not consider that with
reverse axes must iterate all items and get the last, instead of just getting
the first. Probably this happened because it is what one (you, me) expects and
is more efficient, but is not how the others (JAXP) work. I also found out that
{{getDocumentOrder()}} is not implemented on some reverse axes where it
probably should. These changes are complex, break some tests and I am still not
sure about their consequences, still working on them..
> Ancestor: not reverse axis in case of org.w3c.dom documents
> ---
>
> Key: JXPATH-188
> URL: https://issues.apache.org/jira/browse/JXPATH-188
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Stefan Albrecht
> Attachments: AncestorTest.java, AncestorTest.java
>
>
> XPath specifies the ancestor axis to be a reverse axis, thus I would expect
> that JXPath delivers results along the reverse axis. This works, if applied
> to a context wrapping a poje, but not if the context wraps an org.w3c.dom
> document.
> I attached a JUnit test for this (but, unluckily, not a patch...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JXPATH-188) Ancestor: not reverse axis in case of org.w3c.dom documents
[
https://issues.apache.org/jira/browse/JXPATH-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15052394#comment-15052394
]
Stefan Albrecht commented on JXPATH-188:
Some clarification from specification on w3.org - about whether ancestor is
indeed reverse axis:
XPATH 1.0:
http://www.w3.org/TR/xpath/#predicates (Section 2.4)
(...)Thus, the ancestor, ancestor-or-self, preceding, and preceding-sibling
axes are reverse axes; all other axes are forward axes (...)
XPATH 3.1:
http://www.w3.org/TR/xpath-31/#prod-xpath31-ReverseAxis
ReverseAxis ::= ("parent" "::") | ("ancestor" "::") | ("preceding-sibling"
"::") | ("preceding" "::")| ("ancestor-or-self" "::")
(and: sorry for causing efforts due to junit 4 tests...)
> Ancestor: not reverse axis in case of org.w3c.dom documents
> ---
>
> Key: JXPATH-188
> URL: https://issues.apache.org/jira/browse/JXPATH-188
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Stefan Albrecht
> Attachments: AncestorTest.java, AncestorTest.java
>
>
> XPath specifies the ancestor axis to be a reverse axis, thus I would expect
> that JXPath delivers results along the reverse axis. This works, if applied
> to a context wrapping a poje, but not if the context wraps an org.w3c.dom
> document.
> I attached a JUnit test for this (but, unluckily, not a patch...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JXPATH-188) Ancestor: not reverse axis in case of org.w3c.dom documents
[
https://issues.apache.org/jira/browse/JXPATH-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15051871#comment-15051871
]
Michele Vivoda commented on JXPATH-188:
---
Hi,
I would have expected the same results as you do but then I tried with a JAXP
XPath implementation and it gives the same results of JXPath for DOM, so
probably is "JXPath for beans" to be wrong. I stick to DOM for now since it
has a reference to test before thinking what should be for beans.
>From the [XPath Spec|http://www.w3.org/TR/xpath/#predicates] :
bq. An axis that only ever contains the context node or nodes that are before
the context node in document order is a reverse axis.
bq. The proximity position of a member of a node-set with respect to an axis
is defined to be the position of the node in the node-set ordered in document
order if the axis is a forward axis and ordered in reverse document order if
the axis is a reverse axis. The first position is 1.
The proximity position is as expected, {{ancestor::node()\[1]\[@title]/@title}}
returns {{innerCore}}, also if {{ancestor::node()\[@title]/@title}} returns
{{outerCore,core,innerCore}}. However iteration seems always in document order.
Other pointers
http://stackoverflow.com/questions/12369734/get-all-ancestors-of-current-node
(confusing)
http://lists.xml.org/archives/xml-dev/200410/msg5.html (spec pointers)
http://lists.xml.org/archives/xml-dev/200410/msg6.html
bq. Secondly, the XPath 1.0 specification defines that a path expression (or a
union expression) returns a node-set, that is, an unordered set of nodes. Some
host languages, for example XSLT 1.0, specify that node-sets are always
processed in document order.
Probably this is an important point: In [DOM XPath
ResultType|http://www.w3.org/TR/2004/NOTE-DOM-Level-3-XPath-20040226/DOM3-XPath.html#xpath-XPathResultType]
there is mention of a {{ORDERED_NODE_ITERATOR_TYPE}} that returns results in
*document order*, this would map to {{selectNodes}} of JXPath. It says also
that {{FIRST_ORDERED_NODE_TYPE}} ({{selectSingleNode()}} in JXPath) is also in
*document order*.
Other piece of the spec, partially related:
bq. NOTE: The meaning of a Predicate depends crucially on which axis applies.
For example, preceding::foo\[1] returns the first foo element in reverse
document order, because the axis that applies to the \[1] predicate is the
preceding axis; by contrast, (preceding::foo)\[1] returns the first foo element
in document order, because the axis that applies to the \[1] predicate is the
child axis.
> Ancestor: not reverse axis in case of org.w3c.dom documents
> ---
>
> Key: JXPATH-188
> URL: https://issues.apache.org/jira/browse/JXPATH-188
> Project: Commons JXPath
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Stefan Albrecht
> Attachments: AncestorTest.java
>
>
> XPath specifies the ancestor axis to be a reverse axis, thus I would expect
> that JXPath delivers results along the reverse axis. This works, if applied
> to a context wrapping a poje, but not if the context wraps an org.w3c.dom
> document.
> I attached a JUnit test for this (but, unluckily, not a patch...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
