RFC Idea - json_validate() validate schema

On Wed, Mar 1, 2023 at 9:23 AM juan carlos morales <
dev.juan.morales@gmail.com> wrote:

Jakub, wow, great to know this. thanks for writting.

Ok, then .... I will assume that this feature will come from you
sometime in future.

Since json_validate() was announced ... I have being receiving
messages (a lot) about providing the ability to use JSON SCHEMAS as
well, hopefully we will have this in PHP in 8.4 (this will be a
shock!)

Question ... are you planning to incorporate this by enhancing
json_validate() ???

El mié, 1 mar 2023 a las 9:07, Jakub Zelenka (bukka@php.net) escribió:

On Wed, Mar 1, 2023 at 11:44 AM juan carlos morales <
dev.juan.morales@gmail.com> wrote:

Hello Internals.

I am thinking about improving the json_validate() function developed
for php 8.3.

The actual descriptions goes like this:

json_validate(string $json, int $depth = 512, int $flags = 0): bool

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 = 512, int $flags = 0, string
$json_schema = null): bool

so, if the string is a valid JSON and also respects the schema ... then
TRUE.

What do you think ?

I'm actually working on this. Currently developing the schema parsing in
pure C implementation in my play C tool called jso. You can see progress
here: https://github.com/bukka/jso/commits/next . The plan is to develop
it inside jso and then port it to jsond and then propose it for json ext
inclusion (that's how I developed the current parser). There is a lot of to
do as JsonSchema is quite complex (composition, JSON pointers, stream
integration for external pointers and more tricky bits) so this won't
likely be ready for 8.3 but should be ready for 8.4. I plan to introduce
some smaller things for 8.3 like better error reporting (error location
which I have already working in jso) and some other small additions. By the
way, the schema support won't be useful just for validation but also for
decoding and possibly encoding (sort of replacement for JsonSerializable).
Especially for decoding it can be further extended to allow class mapping.
We could also provide automatic generation of schema from class and support
attributes. I plan to propose all of this later as well but that might take
some time.

Regards

Jakub

--

To unsubscribe, visit: https://www.php.net/unsub.php

Great addition folks, looking forward to it!

If there is anything that I can do to help, please let me know!

--
Atenciosamente,

Flávio Heleno

Question ... are you planning to incorporate this by enhancing
json_validate() ???

Yes the plan is to initially enhance json_decode and json_validate that
would get a new $schema argument . I plan to create a class for the
actually schema as it needs to be parsed to its own representation so it is
convenient to have it in the object. It could be also later created from
the different sources than just JSON string (e.g. assoc array / stdClass or
automatic generation from the class that I mentioned before) so it will be
better to have it in the class.

Regards

Jakub

On Wed, Mar 1, 2023 at 11:44 AM juan carlos morales <
dev.juan.morales@gmail.com> wrote:

Hello Internals.

I am thinking about improving the json_validate() function developed
for php 8.3.

The actual descriptions goes like this:

json_validate(string $json, int $depth = 512, int $flags = 0): bool

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 = 512, int $flags = 0, string
$json_schema = null): bool

so, if the string is a valid JSON and also respects the schema ... then
TRUE.

What do you think ?

I'm actually working on this. Currently developing the schema parsing in
pure C implementation in my play C tool called jso. You can see progress
here: https://github.com/bukka/jso/commits/next . The plan is to develop it
inside jso and then port it to jsond and then propose it for json ext
inclusion (that's how I developed the current parser). There is a lot of to
do as JsonSchema is quite complex (composition, JSON pointers, stream
integration for external pointers and more tricky bits) so this won't
likely be ready for 8.3 but should be ready for 8.4. I plan to introduce
some smaller things for 8.3 like better error reporting (error location
which I have already working in jso) and some other small additions. By the
way, the schema support won't be useful just for validation but also for
decoding and possibly encoding (sort of replacement for JsonSerializable).
Especially for decoding it can be further extended to allow class mapping.
We could also provide automatic generation of schema from class and support
attributes. I plan to propose all of this later as well but that might take
some time.

Regards

Jakub

Ooo... This would be super userful, especially for some of the ideas I have floating about in the back of my head for new libraries. :-) I'm no help on the C implementation side but I'd be happy to collaborate on the user-space API design. That's something we'd want to get very-right the first time out, or else have just the primitives that allow us to do the not-slow bits in user-space. (Which will likely mean something more than just tacking an extra parameter onto json_validate().)

