Research valid values of multipleOf and its older variant divisibleBy across dialects

[jviotti]

No description provided.

[suprith-hub]

draft 2 - just says divisibeBy should be a number
draft 3 - specifies it should be non zero
from draft4 its strictly greater than 0
So, for draft 2 we can assume that it should be non-zero??
And for conversion from maxDecimal to divisibleBy, I am attaching this conversation:

So, will it be replacing maxDecimal: 2 with divisibleBy:0.01 and for 3 -> 0.001 and N -> 10power-N ?

[jviotti]

So, for draft 2 we can assume that it should be non-zero??

If the spec says it can be any number, then zero is also valid. Though keep in mind that no number is divisible by zero, so if they user set zero, they have an impossible schema that can be translated to false or { not: {} }

So, will it be replacing maxDecimal: 2 with divisibleBy:0.01 and for 3 -> 0.001 and N -> 10power-N ?

I believe so but please check with actual implementations that support the dialects in question, to confirm that you are indeed keeping the right semantics

[suprith-hub]

1. If implementations have implemented divisibleBy using actual division, then it will throw divideByZeroException. So, we have to convert maxDecimal:0 to divisibleBy: 1. I guess...
2. JSON Schema Lint supports maxDecimal. i.e, for maxDecimal:2 instance: 3.22 validates but 3.222 doesn't

[jviotti]

If implementations have implemented divisibleBy using actual division, then it will throw divideByZeroException. So, we have to convert maxDecimal:0 to divisibleBy: 1. I guess...

If so, that's an implementation error. A schema stating divisibleBy: 0 is likely a valid JSON Schema, just that it is impossible to satisfy (thus it is a "false" schema). Converting that to 1 doesn't sound right, as it would change the semantics of the schema (suddenly every numeric instance that is divisible by 1 succeeds). If you have a schema that cannot be satisfied, converting to an impossible { not: {} } is the most sensible thing we can do IMO.

[suprith-hub]

If implementations have implemented divisibleBy using actual division, then it will throw divideByZeroException. So, we have to convert maxDecimal:0 to divisibleBy: 1. I guess...

If so, that's an implementation error. A schema stating divisibleBy: 0 is likely a valid JSON Schema, just that it is impossible to satisfy (thus it is a "false" schema). Converting that to 1 doesn't sound right, as it would change the semantics of the schema (suddenly every numeric instance that is divisible by 1 succeeds). If you have a schema that cannot be satisfied, converting to an impossible { not: {} } is the most sensible thing we can do IMO.

Clarification for me on this again:
maxDecimal:0 will say no digits after the decimal point, also divisibleBy:1. So, I couldn't get how it violates the semantics. Shouldn't all numbers divisible by 1 be allowed for a number with no decimal..?

[jviotti]

Ah, I see what you mean now. Does maxDecimal: 0 essentially mean that the number has to be an integer? i.e. 1 would be allowed but 1.0 would not?

So, I couldn't get how it violates the semantics. Shouldn't all numbers divisible by 1 be allowed for a number with no decimal..

But every single number is divisible by 1, including real number. What would be the point of introducing divisibleBy: 1? It is a constraint that would always holds.

Maybe we should just convert maxDecimal: 0 to type: integer (or at least add integer to set of possible types)?

[suprith-hub]

Ah, I see what you mean now. Does maxDecimal: 0 essentially mean that the number has to be an integer? i.e. 1 would be allowed but 1.0 would not?

So, I couldn't get how it violates the semantics. Shouldn't all numbers divisible by 1 be allowed for a number with no decimal..

But every single number is divisible by 1, including real number. What would be the point of introducing divisibleBy: 1? It is a constraint that would always holds.

Maybe we should just convert maxDecimal: 0 to type: integer (or at least add integer to set of possible types)?

Yeah! perfect "integer" is a good choice. I see the reason why "multipleOf" was introduced.

[jviotti]

Sounds good. Please add/clarify that on our GitHub Project and close this issue when you have done so!