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 15731 - [QT3] orderBy29a, orderBy52a
Summary: [QT3] orderBy29a, orderBy52a
Status: CLOSED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Member-only Editors Drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Andrew Eisenberg
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-26 16:08 UTC by Tim Mills
Modified: 2012-03-01 08:52 UTC (History)
1 user (show)

See Also:


Attachments

Description Tim Mills 2012-01-26 16:08:52 UTC
These tests use <assert-serialization> to check the results.

One value in the result is an xs:double 0, but I think that xs:double -0 is also valid.  

Perhaps the tests could be tweaked to using assert-serialization.
Comment 1 Andrew Eisenberg 2012-02-28 22:57:11 UTC
I believe that -0 cannot appear in this result. The test case is:

        declare default element namespace "http://www.w3.org/XQueryTestOrderBy"; 
        <results> { 
            for $x in /DataValues/NegativeNumbers/orderData 
            order by ($x * -1) descending 
            return ($x * -1e0) (:force to xs:double:) 
        } </results>

This test case uses orderdata2, so that the source document is not validated. The source document contains an xs:untypedAtomic -0 value. The return multiplication first casts this to xs:double -0 and then does the multiplication, returning xs:double 0.
Comment 2 Tim Mills 2012-03-01 08:52:56 UTC
Agreed.  It was my test harness, trying to avoid loading the same document more than once, which mean it was using the validated version.