Avoid language that seems to attempt to modify JSON parsing behavior

[handrews]

This discussion on the IETF JSON mailing list brought up that this language in §6.3 Mathematical Integers is problematic:

For consistency, integer JSON numbers SHOULD NOT be encoded with a fractional part.

It appears to impose a normative (SHOULD NOT) requirement on JSON parsers, which is not something we can do.

I think that the intent of this was to guide users of JSON Schema to write integers (both in JSON data and in JSON Schema keyword values) as 1 rather than 1.0, as doing so maximizes the chances that a JSON parser will store the value as an integer rather than a float in an environment that makes such distinctions.

[gregsdennis]

I'm not sure that this affects us. We still maintain the ability to treat 1.0 as an integer. Moreover, I think we should.

1. JSON doesn't explicitly disallow writing 1 as 1.0, which means people will do it, and we need to support the possibility.
2. Some parsers don't support the distinction. (I could do it in .Net, but it's not easy, and it would affect validation performance to check every number.)

[handrews]

@gregsdennis it seems I was unclear. None of this is about what JSON Schema does or does not support.

To some folks with deep experience with IETF specification language in general and the JSON RFC in particular, the language in question imposes a requirement on JSON parsers, which are governed by RFC 8259, not us. This interpretation depends on how one understands the word "encoding", but I'm going to take the JSON working group's reading as reasonable. Therefore, the language must be changed.

As far as how people write integers, it is entirely valid for a spec to recommend the most interoperable way to do so. This does not mean we can control what they do, we just tell them what is most likely to work in the broadest circumstances. Here is an example from the JSON RFC:

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

This doesn't mean that people can't use numbers outside of that range, or that they will never be interoperable. It just advises that numbers within that range will behave the same for all conforming implementations.

Similarly, it's possible that something or other (possibly not even a JSON parser since data might be put into the data model from a non-JSON source) might, for example, parse 1.0 into a C++ double, which if used with this implementation will fail validation against "type": "integer". That's the reason to recommend (but not enforce) such usage.

[gregsdennis]

So is the suggestion to make that text read more as setting an expectation for validators?

[handrews]

I honestly do not care. Someone should take out the problematic language, this is already more time than I care to spend on integer representation.

[gregsdennis]

This was done at some point, but I can find no record of when (I didn't search very hard).