Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127898
Precedence: bulk
MIME-Version: 1.0
References: <CAEKnhAF3KOGcWZ6CYxpWkpZbNOGo79DD7p=WsAoJvqdJ5xG_Uw@mail.gmail.com>
 <9B2997E3-21C9-47D9-BB54-99C83A481ED8@php.net> <0BE9291A-A044-4660-AF80-AABE7C4B820A@php.net>
In-Reply-To: <0BE9291A-A044-4660-AF80-AABE7C4B820A@php.net>
Date: Sat, 5 Jul 2025 01:41:27 +0200
Message-ID: <CAEKnhAFLRVpbwZk9Q=gdzX-vHpSta3bOonxo2QfQLK6CxwmzNg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] JSON Schema validation support
To: Ben Ramsey <ramsey@php.net>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000003bf2e06392309e9"
From: bukka@php.net (Jakub Zelenka)

--00000000000003bf2e06392309e9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 5, 2025 at 1:29=E2=80=AFAM Ben Ramsey <ramsey@php.net> wrote:

> Another thing that needs to be addressed in the RFC is how error reportin=
g
> will work. I see this hinted at under Future Scope, but one of the benefi=
ts
> of the existing JSON Schema Composer packages is the robust level of erro=
r
> reporting they provide.
>
>
The error reporting is done using normal error codes and exceptions get
some sort of identification message. It doesn't collect multiple errors
with exact pointers to the place in the same way as the current JSON parser
doesn't do that - this is just how things are in the JSON extension and
this doesn't try to address all problems in one go - it basically needs
some extra parser context for this which is not there yet.


> 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.
>
>
Well you don't have to use it from the start. The reason for introduction
in this form is to mainly get something that we can build on. It is also
important to know that it makes sense to spend more time on it. It already
required lots of time to implement.

If we used the same standard on the json parser, we would never have json
extension in PHP because the error reporting does not provide complete info=
.


> 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 requi=
re
> support for parsing 2020-12 schemas.
>

None of the implementations started with support for all drafts from the
start. We will eventually support all but I don't see why that would have
to be done from the beginning.

Kind regards,

Jakub

--00000000000003bf2e06392309e9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, Jul 5, 2025 at 1:29=E2=80=AFAM Be=
n Ramsey &lt;<a href=3D"mailto:ramsey@php.net">ramsey@php.net</a>&gt; wrote=
:</div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
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.<br>
<br></blockquote><div><br></div><div>The error reporting is done using norm=
al error codes and exceptions get some sort of identification message. It d=
oesn&#39;t collect multiple errors with exact pointers to the place in the =
same way as the current JSON parser doesn&#39;t do that - this is just how =
things are in the JSON extension and this doesn&#39;t try to address all pr=
oblems in one go - it basically needs some extra parser context for this wh=
ich is not there yet.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
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 bui=
lt-in JSON Schema functionality until it has a certain level of error repor=
ting that goes well beyond simple `JSON_ERROR_SCHEMA_*` error codes.<br>
<br></blockquote><div><br></div><div>Well you don&#39;t have to use it from=
 the start. The reason for introduction in this form is to mainly get somet=
hing that we can build on. It is also important to know that it makes sense=
 to spend more time on it. It already required lots of time to implement.</=
div><div><br></div><div>If we used the same standard on the json parser, we=
 would never have json extension in PHP because the error reporting does no=
t provide complete info.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">
I see that the JSO C library supports JSON Schema validation for draft-04 a=
nd 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 su=
pport for parsing 2020-12 schemas.<br></blockquote><div><br></div><div>None=
 of the implementations started with support for all drafts from the start.=
 We will eventually support all but I don&#39;t see why that would have to =
be done from the beginning.</div><div><br></div><div>Kind regards,</div><di=
v><br></div><div>Jakub</div></div></div>

--00000000000003bf2e06392309e9--