On Sat, Jul 5, 2025 at 1:29 AM Ben Ramsey <ram...@php.net> wrote: > 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. > > 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’t 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 require > 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
