This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We repeat our previous last call comment regarding the semantics of untyped values with value comparisons. The argument of providing transitivity on the user-level syntax for lt, eq, and friends is too weak to introduce the current inconsistency between the general and value comparison treatment of untypedAtomic values. Instead, logical discourse on the transitivity needs to be held on the expanded expressions that have added the implied casts. Note that no general transitivity can be guaranteed anyway due to the impreciseness of float/double value comparisons anyway. We consider the usability aspect of consistent treatment of untypedAtomic values between value and general comparison (and following the general comparison semantics) important enough, that we consider filing a minority opinion on this topic, if it does not get fixed.
(In reply to comment #0) > The argument of providing transitivity on the user-level syntax for lt, eq, > and friends is too weak to introduce the current inconsistency between the > general and value comparison treatment of untypedAtomic values. Instead, > logical discourse on the transitivity needs to be held on the expanded > expressions that have added the implied casts. One of the important reasons for transitivity in these comparisons is to give us a way to sort values. We use the 'gt' operator for this, and if we adopted your proposal, it would cast untypedAtomic values in the same way as the > operator. Query: let $a := <i>100</i>, $b := <i>4</i>, $c := 5 return <compare> <ab>{ $a > $b }</ab> <bc>{ $b > $c }</bc> <ac>{ $a > $c }</ac> </compare> Output: <compare> <ab>false</ab> (: "100" > "4" :) <bc>false</bc> (: "4" > 5 :) <ac>true</ac> (: "100" > 5 :) </compare> Some of these comparisons are done lexicographically, others numerically, because of the casting rules, which makes the result intransitive. Suppose an order by clause requires us to sort these three values. What order should they appear in?
I think it is easier to understand if order-by has a slightly different type semantics than lt,<. So I advocate to have clean order-by semantics and still align value and general comparison operators.
> I think it is easier to understand if order-by has a slightly > different type semantics than lt,<. So I advocate to have clean > order-by semantics and still align value and general comparison > operators. I assume you are saying that we would introduce a different operator, a transitive one, for order by, to replace the operators that you propose to make non-transitive? I would have to see a concrete proposal before I can comment technically, but I am concerned that we already have too many ways of comparing items in XQuery, and I'm reluctant to add one more.
Yes, I am recommending to keep order by's semantic (or make it a bit more restrictive, at least for static typing implementations) and align value and general comparisons. This will not introduce additional ways to compare but shift the alignment.
Created attachment 390 [details] Slides discussing this comment
Michael, The Query and XSLT Working Groups discussed this comment at a joint meeting on July 20, 2005. We agree that the current inconsistency in casting behavior between the value comparisons and general comparisons is unfortunate. However, several members observed that making the two kinds of comparison more consistent would simply push the inconsistency to another place, such as between comparison operators and "order by". Also, several members were concerned by the impact of non-transitive comparison operators on query rewrites and on access methods such as indexes, sort-merge joins, and hash joins. For these reasons, the working groups jointly decided not to change the XPath and XQuery specifications as suggested by this comment. The attachment contains a set of slides used by the working groups in discussion of this comment. Since you participated in the working group discussion, I am marking the comment as closed. If you are not satisfied with the decision of the working groups, you may reopen the comment. Regards, Don Chamberlin (for the Query and XSLT working groups)
Microsoft Corporation has formally objected to the working group's resolution of this bug. Michael Rys provided the rationale in http://lists.w3.org/Archives/Member/w3c-xsl-query/2005Sep/0055.html "We feel that the arguments made in the Working group in favor of the current semantics on the value comparisons are less beneficial and more costly for our users and implementers for supporting them, than our proposed alternative that aligns the semantics with the general comparison operators. We provided a detailed change proposal at http://lists.w3.org/Archives/Member/w3c-xsl-query/2005Jun/0027 that showed how our proposal can address all the concerns brought forward on the technical level."
Writing as scribe for the joint XQuery/XSL working group: The working groups considered Microsoft's objection at a joint meeting on 29 September 2005 and there was no other support for changing the disposition of the original comment.