json-schema: Generated schema for Range numeric type breaks Draft 4

[en-sllupa]

API Platform version(s) affected: 3.2.7

Description
Generated JSON Schema for Range numbers changed from 3.2.6 to 3.2.7. The array copy previously was:

"position" => ArrayObject {#24994
    storage: array:4 [
    "minimum" => 0
    "exclusiveMinimum" => true
    "externalDocs" => array:1 [
        "url" => "https://schema.org/position"
    ]
    "type" => "integer"
    ]
    flag::STD_PROP_LIST: false
    flag::ARRAY_AS_PROPS: false
    iteratorClass: "ArrayIterator"
}

In 3.2.7 it is now:

"position" => ArrayObject {#5413
    storage: array:3 [
        "exclusiveMinimum" => 0
        "externalDocs" => array:1 [
            "url" => "https://schema.org/position"
        ]
        "type" => "integer"
    ]
    flag::STD_PROP_LIST: false
    flag::ARRAY_AS_PROPS: false
    iteratorClass: "ArrayIterator"
}

They are both right in their own way. Because in JSON-Schema docs under range you can read:

While you can specify both of minimum and exclusiveMinimum or both of maximum and exclusiveMaximum, it doesn't really make sense to do so.

There is also a Draft 4 specific interpretation:

In JSON Schema Draft 4, exclusiveMinimum and exclusiveMaximum work differently. There they are boolean values, that indicate whether minimum and maximum are exclusive of the value. For example:

if exclusiveMinimum is false, x ≥ minimum
if exclusiveMinimum is true, x > minimum.

This was changed to have better keyword independence.

The json-schema validator library used in API Platform only supports Draft 4, so any Range property now breaks schema assertions.

I am not sure if the team considers this a regression or not because I cannot find the reasoning for dropping Draft 4. Depending on this the fix can be different.

How to reproduce

In my case I have a $position property in my API Resource that has a Symfony\Component\Validator\Constraints\Positive attribute. If you have an API test case that validates response json schema, you can see how it fails between 3.2.6 and 3.2.7.

Possible Solution

• revert the change to drop Draft 4
• keep the change and open an issue over validator library

[soyuka]

It's quite hard as we want to be as up to date as possible but it's really hard to support many versions. We definitely need to propose an update to justinrainbow/json-schema!

[llupa]

I will report it and link these two together. I found the breaking change reference too between Draft 4 and 6.

PS: I am OP, I accidentally submitted this issue with my work account.

Edit: I am just going to try and open a PR for this specific issue of Draft 6 with Range numbers. I was browsing around the library for a bit and this issue was a bit demotivating. jsonrainbow/json-schema#699

Because nobody on this project has the time to implement it. It's basically on life support.

[llupa]

@soyuka I was thinking, if the checker lib does not respond, would submitting a oneOf work for API Platform? I can make it so it is one of Draft 4 or Draft 6?

If anyone has the same issue, for my project I eventually override the generated schema via attributes or some decorator service. I have to have the schema checks in place all the time and I want to update.

[soyuka]

indeed I think we should add some backward compatibility

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[llupa]

@soyuka sorry for the ping. This issue can be closed since #6098 has been merged. Eventually when json-schema merges the Draft 06 check, I will make another PR and drop the decorator.

Thanks!

[soyuka]

It looks like there are still some issues regarding schemas? I'm waiting for someone to come back with an update as 3.2.14 just came out

[llupa]

Ok! I was not sure if this was an oversight or not.

Also, I found it cool you mentioned 3.2.14 just minutes after this happened 😄 :