W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2016

[Bug 29679] New: [XQ3Ts] same-key-008

From: <bugzilla@jessica.w3.org>
Date: Wed, 01 Jun 2016 15:29:00 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29679-523@http.www.w3.org/Bugs/Public/>

            Bug ID: 29679
           Summary: [XQ3Ts] same-key-008
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 3 & XPath 3 Test Suite
          Assignee: oneil@saxonica.com
          Reporter: tim@cbcl.co.uk
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

I'm not convinced that the expected result does not depend on
implementation-defined behaviour.

Consider looking up the map entry with key

1 div 3 cast as xs:float

using the key 

(1 div 3 cast as xs:float) cast as xs:decimal

According to the rules of casting, the result is 

"the xs:decimal value, within the set of xs:decimal values that the
implementation is capable of representing, that is numerically closest to SV.
If two values are equally close, then the one that is closest to zero is
chosen. "

Under Saxon, I get 0.3333333432674407958984375.

Assuming this is exactly accurate, it requires more than the minimum 18 digits
for decimal.  Therefore other implementations may legitimately return something
different, and thus the keys may not match under the rules for op:same-key.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 1 June 2016 15:29:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:00 UTC