is `1.0` an "integer"?

[awwright]

Right now, draft-04 says:

both are numbers, and have the same mathematical value; or

However, the test suite has this test: https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/develop/tests/draft4/optional/zeroTerminatedFloats.json

meaning that even though 1.0 is equal to 1, there still exists a keyword where one will validate and the other will not.

Should this be correct? I don't see any language in draft-04 for why this should be the case. I suggest remove this test, or flip the test result to "valid".

[Relequestual]

Discussion had over on spec issue: json-schema-org/json-schema-spec#79 (comment)

[awwright]

It appears we already had this discussion in #22, but we're re-evaluating this on new evidence that the spec says 1 is equal to 1.0 and therefore you'd expect the validation to be the same, too.

[Relequestual]

Looks like it's either changing the test, or removing the "mathmatically" similar clause.

[Julian]

(I've been pretty swamped the last 2 weeks, so apologies for long turnarounds on all these issues) -- but yeah that test was submitted by @fge, who authored the spec at the time, so I'm inclined to believe it's probably the correct interpretation. I can go back and read all the comments (and the spec) hopefully in the next day or two.

[seagreen]

@awwright: It looks to me like the spec says they SHOULD not be equal (admittedly a less severe requirement than MUST).

3.5:

integer
A JSON number without a fraction or exponent part.

5.5:

It is acknowledged by this specification that some programming languages, and their associated parsers, use different internal representations for floating point numbers and integers, while others do not.

As a consequence, for interoperability reasons, JSON values used in the context of JSON Schema, whether that JSON be a JSON Schema or an instance, SHOULD ensure that mathematical integers be represented as integers as defined by this specification.

EDIT: Links changed to go to draft 4 instead of latest.

[Relequestual]

Hum. That's a good argument. Maybe the "mathmatically the same" is meant to represent 1.0 and 1.0000 should be considered the same.

[seagreen]

I've looked into this a little more. 1 and 1.0 are definitely equal, because of 3.6 ("same mathematical value"). This matters for validators like "exclusiveMaximum" and "enum".

However, "type" validation is a different thing from equality. That's where my two citations above (3.5 and 5.5) come in, and that I'm still not sure about.

[awwright]

In the latest draft, there's no differentiation between "integer" and "number" as a primitive type anymore; and as of current master "integer" is simply defined as "any number with a zero fractional part".

Is there any reason this doesn't work?

The only reason I can think of that we want this, is for things like user IDs and serial numbers, where it makes little sense representing the number in a form like 12e4 (a shorter version of 120000).

But that is a parser-level concern, which JSON Schema specifically doesn't cover. Should that be reconsidered?

[seagreen]

@awwright: I think it's subjective.

According to the JSON specification, 100.0, 100, and 10e2 are all different sequences of characters. The specification sets a hilariously low bar for what constitutes a valid JSON parser or generator, so if a parser wanted to distinguish between 100 and 10e2 it's totally allowed to.

This sounds crazy, but might even have been a useful thing to do! 100 and 10e2 have different numbers of significant digits in scientific notation. It might have been cool to have kept that distinction in our JSON parsers and generators. I think we can all agree that ship has sailed though. I don't know of a single parser or generator that preserves a difference there.

Deciding whether we want to distinguish 100.0 and 100 is trickier. Some people may want to schema their JSON to allow only numbers without decimal points in certain places. Perhaps they want to make config files clearer to read, or are using the decimal point to decide the type to parse that particular JSON value to. On the other hand it will be be a pain for JSON Schema implementers -- writing a validator that distinguishes 100.0 from 100 is going to be tricky when the main JSON parser in your language interprets them both as double precision floats.

Further thoughts

For a quantity that's not divisible 1.0 looks and feels really wrong. At the same time the pragmatism advantage of not distinguishing them in JSON schema seems pretty big. I honestly don't know what's best here.

[awwright]

Assume for the moment we want to modify JSON Schema...

We could modify the "number" primitive to include two numeric values, "value" and "precision" or something. Then "integer" would be any number with a precision of exactly 1 (a.k.a. e0) -- leaving out 100.0 (precision of e-1) and 10e1 (precision of e+1) as options.

[awwright]

Actually, I like this idea -- an optional feature for parsers that do want to distinguish between precision. I think I'll file an enhancement for this. You may have stumbled across something, @seagreen

Edit: Filed json-schema-org/json-schema-spec#152

[awwright]

Filed json-schema-org/json-schema-spec#152

I think I'll close this, resolved with: The current definition (an integer is any number with a zero fractional part) suffices, and pretty much any other case can be handled by the new feature.