lucidsoftware/xtract

XPath's first index is 0 in the implementation of xtract instead of 1

Closed this issue · 2 comments

According to W3C the first child node in XPath has the index 1 and not 0. So the example /bookstore/book[1] selects the first child node of the node book. And the documentation for the XPath class states that the apply(idx: Int) function is equivalent to [idx] in the XPath syntax. However this function calls the function def apply(i: Int): Node = theSeq(i) in the NodeSeq class of scala-xml, which takes the i-th element of the sequence and this actually means that the XPath implementation starts counting at 0 and not 1, so this behaviour differs from the documentation.

My question is now: is it intended behaviour that the apply(idx: Int) function starts counting at 0 and breaks the XPath spec? In that case, the documentation is wrong and I can create a PR for the documentation.

Laurin

I wasn't aware xpath started counting at 1. I think starting counting at 0 is the intended behaviour, and changing that to be 1-based now would be backwards incompatible, so I'm inclined to prefer changing the documentation to clarify it is 0-based. I might be ok with changing this to be 1-based in a future major version, if there is a compelling reason to do so.

That's what I thought. Fixing the docs is way easier and won't cause compatability issues. I created a PR for the docs improvements.