[Bug 27180] Various minor bugs and inconsistencies

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27180

--- Comment #14 from Christian Gruen <christian.gruen@gmail.com> ---
> I'm not entirely certain why you'd expect FOAR0002. If the large integer value
> is too big for your internal representation of a decimal value, I'd have
> expected you to raise FOCA0001, but it's probably arguable.

As the description for FOCA0001 is "Input value too large for decimal.", I am
not sure if this would be the best choice, as the input is an integer (we have
no problem to represent larger decimals). We chose FOAR0002 based on the
interpretation of the spec shown below. Maybe a parse error (XQST) could be
more appropriate, but in practice, it has not been an issue so far:

* [1] "The value of a numeric literal containing no "." and no e or E character
is
  an atomic value of type xs:integer. [...] The value of the numeric literal is
  determined by casting it to the appropriate type according to the rules for
  casting from xs:untypedAtomic to a numeric type as specified in Section
  19.2 Casting from xs:string and xs:untypedAtomic FO31."

* [2] "If the value is too large or too small to be accurately represented by
the
  implementation, it is handled as an overflow or underflow as defined in
  4.2 Arithmetic operators on numeric values."

* [3] "For xs:integer operations, implementations that support
limited-precision 
  integer operations ·must· select from the following options: They ·may·
choose
  to always raise a dynamic error [err:FOAR0002]."

[1] http://www.w3.org/TR/xquery-31/#id-literals
[2] http://www.w3.org/TR/xpath-functions-31/#casting-from-strings
[3] http://www.w3.org/TR/xpath-functions-31/#op.numeric

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 19 December 2014 15:30:51 UTC