This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In #3443, I reported a number of test cases for which I felt additional results were justified. I'd like to add to that list and suggest that test cases support the following additional values: Test Case Existing value Additional Value extvardeclwithouttype-18 2.333333333333333333 2.333333333333 extvardeclwithtype-18 2.3333333 2.33333 fn-avg-mix-args-009 -50.5000000000005 -50.5
Concerning extvardeclwithouttype-18, this effectively returns the result of (7 div 3) (which is an xs:decimal). This is governed by the rule: For xs:decimal values the number of digits of precision returned by the numeric operators is ·implementation-defined·. If the number of digits in the result exceeds the number of digits that the implementation supports, the result is truncated or rounded in an ·implementation-defined· manner. Implementations are required to support at least 18 digits. My reading is that you have to take the two sentences together, and this means that the result of the division must be at least 18 digits. Therefore the result 2.333333333333 is wrong. On a more practical point, however, it's clear that there are an infinite number of correct results for this query. The simplest solution would therefore be to change the query so that instead of computing avg(4,2,1), it computes avg(8,4,2,1), which is incontrovertibly 7.5. Concerning extvardeclwithtype-18, the result here is the decimal value of (8 div 3) converted to a float. Similar considerations therefore apply. Concerning fn-avg-mix-args-009 teh query here is: fn:avg( ( ( xs:decimal("-1.000000000001"), xs:integer("-100")))) The correct answer to this can be expressed exactly in 15 decimal digits of precision, and since all products are required to support this number of digits, I do not think any answer other than -50.5000000000005 is acceptable.
Carmelo, please add these expected results to their associated test cases. We can remove them once we have a rulin gfrom the XSL and XML Query WGs.
All: Added extra values and will leave bug open, pending a resolution of the Working Group. Thanks, Carmelo
Found one more of these Test Case Existing value Additional Value op-divide-dayTimeDuration-by-dTD-1 1.437834967320261 1.4378349673
I keep thinking that I've found the last of these, but ... Test Case Existing value Additional Value op-numeric-dividesht2args-5 -1.000030518509475997 -1.000030518509 op-divide-dayTimeDuration-by-dTD-1 1.437834967320261 1.4378349673 I've added the additional expected results to these test cases, so no further action is required until we get a ruling from the WGs.
As per the working groups decison to allow arbitrary number of digits. 15 digits is acceptable for these types of decimal operations. I am marking this bug as closed. Any implementatin that differs from the given outcomes should provide those to the Task force. Thanks, Carmelo