30259 2018-05-31 19:26:57 +0000 [FO31] Normative function implementation given for fn:sum#2 seems to be at odds with the text 2018-05-31 20:31:12 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.1 Recommendation PC Windows NT NEW P2 normal --- 1 abel.online mike public-qt-comments oldest_to_newest 129275 0 abel.online 2018-05-31 19:26:57 +0000 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? 129276 1 mike 2018-05-31 20:31:12 +0000 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).