> On Jul 4, 2025, at 18:07, Ben Ramsey <ram...@php.net> wrote: > >> On Jul 4, 2025, at 16:01, Jakub Zelenka <bu...@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
signature.asc
Description: Message signed with OpenPGP
