> On Jul 4, 2025, at 18:07, Ben Ramsey <ramsey@php.net> wrote:
>
>> On Jul 4, 2025, at 16:01, Jakub Zelenka <bukka@php.net> wrote:
>>
>> Hello,
>>
>> I would like introduce and open discussion for RFC proposing the addition of JSON Schema validation support to JSON extension:
>>
>> https://wiki.php.net/rfc/json_schema_validation
>>
>> If this is successful, it should be just the first for further improvements (see the future scope).
>>
>> Kind regards,
>>
>> Jakub
>
>
> There are 9 versions of JSON Schema and 11 Internet-Drafts, all of which have expired. Many of these versions are still widely used in the wild (draft-04, draft-05, and draft-06 come to mind as heavily used, despite several newer versions).
>
> Which version do you plan to target with this RFC, or will it be able to parse all versions, depending on what the input has specified in the `$schema` properties? I’ve even seen multiple schema versions used within the same set of referenced documents, and as long as the parser knows how to handle all versions, it will parse things just fine.
>
> For the reference of others on the list, here’s what I mean by 9 versions and 11 I-Ds:
>
> * Version: 2020-12
> - https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-01
> - https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00
>
> * Version: 2019-09
> - https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-02
>
> * Version: draft-07
> - https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-01
> - https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-00
>
> * Version: draft-06
> - https://datatracker.ietf.org/doc/html/draft-wright-json-schema-01
>
> * Version: draft-05
> - https://datatracker.ietf.org/doc/html/draft-wright-json-schema-00
>
> * Version: draft-04
> - https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04
>
> * Version: draft-03
> - https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-03
>
> * Version: draft-02
> - https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-02
>
> * Version: draft-01
> - https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-01
>
> Typically, when you create a JSON Schema document, you specify the `$schema` property, the value of which is a URI that refers to the schema version you’re using, like this:
>
> ```
> {
> "$schema": "https://json-schema.org/draft/2020-12/schema"
> }
> ```
>
> This lets the parser know what “flavor” of JSON Schema you’re using. The problem is that many parsers don’t understand all schema versions, and the most popular one in PHP (justinrainbow/json-schema <https://packagist.org/packages/justinrainbow/json-schema>) only supports draft-03 and draft-04, both well over 12 years old, at this point.
>
> Perhaps the JSON Schema library that is most robust and supports the latest versions is the opis/json-schema package <https://opis.io/json-schema/2.x/>. It supports draft-06, draft-07, 2019-09, and 2020-12, which is pretty much all the newer ones that justinrainbow/json-schema doesn’t support.
>
> I think your RFC needs to address all these versions and how you plan to address compatibility issues between them all.
>
> Since all the I-Ds have expired without a formal IETF RFC being voted on and passing, you should probably call attention to the fact that JSON Schema, while not moving much right now, is still a moving target and any new versions will require updates to the core to support them.
>
> Cheers,
> Ben
Another thing that needs to be addressed in the RFC is how error reporting will work. I see this hinted at under Future Scope, but one of the benefits of the existing JSON Schema Composer packages is the robust level of error reporting they provide.
I think robust error reporting is base-level functionality and non-optional for a minimum viable feature. I won’t have a reason to use the built-in JSON Schema functionality until it has a certain level of error reporting that goes well beyond simple `JSON_ERROR_SCHEMA_*` error codes.
I see that the JSO C library supports JSON Schema validation for draft-04 and draft-06. IMO, you will need at least 2020-12 support, since this is the version that OpenAPI 3 has adopted, and any tooling for it will require support for parsing 2020-12 schemas.
Cheers,
Ben
