On Thu, Mar 2, 2023, at 6:34 AM, Jakub Zelenka wrote: > 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
This may be a place where good OO design helps. Thinking aloud: $schema = new JsonSchemaDraft4($schema_string); $schema->validate($json_string): bool; $otherSchema = new JsonSchemaDraft5($other_schema); etc. If there's a common JasonSchema interface for them all, it would also be possible to polyfill the classes in user-space that way. The C-provided classes could of course share whatever underlying code makes sense for them to share. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
