Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127895
Content-Type: multipart/signed;
	boundary="Apple-Mail=_F2D2A58E-016F-47AF-861C-7AC458ACFEE5";
	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:07:43 -0500
References: <CAEKnhAF3KOGcWZ6CYxpWkpZbNOGo79DD7p=WsAoJvqdJ5xG_Uw@mail.gmail.com>
To: PHP internals list <internals@lists.php.net>
In-Reply-To: <CAEKnhAF3KOGcWZ6CYxpWkpZbNOGo79DD7p=WsAoJvqdJ5xG_Uw@mail.gmail.com>
Message-ID: <9B2997E3-21C9-47D9-BB54-99C83A481ED8@php.net>
From: ramsey@php.net (Ben Ramsey)


--Apple-Mail=_F2D2A58E-016F-47AF-861C-7AC458ACFEE5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> 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


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).

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.

For the reference of others on the list, here=E2=80=99s what I mean by 9 =
versions and 11 I-Ds:

* 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

* Version: 2019-09
  - https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-02

* 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

* Version: draft-06
  - https://datatracker.ietf.org/doc/html/draft-wright-json-schema-01

* Version: draft-05
  - https://datatracker.ietf.org/doc/html/draft-wright-json-schema-00

* Version: draft-04
  - https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-04

* Version: draft-03
  - https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-03

* Version: draft-02
  - https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-02

* Version: draft-01
  - https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-01

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:

```
{
  "$schema": "https://json-schema.org/draft/2020-12/schema"
}
```

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.

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.

I think your RFC needs to address all these versions and how you plan to =
address compatibility issues between them all.

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.

Cheers,
Ben


--Apple-Mail=_F2D2A58E-016F-47AF-861C-7AC458ACFEE5
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-----

iHUEAREIAB0WIQToXQMR3fpbrPOmEOewLZeYnIwHGwUCaGhevwAKCRCwLZeYnIwH
G6UeAP0fVfC2egyJ+eiE40tbkNbd4HZedEdFHGDpWfXufJn1RgD+L3/k4pbUo94J
biGziGK0B8VJ9I01JB/98HBTaZULUF8=
=NotC
-----END PGP SIGNATURE-----

--Apple-Mail=_F2D2A58E-016F-47AF-861C-7AC458ACFEE5--