commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michele Vivoda (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (JXPATH-188) Ancestor: not reverse axis in case of org.w3c.dom documents
Date Fri, 11 Dec 2015 06:04:11 GMT

    [ https://issues.apache.org/jira/browse/JXPATH-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051871#comment-15051871
] 

Michele Vivoda edited comment on JXPATH-188 at 12/11/15 6:03 AM:
-----------------------------------------------------------------

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://stackoverflow.com/a/15197042/1536382 (sort in XPath applications)
http://lists.xml.org/archives/xml-dev/200410/msg00005.html (spec pointers)
http://lists.xml.org/archives/xml-dev/200410/msg00006.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.





was (Author: vivodamichele@hotmail.com):
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/msg00005.html (spec pointers)
http://lists.xml.org/archives/xml-dev/200410/msg00006.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, 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)

Mime
View raw message