is `1.0` an "integer"?

[awwright]

Right now, the JSON Schema Test Suite seems to test for the assertion that 1.0 does not validate against "type":"integer"

Right now, draft-04 says:

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

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?

[Relequestual]

I think we have to ask, what's the implication of saying this type should be an integer, and then trying to use that in say a Java application. (I don't know, and I'm going based on years old limited experience). Could it cause problems for some languages? OR should json-schema only focus on what is known within javascript, and other languges will have to work round issues (because every lanuges has its own issues).

[awwright]

I'm not really sure myself. I don't know if any parsers will render a difference if you supply 1.0 versus 1. According to JSON Schema, though, they're "equal". JSON Schema does need to answer some questions like this, and it does by saying "mathematically equal".

Do note that JSON doesn't make a distinction between integers and floats, it's literally the same thing in the ABNF.

[Relequestual]

I agree, mathmatically equal should be clear enough.
In which case, what do you mean when you say...

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

[awwright]

This test: https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/develop/tests/draft4/optional/zeroTerminatedFloats.json

Says that 1.0 should fail against type:"integer" even though it's equal to 1

[Relequestual]

OK.

As a broader question, would you expect existing libraries to implement your newer release of json-schema? if so, does the acceptance testing framework need a draft 5 set of tests? One specific change would be as you mention above.

[awwright]

The new draft is intended to be just a clarification and reverse-compatible, for the most part. There shouldn't really be anything to implement, unless they were implementing something incorrectly to begin with.

[Relequestual]

Right. So for this issue, a new part of the test suite should run the same test, but expect the opposite result. 1.0 should now pass against type integer because spec says mathmatically equal.

[awwright]

draft-04 says they're equal if they're mathematically the same.

And I don't see any language suggesting the extra trailing 0 should disqualify it from being an int.

So I think the test is wrong.

It seems like this is the behavior we want going forward, right? I suppose I'll open an issue to fix the test then

[Relequestual]

I'm happy to open the issue, but I expect you'll beat me to it =]