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 "-0" 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.

It's odd that decimal doesn'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: "The ·value space· of integer is the infinite set {...,-2,-1,0,1,2,...}." 

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.

(In reply to comment #2)
> It's odd that decimal doesn'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
> 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: "The
> ·value space· of integer is the infinite set {...,-2,-1,0,1,2,...}." 

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...
> 
> 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. 
> 
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 <orderData>0</orderData> rather than <orderData>-0</orderData>.

Looking at the history here:

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

it's clear that the reason there are alternative results for these tests is to allow for processors that don't validate the input and process it as untyped. We've moved on from there: such processors shouldn't run this test, and the alternative untyped results should therefore be removed.

(In reply to comment #4)
> Looking at the history here:
> 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=1997
> 
> it's clear that the reason there are alternative results for these tests is
> to allow for processors that don't validate the input and process it as
> untyped. We've moved on from there: such processors shouldn't run this test,
> and the alternative untyped results should therefore be removed.

Please see test set "prod-OrderByClause", test cases "orderBy20" and "orderBy21"

Only accepted results for these test cases are with "-0" (negative zero).

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.

>The correct results should only contain 0, without the minus.

No, that'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 "-0".

One *could* justify returning "0" as an alternative, on the theory that 

"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."

(XDM 3.0 section 6.2.4)

The "0" 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't validate the input should be removed (since they should not run this test).

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.

prod-OrderByClause/orderBy20 and orderBy21 were not fixed.

(In reply to comment #10)
> prod-OrderByClause/orderBy20 and orderBy21 were not fixed.

Test cases now fixed with additional expected results.