<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://www.w3.org/Bugs/Public/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4"
          urlbase="https://www.w3.org/Bugs/Public/"
          
          maintainer="sysbot+bugzilla@w3.org"
>

    <bug>
          <bug_id>21619</bug_id>
          
          <creation_ts>2013-04-08 13:09:05 +0000</creation_ts>
          <short_desc>wrong results when handeling -0 negativeZero</short_desc>
          <delta_ts>2013-05-07 16:34:28 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>XPath / XQuery / XSLT</product>
          <component>XQuery 3 &amp; XPath 3 Test Suite</component>
          <version>Working drafts</version>
          <rep_platform>PC</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Cezar Andrei">cezar.andrei</reporter>
          <assigned_to name="O&apos;Neil Delpratt">oneil</assigned_to>
          <cc>cezar.andrei</cc>
    
    <cc>mike</cc>
    
    <cc>spungi</cc>
          
          <qa_contact name="Mailing list for public feedback on specs from XSL and XML Query WGs">public-qt-comments</qa_contact>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>85706</commentid>
    <comment_count>0</comment_count>
    <who name="Cezar Andrei">cezar.andrei</who>
    <bug_when>2013-04-08 13:09:05 +0000</bug_when>
    <thetext>Test case prod-FLWORExpr/ForExprType010 and prod-OrderByClause/orderBy26 should check for a return value of -0 not 0. The two cases load up the value -0 from an XML document as decimal values and returns it. According to XMLSchema 1.1 http://www.w3.org/TR/xmlschema11-2/#sec-chnum and the note on http://www.w3.org/TR/xpath-functions-30/#numeric-types -0 and 0 are distinct values and should be treated acordingly.


Related is prod-OrderByClause/orderBy29 that returns ($x * -1e0) where $x is -0. Since it doesn&apos;t come from &quot;-0&quot; sting or the result of &quot;-&quot; unary opperator it should return just 0 (pozitive zero).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>85715</commentid>
    <comment_count>1</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2013-04-08 13:52:01 +0000</bug_when>
    <thetext>Concerning ForExprType010, the values are decimal rather than double/float, and the type xs:decimal does not have a negative zero in its value space.

Concerning orderBy29, the last result in the sequence is formed by converting &quot;-0&quot; to decimal (giving zero) and then multiplying by the double value -1e0. First the decimal zero is converted to the double (positive) zero, then this is multiplied by double minus one. The IEEE rules are that +0e0 times -1e0 gives negative zero.

So I believe both tests are correct.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>85758</commentid>
    <comment_count>2</comment_count>
    <who name="Cezar Andrei">cezar.andrei</who>
    <bug_when>2013-04-08 23:37:20 +0000</bug_when>
    <thetext>It&apos;s odd that decimal doesn&apos;t support -0 while float and double does. The XMLSchema 1.1 it not very clear, defines the value space of decimal by using the value space of integer, while the value space of integer says only: &quot;The ·value space· of integer is the infinite set {...,-2,-1,0,1,2,...}.&quot; 

If this means that there is no -0 as a decimal, which means that the test case prod-OrderByClause/orderBy20 and orderBy21 have the wrong result. 

