This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This comment is about one of the language features defined in "W3C XPath 2.0, PER document". Though, this language feature is present since all previous XPath 2.0 documents. The details of my query is described below: In the following section, on "general comparisons" http://www.w3.org/TR/2009/PER-xpath20-20090421/#id-general-comparisons One of the conditions for evaluation of operator '=' is define as following: The result of the comparison is true if and only if there is a pair of atomic values, one in the first operand sequence and the other in the second operand sequence, that have the required magnitude relationship. Otherwise the result of the comparison is false. The examples given in spec says, that following two expressions are true: (1, 2) = (2, 3) (2, 3) = (3, 4) while following is false: (1, 2) = (3, 4) I think, common programming practice is that comparion operator '=' when applied to two collections, would return true if *all items* in both collections are equal by magnitude. Why does the XPath 2.0 spec defines the semantics of operator '=' in such a way that, magnitude equality of only 1 item is enough, for '=' operator to return 'true'? Regards, Mukul
(In reply to comment #0) I think, I would take back my comment. The feature I am seeking, is met by deep-equal function. The semantics is '=' now looks ok to me. Sorry about it. Regards, Mukul
>Why does the XPath 2.0 spec defines the semantics of operator '=' in such a way that, magnitude equality of only 1 item is enough, for '=' operator to return 'true'? Well, XPath 2.0 defines it this way because XPath 1.0 defined it that way, so your question translates into, why did XPath 1.0 do it this way. The factual answer is that I don't know: I wasn't at the meetings and haven't studied the minutes. However, I can speculate. With a predicate like book[title='Black Beauty'] it is very common that there is only one title, and it should be easy and intuitive to write such a query for books with only one title. If a book has no title, it seems intuitive that the predicate should not select the book. This only leaves the question of what should be done if there are multiple titles. In some other situations, XPath 1.0 took the approach of selecting the first title. Another approach, favoured in some situations in XPath 2.0, is to raise an error. Dynamic errors were not part of the culture of XPath 1.0 (and given all the problems we have since had with errors and optimizations, I have increasing sympathy with this design choice.) Choosing to compare the first item only would have probably been more consistent, but it's not clear that it would have been a more intuitive interpretation. Anyway, this decision was made more than ten years ago, and it seems to work reasonably well. If someone were starting from scratch, I expect they would do it differently, but it's not clear to me that they would do it better - XPath has proved remarkably successful.
(In reply to comment #2) Thanks, Mike for the comments. This makes me more aware of the semantics of this feature. Regards, Mukul
Thanks for keeping us on our toes. I'm now marking this bug as "invalid", as this seems the most appropriate closure category, and if this is OK with you, Mukul, I would be grateful if you could mark it as closed. Michael Kay on behalf of the XQuery Working Group
Thanks for discussing this bug report. I apologize too, to the WG for spending time for an invalid bug report. Regards, Mukul