[Bug 29419] [XP31] edge case with negative integer literals (UnaryExpr) and limits for -9223372036854775808, which cannot be parsed

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

--- Comment #5 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
(In reply to Michael Kay from comment #4)
> The spec requires support for at least 18 digits - and an implementation
> that took that literally would not allow 9223372036854775808 anyway (I make
> it 19 digits).
I had some trouble finding this, but see it now in XSD 1.0:

<quote>
Note:  All ·minimally conforming· processors ·must· support decimal numbers
with a minimum of 18 decimal digits (i.e., with a ·totalDigits· of 18).
However, ·minimally conforming· processors ·may· set an application-defined
limit on the maximum number of decimal digits they are prepared to support, in
which case that application-defined maximum number ·must· be clearly
documented. 
<quote>

Interestingly, this is a "Note" that contains a "MUST", which seems in
contradiction with itself. Nevertheless, this then has the effect that xs:long,
xs:positiveInteger, xs:unsignedLong and the like *MAY* be limited by the
IntegerLiteral production in XPath, even though those very same types have, in
the same XSD 1.0, normative limits that extend to 19 digits.

I feel as though this is a rather strange conflicting limit:

1) xs:decimal *MAY* be limited to 18 digits
2) xs:unsignedLong etc *MUST* be allowed a range to 2^64

I understand that these limits are imposed from the dependency on XSD 1.0 and
not so much by XPath itself.

By extension, since we say in XPath that an IntegerLiteral must be treated as
an xs:integer (as opposed to an xs:decimal), this inherits its restriction.
xs:integer itself has no (extra) restriction. But further derived types like
xs:unsignedLong have a restriction, are xs:integer and therefore xs:decimal but
require more digits than a *MINIMALLY CONFORMING PROCESSOR* is required to
support.

I don't know if this is a spec issue or not, but it seems that different
definitions are in conflict with one another.

> The only place where 2^64 comes into play is for types such as xs:long; but
> we don't have xs:long literals in the language, you can only construct them
> from strings or xs:integer values, where the issue of "-" being an operator
> rather than part of the value doesn't arise.
True, with the caveat that xs:unsignedLong(18446744073709551615) (20 digits) is
parsed as xs:integer from the literal, then cast to unsignedLong. But the first
step may fail because of the limits-restriction. Obviously, this can be
circumvented by writing xs:unsignedLong("18446744073709551615").

> So you may have an implementation issue here, but I don't think there is a
> spec issue.
I'm not sure, you may be right. Actually, given the current spec and this
discussion, I think an implementation (minimally conforming) *MAY* throw
FOAR0002 on xs:unsignedLong(18446744073709551615) and *MUST NOT* throw on
xs:unsignedLong("18446744073709551615").

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

Received on Friday, 5 February 2016 14:51:40 UTC