Support of numeric values over the 64-bit limits

[gregsdennis]

We have recently added several optional tests to the test suite that cover cases for very large and very precise numeric values (both floating point and integer). This was done citing that JSON supports arbitrarily large values.

While it's true that JSON supports these values, the specification does also contain this guidance:

This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.

Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values.

We should take this advice into consideration when promoting these tests. I wonder if it's worth creating a new category of tests. "Optional" tests to me imply that the cases are typical, but the spec says support for them isn't strictly required. Big-num support seems more like an edge-case to me: something that could be supported if you really want, but it's a bit overambitious to do so.

[awwright]

Strictly speaking, JSON Schema assumes that it is validating the document before it's decoded.

For compatibility with JSON, maybe we can explain that since parsers can lose precision during the parsing, then it is legal to validate the parsed value if that value would be valid in the original document, even if the original value is not.

We can think of this as an additional case in between "valid" and "invalid" — let's call it "coerced" (a value that was invalid in the original document, strictly speaking, but was able to be parsed into a valid value). There might also be a fourth class of values, let's call them "corrupted" (valid in the original document, but became invalid at parse time.)

An example of a "corrupted" value: 7e100 against the schema {divisibleBy: 7} — this has a modulus of 1 in float64 math, but in arbitrary-precision math it's actually 0.

(I'm not sure how we address the "corrupted instance" case.)

[awwright]

Maybe I'm trying too hard to preserve the "validate what's written not what's decoded" assumption.

Maybe we change this assumption entirely, to something like: "Validators should validate what the application actually sees instead of what is written in the document. For JSON parsers that use float64 math, validators should validate against this parsed value." with the condition:

The parsed value MUST have an exact & equivalent JSON representation

This removes the possibility of a validator seeing NaN or Inf.

[awwright]

This removes the possibility of a validator seeing NaN or Inf.

I just realized this may be a problem. ECMAScript JSON.parse can produce Infinity:

> JSON.parse('1e400');
Infinity

[karenetheridge]

Infinity and NaN are outside the JSON document model, so given the current specification, their treatment by an implementation is undefined.

I checked mine and (simply as a byproduct of how numbers are represented inernally) Inf and -Inf values are recognized as integers and NaN is recognized as a number, and comparisons with them e.g. from "minimum": 0 do evaluate correctly: -Inf < 0 < -Inf, and both 0 < NaN and 0 > NaN are false.