Add boundary cases for integers #774
Conversation
| { | ||
| "description": "a float with zero fractional part is an integer", | ||
| "data": 1.0, | ||
| "valid": true | ||
| }, |
There was a problem hiding this comment.
Not sure why this wasn't included in draft3 already, but there might be a reason!
| { | ||
| "description": "a float with zero fractional part is an integer", | ||
| "data": 1.0, | ||
| "valid": true | ||
| }, |
There was a problem hiding this comment.
Not sure why this wasn't included in draft4 already, but there might be a reason!
There was a problem hiding this comment.
draft4 and earlier have different integer semantics: in draft4, an integer is "A JSON number without a fraction or exponent part", therefore 1.0 is NOT an integer.
There was a problem hiding this comment.
There ought to be a draft4 test for 1.0 not being an integer, but I only see one that confirms it is a number (but that's not sufficient because all integers are also numbers).
There was a problem hiding this comment.
The "small and large float are integers" tests are not valid. You cannot make any assumptions about the architecture the tests are running on, and the expectation is that all integers, no matter the size, no matter whether they fit into the native integer size for your architecture, will still be treated as integers by JSON Schema.
| "description": "a small float whose non-zero fractional part is truncated in a binary64 float is an integer", | ||
| "data": 1.00000000000001, | ||
| "valid": true | ||
| }, | ||
| { | ||
| "description": "a large float whose non-zero fractional part is truncated in a binary64 float is an integer", | ||
| "data": 9007199254740991.5, | ||
| "valid": true | ||
| }, |
There was a problem hiding this comment.
@karenetheridge is correct. These are not integers. JSON Schema uses an object model based on the one defined by the JSON specification, RFC 8259, which does not put limits on numeric values. Range does not matter. See Core 6.2 and Validation 4.2.
We do already have some tests for extremely large numbers. They are in the optional folders as we recognize that they typically are not fully supported and are generally edge-case. An argument could be made that they should not be optional.
I certainly don't like all of these behaviors, but if we want truly consistent behavior across languages, we'll have to match the least-common-denominator behavior for JSON parsers (particularly ECMAScript's
JSON.parse()).