W3C home > Mailing lists > Public > public-qt-comments@w3.org > March 2015

[Bug 28319] [FO30] (and [FO31]) Text on least common type and conversion in fn:min and fn:max ambiguous

From: <bugzilla@jessica.w3.org>
Date: Tue, 24 Mar 2015 14:28:12 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-28319-523-3RvoCPtNXd@http.www.w3.org/Bugs/Public/>

--- Comment #5 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
>From bug 26453, MKay wrote:

    If anyone doesn't believe this is an improvement, then I threaten 
    to write some tests for the edge cases under the current rule and watch 
    implementations break...

Now, I do think very strongly that this is an improvement, but it is quite
possible to write a test that fails in older implementations and succeeds in
newer, depending on the interpretation of the FO30 text:

max((xs:integer(12), xs:decimal(10))) instance of xs:integer

will return FALSE in FO30 (tested with Saxon) but will return TRUE with the new
text of FO31.

I highly doubt that any existing code out there will rely on this behavior. I
can't find tests that break (90% tests conversion to xs:double), but there are
some tests that test LCT, for example:

> max((1.0, 1, 1, 1, 1)) instance of xs:decimal
>> change it to xs:integer and the outcome is debatable (items are equal)
>> the NOTE says this explicitly though

> let $var := max((xs:long(20),xs:short(13))) return $var instance of xs:integer
>> change it to "max((xs:long(10),xs:short(13))) instance of xs:short" and 
>> it was false (FO30) is true (FO31)

I do not know if this warrants a comment in the changes section of the spec,
but it is a change that in rare edge cases has different results.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 24 March 2015 14:28:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:53 UTC