The tests cases parses -0 (from orderData.xml) as a decimal (according to orderData.xsd) and returns it, just like prod-FLWORExpr/ForExprType010 and prod-OrderByClause/orderBy26. But the result is expected as -0.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>85775</commentid>
    <comment_count>3</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2013-04-09 08:44:18 +0000</bug_when>
    <thetext>(In reply to comment #2)
&gt; It&apos;s odd that decimal doesn&apos;t support -0 while float and double does.

Well, in my view the concept of negative zero is pretty odd to start with, but who are we to argue?
 The
&gt; XMLSchema 1.1 it not very clear, defines the value space of decimal by using
&gt; the value space of integer, while the value space of integer says only: &quot;The
&gt; ·value space· of integer is the infinite set {...,-2,-1,0,1,2,...}.&quot; 

I think we can be glad that the XSD designers took a few concepts as given, rather than attempting to formalize the whole system of arithmetic...
&gt; 
&gt; If this means that there is no -0 as a decimal, which means that the test
&gt; case prod-OrderByClause/orderBy20 and orderBy21 have the wrong result. 
&gt; 
I have no idea why these tests include more than one permitted result, but the reason they include -0 in the result is that the query is returning the orderData elements, not their atomized values. However (I think), an implementation is permitted to retain the typed value rather than the string value, and to reconstitute the string value on serialization, and such an implementation could legitimately output &lt;orderData&gt;0&lt;/orderData&gt; rather than &lt;orderData&gt;-0&lt;/orderData&gt;.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>85776</commentid>
    <comment_count>4</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2013-04-09 08:51:04 +0000</bug_when>
    <thetext>Looking at the history here:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=1997

it&apos;s clear that the reason there are alternative results for these tests is to allow for processors that don&apos;t validate the input and process it as untyped. We&apos;ve moved on from there: such processors shouldn&apos;t run this test, and the alternative untyped results should therefore be removed.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>85865</commentid>
    <comment_count>5</comment_count>
    <who name="Sorin Nasoi">spungi</who>
    <bug_when>2013-04-10 15:16:38 +0000</bug_when>
    <thetext>(In reply to comment #4)
&gt; Looking at the history here:
&gt; 
&gt; https://www.w3.org/Bugs/Public/show_bug.cgi?id=1997
&gt; 
&gt; it&apos;s clear that the reason there are alternative results for these tests is
&gt; to allow for processors that don&apos;t validate the input and process it as
&gt; untyped. We&apos;ve moved on from there: such processors shouldn&apos;t run this test,
&gt; and the alternative untyped results should therefore be removed.

Please see test set &quot;prod-OrderByClause&quot;, test cases &quot;orderBy20&quot; and &quot;orderBy21&quot;

Only accepted results for these test cases are with &quot;-0&quot; (negative zero).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>85867</commentid>
    <comment_count>6</comment_count>
    <who name="Cezar Andrei">cezar.andrei</who>
    <bug_when>2013-04-10 16:11:12 +0000</bug_when>
    <thetext>I think we all agree that the results for prod-OrderByClause/orderBy20 and orderBy21 should not contain -0. As it stands right now, there are only results that contain -0:

http://dev.w3.org/cvsweb/2011/QT3-test-suite/prod/OrderByClause.xml?rev=1.9;content-type=text%2Fplain

The correct results should only contain 0, without the minus.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>85868</commentid>
    <comment_count>7</comment_count>
    <who name="Michael Kay">mike</who>
    <bug_when>2013-04-10 16:28:01 +0000</bug_when>
    <thetext>&gt;The correct results should only contain 0, without the minus.

No, that&apos;s wrong. As I explained in comment 3 these tests are returning the original element from the input XDM instance, which contains the text node &quot;-0&quot;.

One *could* justify returning &quot;0&quot; as an alternative, on the theory that 

&quot;If an implementation stores only the typed value of an element, it may use any valid lexical representation of the typed value for the string-value property.&quot;

(XDM 3.0 section 6.2.4)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>85869</commentid>
    <comment_count>8</comment_count>
    <who name="Cezar Andrei">cezar.andrei</who>
    <bug_when>2013-04-10 16:50:49 +0000</bug_when>
    <thetext>The &quot;0&quot; result should be added as an alternate result for processors that store only the typed value.

And as you mentioned in comment #4, the alternate result for processors that don&apos;t validate the input should be removed (since they should not run this test).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>87104</commentid>
    <comment_count>9</comment_count>
    <who name="O&apos;Neil Delpratt">oneil</who>
    <bug_when>2013-05-01 14:02:03 +0000</bug_when>
    <thetext>Inline with the agreed resolution in comment #8 I have made the changes to the test cases i.e. alternative result, and committed them to cvs.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>87116</commentid>
    <comment_count>10</comment_count>
    <who name="Sorin Nasoi">spungi</who>
    <bug_when>2013-05-01 18:18:37 +0000</bug_when>
    <thetext>prod-OrderByClause/orderBy20 and orderBy21 were not fixed.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>87355</commentid>
    <comment_count>11</comment_count>
    <who name="O&apos;Neil Delpratt">oneil</who>
    <bug_when>2013-05-07 16:34:28 +0000</bug_when>
    <thetext>(In reply to comment #10)
&gt; prod-OrderByClause/orderBy20 and orderBy21 were not fixed.

Test cases now fixed with additional expected results.</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>