On Wed, 1 Mar 2023 at 11:44, juan carlos morales <dev.juan.mora...@gmail.com> wrote:
> I am thinking about enhancing this function to also be able to > validate against a JSON SCHEMA, giving us something like this: > > json_validate(string $json, int $depth = 512, int $flags = 0, string > $json_schema = null): bool > Functionally, I think this is sounds great. My only concern is that JSON Schema is a bit of a moving target. Unlike XSD, which has only ever had two revisions, 10 years apart (1.0 from 2001, and 1.1 from 2012), JSON Schema is in active development, with "Draft-07", "2019-09", and "2020-12" all seeing deployment as stable releases, and work in progress on a new version: https://github.com/json-schema-org/json-schema-spec/milestone/7 That raises two questions: * Which existing version(s) of the specification will be implemented? For instance, if I have a schema written for 2019-09 rather than 2020-12, will I be able to use this validator? * How will new versions of the specification be added to the parser? If PHP 8.4 is release in November 2024, and JSON Schema 2025-01 is published two months later, will I need to wait for PHP 8.5 to use the new specification? I guess the combination of those leads to a third question: will support for some versions be *removed* in later PHP versions, so that each PHP version will have a minimum and maximum schema version it supports? That's the big disadvantage of anything shipped in core, rather than in an extension or library - there is no way to make even minor changes outside of PHP's release cycle. I wonder if there's some way this can be made pluggable - ship the core mechanisms needed by the validator in core, but make them accessible to libraries to implement specific specifications in an efficient way. This is the approach taken by the MongoDB PHP driver - there's a stable extension providing efficient low-level routines, then a decoupled PHP library which can be installed at the project level, and follow a much more agile release process. I'm not sure what it would look like in this case, but may be worth considering. Regards, -- Rowan Tommins [IMSoP]
