Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119653
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-183-gbf7d00f500-fm-20230220.001-gbf7d00f5
Mime-Version: 1.0
Message-ID: <65dbe7f1-a6d0-4b06-833c-f1c579a2ca91@app.fastmail.com>
In-Reply-To: 
 <CAEKnhAGsAgNxfhGBLRU69HibaFYaeef4NsefxHYOQXyF2ZNSkw@mail.gmail.com>
References: 
 <CANMwmbMObQJD=bBncxXcHOgs1yoBfHXsTE1KZDYcSKMxMUUrRQ@mail.gmail.com>
 <CALKiJKpuDUJ6cyh8DdCFV2o740A3ua+H0nc3_qYHwCrrSdLkGg@mail.gmail.com>
 <CAEKnhAGsAgNxfhGBLRU69HibaFYaeef4NsefxHYOQXyF2ZNSkw@mail.gmail.com>
Date: Thu, 02 Mar 2023 11:10:40 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC Idea - json_validate() validate schema
From: larry@garfieldtech.com ("Larry Garfield")

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@g=
mail.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, s=
tring
>> > $json_schema =3D null): bool
>> >
>>
>>
>> Functionally, I think this is sounds great. My only concern is that J=
SON
>> Schema is a bit of a moving target. Unlike XSD, which has only ever h=
ad two
>> revisions, 10 years apart (1.0 from 2001, and 1.1 from 2012), JSON Sc=
hema
>> is in active development, with "Draft-07", "2019-09", and "2020-12" a=
ll
>> seeing deployment as stable releases, and work in progress on a new
>> version: https://github.com/json-schema-org/json-schema-spec/mileston=
e/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 draf=
t-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 specific=
ation?
>>
>>
> It would be a feature so the next minor.
>
>
>> I guess the combination of those leads to a third question: will supp=
ort
>> 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 t=
he
> 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 out=
side
>> of PHP's release cycle.
>>
>>
> The changes are going to be first added to PECL jsond which will suppo=
rt
> PHP 7.2+ for some time. I will most likely keep it updated for later d=
rafts
> 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 co=
re
>> mechanisms needed by the validator in core, but make them accessible =
to
>> libraries to implement specific specifications in an efficient way. T=
his is
>> the approach taken by the MongoDB PHP driver - there's a stable exten=
sion
>> providing efficient low-level routines, then a decoupled PHP library =
which
>> can be installed at the project level, and follow a much more agile r=
elease
>> 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);

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-provide=
d classes could of course share whatever underlying code makes sense for=
 them to share.

--Larry Garfield