[
https://issues.apache.org/jira/browse/JCR-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485453
]
Stefan Guggisberg commented on JCR-789:
---------------------------------------
Marcel wrote:
> IMO the INDEX_UNDEFINED only makes sense in context of an XPath query. If a
> path element does not have an index in XPath then all same named nodes are
> selected regardless of what index they have. Whereas in the JCR API
> Node.getNode("foo") and Node.getNode("foo[1]") is the same.
>
> I think the crucial question is: does the spec says anywhere an 1-index needs
> to preserved in a path?
you're right, it doesn't.
the original idea behind INDEX_UNDEFINED was to distinguish an implicit "[1]"
subscript from an explicit "[1]".
i.e. to preserve e.g. the following string representation: "/foo[1]/bar". it's
not required by the spec and whether
that's useful feature or not is another question.
personally i am not particularly attached to INDEX_UNDEFINED, i wouldn't be
opposed to removing it.
> PathElement.equals doesn't handle INDEX_UNDEFINED
> -------------------------------------------------
>
> Key: JCR-789
> URL: https://issues.apache.org/jira/browse/JCR-789
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Reporter: Julian Reschke
> Priority: Minor
> Attachments: jcr789.diff.txt
>
>
> PathElement (and therefore Path) comparisons fail when INDEX_UNDEFINED is
> used (it's treated differently from INDEX_DEFAULT).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
