Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127896
Content-Type: multipart/signed;
	boundary="Apple-Mail=_AED0A293-C600-4C69-A1A5-71FD7BCE0C13";
	protocol="application/pgp-signature";
	micalg=pgp-sha256
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
Subject: Re: [PHP-DEV] [RFC] JSON Schema validation support
Date: Fri, 4 Jul 2025 18:27:06 -0500
References: <CAEKnhAF3KOGcWZ6CYxpWkpZbNOGo79DD7p=WsAoJvqdJ5xG_Uw@mail.gmail.com>
 <9B2997E3-21C9-47D9-BB54-99C83A481ED8@php.net>
To: PHP internals list <internals@lists.php.net>
In-Reply-To: <9B2997E3-21C9-47D9-BB54-99C83A481ED8@php.net>
Message-ID: <0BE9291A-A044-4660-AF80-AABE7C4B820A@php.net>
From: ramsey@php.net (Ben Ramsey)


--Apple-Mail=_AED0A293-C600-4C69-A1A5-71FD7BCE0C13
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Jul 4, 2025, at 18:07, Ben Ramsey <ramsey@php.net> wrote:
>=20
>> On Jul 4, 2025, at 16:01, Jakub Zelenka <bukka@php.net> wrote:
>>=20
>> Hello,
>>=20
>> I would like introduce and open discussion for RFC proposing the =
addition of JSON Schema validation support to JSON extension:
>>=20
>> https://wiki.php.net/rfc/json_schema_validation
>>=20
>> If this is successful, it should be just the first for further =
improvements (see the future scope).
>>=20
>> Kind regards,
>>=20
>> Jakub
>=20
>=20
> There are 9 versions of JSON Schema and 11 Internet-Drafts, all of =
which have expired. Many of these versions are still widely used in the =
wild (draft-04, draft-05, and draft-06 come to mind as heavily used, =
despite several newer versions).
>=20
> Which version do you plan to target with this RFC, or will it be able =
to parse all versions, depending on what the input has specified in the =
`$schema` properties? I=E2=80=99ve even seen multiple schema versions =
used within the same set of referenced documents, and as long as the =
parser knows how to handle all versions, it will parse things just fine.
>=20
> For the reference of others on the list, here=E2=80=99s what I mean by =
9 versions and 11 I-Ds:
>=20
> * Version: 2020-12
>  - https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-01
>  - https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00
>=20
> * Version: 2019-09
>  - https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-02
>=20
> * Version: draft-07
>  - https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-01
>  - https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-00
>=20
> * Version: draft-06
>  - https://datatracker.ietf.org/doc/html/draft-wright-json-schema-01
>=20
> * Version: draft-05
>  - https://datatracker.ietf.org/doc/html/draft-wright-json-schema-00
>=20
> * Version: draft-04
>  - https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04
>=20
> * Version: draft-03
>  - https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-03
>=20
> * Version: draft-02
>  - https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-02
>=20
> * Version: draft-01
>  - https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-01
>=20
> Typically, when you create a JSON Schema document, you specify the =
`$schema` property, the value of which is a URI that refers to the =
schema version you=E2=80=99re using, like this:
>=20
> ```
> {
>  "$schema": "https://json-schema.org/draft/2020-12/schema"
> }
> ```
>=20
> This lets the parser know what =E2=80=9Cflavor=E2=80=9D of JSON Schema =
you=E2=80=99re using. The problem is that many parsers don=E2=80=99t =
understand all schema versions, and the most popular one in PHP =
(justinrainbow/json-schema =
<https://packagist.org/packages/justinrainbow/json-schema>) only =
supports draft-03 and draft-04, both well over 12 years old, at this =
point.
>=20
> Perhaps the JSON Schema library that is most robust and supports the =
latest versions is the opis/json-schema package =
<https://opis.io/json-schema/2.x/>. It supports draft-06, draft-07, =
2019-09, and 2020-12, which is pretty much all the newer ones that =
justinrainbow/json-schema doesn=E2=80=99t support.
>=20
> I think your RFC needs to address all these versions and how you plan =
to address compatibility issues between them all.
>=20
> Since all the I-Ds have expired without a formal IETF RFC being voted =
on and passing, you should probably call attention to the fact that JSON =
Schema, while not moving much right now, is still a moving target and =
any new versions will require updates to the core to support them.
>=20
> Cheers,
> Ben


Another thing that needs to be addressed in the RFC is how error =
reporting will work. I see this hinted at under Future Scope, but one of =
the benefits of the existing JSON Schema Composer packages is the robust =
level of error reporting they provide.

I think robust error reporting is base-level functionality and =
non-optional for a minimum viable feature. I won=E2=80=99t have a reason =
to use the built-in JSON Schema functionality until it has a certain =
level of error reporting that goes well beyond simple =
`JSON_ERROR_SCHEMA_*` error codes.

I see that the JSO C library supports JSON Schema validation for =
draft-04 and draft-06. IMO, you will need at least 2020-12 support, =
since this is the version that OpenAPI 3 has adopted, and any tooling =
for it will require support for parsing 2020-12 schemas.

Cheers,
Ben


--Apple-Mail=_AED0A293-C600-4C69-A1A5-71FD7BCE0C13
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iHUEAREIAB0WIQToXQMR3fpbrPOmEOewLZeYnIwHGwUCaGhjSgAKCRCwLZeYnIwH
G++2AP9U74ouO2gPDerm6WX04yo2GRjhAt3V1kY96BjQBBgoYAD/ebQiaw9HfaeA
5h2aqmoknYimOqODR50Fz6Po+dFY148=
=Ua3h
-----END PGP SIGNATURE-----

--Apple-Mail=_AED0A293-C600-4C69-A1A5-71FD7BCE0C13--