This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1414 - [XQuery] Semantics: Treatment of untyped values with value comparisons
Summary: [XQuery] Semantics: Treatment of untyped values with value comparisons
Status: CLOSED WONTFIX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-13 20:26 UTC by Michael Rys
Modified: 2005-09-29 11:36 UTC (History)
0 users

See Also:


Attachments
Slides discussing this comment (85.84 KB, application/pdf)
2005-07-20 21:57 UTC, Don Chamberlin
Details

Description Michael Rys 2005-05-13 20:26:35 UTC
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.
Comment 1 Jonathan Robie 2005-05-17 22:31:42 UTC
(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?
Comment 2 Michael Rys 2005-05-18 03:18:52 UTC
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.
Comment 3 Jonathan Robie 2005-05-18 13:51:31 UTC
> 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.
Comment 4 Michael Rys 2005-05-18 13:58:02 UTC
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.
Comment 5 Don Chamberlin 2005-07-20 21:57:05 UTC
Created attachment 390 [details]
Slides discussing this comment
Comment 6 Don Chamberlin 2005-07-20 21:58:53 UTC
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)
Comment 7 Michael Champion 2005-09-29 11:34:21 UTC
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."
Comment 8 Michael Champion 2005-09-29 11:36:40 UTC
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.