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 30259 - [FO31] Normative function implementation given for fn:sum#2 seems to be at odds with the text
Summary: [FO31] Normative function implementation given for fn:sum#2 seems to be at od...
Status: NEW
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: 2018-05-31 19:26 UTC by Abel Braaksma
Modified: 2018-05-31 20:31 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2018-05-31 19:26:57 UTC 
For the two-argument function the spec gives the following implementation (and this seems normative)

    if (fn:count($c) eq 0) then
        $zero
    else if (fn:count($c) eq 1) then
        $c[1]
    else
        $c[1] + fn:sum(subsequence($c, 2))

However, that means that sum('a', 0) would not raise an error. And since fn:sum#1 is also defined to mean sum($arg, 0), sum('a') wouldn't raise an error either.

But the text gives:

"In addition, the type must support addition"

And this is confirmed in the explanation of FORG0006. However, I am wondering why then wouldn't the above function be defined as:

    if (fn:count($c) eq 0) then
        $zero
    else
        fn:sum($c)

Which then leads me to the assumption that the 'else if' is deliberate and trumps the rule of having to raise FORG0006, but I cannot say I am entirely sure of it. Could this be clarified in a (possible) update to the erratum?
Comment 1 Michael Kay 2018-05-31 20:31:12 UTC 
I think the intended reading is that all the rules must be satisfied. That is,

(a) All items in $arg must be numeric or derived from a single base type.

and

(b) The result of the function, using the second signature, is the result of the expression:

must both be satisfied.

Note that the supplied implementation also does not incorporate the rule that the items can be processed in any order (which could affect overflow or underflow behavior).