This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29430 - [FO31] Resulting type of numeric functions
Summary: [FO31] Resulting type of numeric functions
Status: CLOSED WORKSFORME
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-07 18:39 UTC by Abel Braaksma
Modified: 2016-03-03 10:13 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2016-02-07 18:39:42 UTC
This bug report originated from the discussion in bug 29420, a QT3 test bug.

The question I would like to raise is what type is expected to be returned:

   fn:sum((xs:byte(1), xs:byte(2))
   fn:sum((xs:unsignedShort(12), xs:unsignedShort(24))
   fn:sum((xs:nonNegativeInteger(42), xs:nonNegativeInteger(42))

My take is that, since fn:sum is defined in terms of op:numeric-plus, section 4.2 applies and they should all return xs:integer. That does not prevent them from return xs:byte, xs:unsignedShort, xs:nonNegativeInteger, but if an implementation does not return those types, it should return xs:integer (and not an xs:decimal that is itself not also an xs:integer).

Michael Kay argues in bug 29240, comment#5 that the rules in section 4.2 do not apply for fn:sum, but I think they do.

Considering the confusion this caused, does it makes sense, and is there room, for writing this up somehow? I.e., change this:

<quote>
The sum of a sequence of integers will therefore be an integer, while the sum of a numeric sequence that includes at least one xs:double will be an xs:double.
</quote>

into something like this (in particular add "of more than one"):

<quote>
The sum of a sequence of more than one integers will therefore be an integer, while the sum of a numeric sequence that includes at least one xs:double will be an xs:double. The sum of a singleton will always retain its type, while the sum of an empty sequence takes the type of the second argument, or xs:integer is absent.
</quote>
Comment 1 Michael Kay 2016-02-11 22:18:00 UTC
There are missing parentheses in your examples but I assume the intended expressions are

   fn:sum((xs:byte(1), xs:byte(2)))
   fn:sum((xs:unsignedShort(12), xs:unsignedShort(24)))
   fn:sum((xs:nonNegativeInteger(42), xs:nonNegativeInteger(42)))

that is, in each case we are concerned with sum#1 rather than sum#2.

>My take is that, since fn:sum is defined in terms of op:numeric-plus, section 4.2 applies and they should all return xs:integer. That does not prevent them from return xs:byte, xs:unsignedShort, xs:nonNegativeInteger, 

I agree with that.

>Michael Kay argues in bug 29240, comment#5 that the rules in section 4.2 do not apply for fn:sum, but I think they do.

I was arguing that the rules in section 4.2 do not apply to fn:sum() when the first argument to fn:sum is a singleton, because in that case op:numeric-plus is not invoked. The rules for fn:sum say that when the first argument is a singleton, it is returned unchanged.

>Considering the confusion this caused

Personally I think fn:sum is quite wordy enough already, and that saying the same thing in three different ways does not always add clarity.
Comment 2 Abel Braaksma 2016-02-20 17:50:42 UTC
It looks like part of the confusion came from me mixing the sum#1 and sum#2 and/or the sequence-of-one vs the sequence-of-more-than-one as first argument.

I think the current spec says this:

sum#1, if empty seq return xs:integer(0)
sum#1, if seq-of-one return $arg1 unchanged (keep type)
sum#1, if seq-gt-than-one convert result to xs:integer/xs:double etc
sum#2, if empty seq return $arg2 unchanged (keep type)
sum#2, with non-empty $arg1 same as sum#1.

If this is how it is supposed to work then I think that my argument is void. I thought we both had a different reading of the spec (and add to that some additional confusion on my end), but this appears not the case.

If that's indeed the case, let's close with no action.
Comment 3 Abel Braaksma 2016-03-03 10:13:06 UTC
Following decision from WG meeting #634, this bug can now be closed with no action.