On Thu, Mar 2, 2023 at 5:11 PM Larry Garfield <la...@garfieldtech.com> wrote:
> 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); > > The schema version should be specified by $schema keyword so I don't think we need multiple classes for that. We should probably default to the latest version (and maybe allow changing default using argument) if it is not present but it's not something that users should specify outside the schema if they control it so it seems better not to do it on the class level. Cheers Jakub
