Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119654
MIME-Version: 1.0
References: <CANMwmbMObQJD=bBncxXcHOgs1yoBfHXsTE1KZDYcSKMxMUUrRQ@mail.gmail.com>
 <CALKiJKpuDUJ6cyh8DdCFV2o740A3ua+H0nc3_qYHwCrrSdLkGg@mail.gmail.com>
 <CAEKnhAGsAgNxfhGBLRU69HibaFYaeef4NsefxHYOQXyF2ZNSkw@mail.gmail.com> <65dbe7f1-a6d0-4b06-833c-f1c579a2ca91@app.fastmail.com>
In-Reply-To: <65dbe7f1-a6d0-4b06-833c-f1c579a2ca91@app.fastmail.com>
Date: Thu, 2 Mar 2023 17:23:07 +0000
Message-ID: <CAEKnhAFpN2uOKx-RcFWiV-hnYZ+ffQJtt-8kBBgJy=Tuw7DOSw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b532cb05f5ee150e"
Subject: Re: [PHP-DEV] RFC Idea - json_validate() validate schema
From: bukka@php.net (Jakub Zelenka)

--000000000000b532cb05f5ee150e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 2, 2023 at 5:11=E2=80=AFPM Larry Garfield <larry@garfieldtech.c=
om>
wrote:

> On Thu, Mar 2, 2023, at 6:34 AM, Jakub Zelenka wrote:
> > On Thu, Mar 2, 2023 at 12:00=E2=80=AFPM Rowan Tommins <rowan.collins@gm=
ail.com>
> > wrote:
> >
> >> On Wed, 1 Mar 2023 at 11:44, juan carlos morales <
> >> dev.juan.morales@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 =3D 512, int $flags =3D 0, st=
ring
> >> > $json_schema =3D null): bool
> >> >
> >>
> >>
> >> Functionally, I think this is sounds great. My only concern is that JS=
ON
> >> Schema is a bit of a moving target. Unlike XSD, which has only ever ha=
d
> 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" al=
l
> >> 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? I=
f
> 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 suppo=
rt
> >> 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 th=
e
> > maintenance burden is too big and usage small but I wouldn't see that a=
s
> > 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 i=
n
> 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 suppor=
t
> > 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 cor=
e
> >> mechanisms needed by the validator in core, but make them accessible t=
o
> >> 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 =3D new JsonSchemaDraft4($schema_string);
>
> $schema->validate($json_string): bool;
>
> $otherSchema =3D 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

--000000000000b532cb05f5ee150e--