--Larry Garfield

--

To unsubscribe, visit: https://www.php.net/unsub.php

Hi internals,

wish one day we could have something as simple and
ubiquitous as Composer installing PHP extensions

When it comes to Docker containers and PHP, I've found
https://github.com/mlocati/docker-php-extension-installer to be
invaluable. I wish it were part of the official Docker image because
it is so incredibly painless. Usually, there's even support to apply
upstream patches and get extensions working in later versions of PHP
(for example, Memcached and PHP 8+) before they are officially
released.

On Wed, Mar 1, 2023 at 5:05 PM Larry Garfield larry@garfieldtech.com
wrote:

On Wed, Mar 1, 2023 at 11:44 AM juan carlos morales <
dev.juan.morales@gmail.com> wrote:

Hello Internals.

I am thinking about improving the json_validate() function developed
for php 8.3.

The actual descriptions goes like this:

json_validate(string $json, int $depth = 512, int $flags = 0): bool

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 = 512, int $flags = 0, string
$json_schema = null): bool

so, if the string is a valid JSON and also respects the schema ... then
TRUE.

What do you think ?

I'm actually working on this. Currently developing the schema parsing in
pure C implementation in my play C tool called jso. You can see progress
here: https://github.com/bukka/jso/commits/next . The plan is to
develop it
inside jso and then port it to jsond and then propose it for json ext
inclusion (that's how I developed the current parser). There is a lot of
to
do as JsonSchema is quite complex (composition, JSON pointers, stream
integration for external pointers and more tricky bits) so this won't
likely be ready for 8.3 but should be ready for 8.4. I plan to introduce
some smaller things for 8.3 like better error reporting (error location
which I have already working in jso) and some other small additions. By
the
way, the schema support won't be useful just for validation but also for
decoding and possibly encoding (sort of replacement for
JsonSerializable).
Especially for decoding it can be further extended to allow class
mapping.
We could also provide automatic generation of schema from class and
support
attributes. I plan to propose all of this later as well but that might
take
some time.

Regards

Jakub

Ooo... This would be super userful, especially for some of the ideas I
have floating about in the back of my head for new libraries. :-) I'm no
help on the C implementation side but I'd be happy to collaborate on the
user-space API design. That's something we'd want to get very-right the
first time out, or else have just the primitives that allow us to do the
not-slow bits in user-space. (Which will likely mean something more than
just tacking an extra parameter onto json_validate().)

Agreed that we'd want to get it right the first time out so help with the
API will be certainly appreciated. I will announce it here when I have got
some draft version and we can go from there.

Cheers

Jakub

On Thu, Mar 2, 2023 at 12:00 PM Rowan Tommins rowan.collins@gmail.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 = 512, int $flags = 0, string
$json_schema = null): bool

Functionally, I think this is sounds great. My only concern is that JSON
Schema is a bit of a moving target. Unlike XSD, which has only ever had two
revisions, 10 years apart (1.0 from 2001, and 1.1 from 2012), JSON Schema
is in active development, with "Draft-07", "2019-09", and "2020-12" all
seeing deployment as stable releases, and work in progress on a new
version: https://github.com/json-schema-org/json-schema-spec/milestone/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 draft-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 specification?

It would be a feature so the next minor.

I guess the combination of those leads to a third question: will support
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 the
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 outside
of PHP's release cycle.

The changes are going to be first added to PECL jsond which will support
PHP 7.2+ for some time. I will most likely keep it updated for later drafts
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 core
mechanisms needed by the validator in core, but make them accessible to
libraries to implement specific specifications in an efficient way. This is
the approach taken by the MongoDB PHP driver - there's a stable extension
providing efficient low-level routines, then a decoupled PHP library which
can be installed at the project level, and follow a much more agile release
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 = new JsonSchemaDraft4($schema_string);

$schema->validate($json_string): bool;

$otherSchema = 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-provided classes could of course share whatever underlying code makes sense for them to share.

--Larry Garfield

It's possible that we might decide to stop supporting some drafts if the
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).

Thinking about this, particularly if there is the ability to install a PECL
extension which supports different versions from the core PHP version,
perhaps it would be useful to expose a function or constant that lists the
supported versions, so that code needing a particular version could check
for support directly, rather than having to attempt and catch an exception?

I guess in Larry's suggestion, that use case would be filled by
class_exists('JsonSchema_2026_10")

Regards,

Rowan Tommins
[IMSoP]