On Thu, Mar 2, 2023 at 12:00 PM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> 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? > The plan is to support draft-04 and all later ones. So yeah you should be able to support both once they are implemented. I'm starting with draft-04 and will add others in the order they were created. > * 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? > > It would be a feature so the next minor. > 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? > > It's possible that we might decide to stop supporting some drafts if the maintenance burden is too big and usage small but I wouldn't see that as something that happens often. But essentially you are right that there will be minimum (draft-04 initially) and maximum (latest implemented draft). > 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. > > The changes are going to be first added to PECL jsond which will support PHP 7.2+ for some time. I will most likely keep it updated for later drafts additions so it could be still used for older versions of PHP. > 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. > > This might be quite technically challenging and also significantly impacting performance of parsing so I wouldn't see this happening - at least not initially. Regards Jakub
