Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119651 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 91613 invoked from network); 2 Mar 2023 12:34:25 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 2 Mar 2023 12:34:25 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 687B11804D7 for ; Thu, 2 Mar 2023 04:34:24 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 2 Mar 2023 04:34:24 -0800 (PST) Received: by mail-ed1-f46.google.com with SMTP id da10so67032814edb.3 for ; Thu, 02 Mar 2023 04:34:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nkewq636YjYw/IgSCWhVV/XmrMSQ4gIZaHzocnIwPWM=; b=W7jHz6M3pqDAtXEJ/8LgTJU1zPVJHteDoj9BBLkv/23ws6T58DxWvaky0MH9Pqzonf TfHbtpN/t0U5W6cFEe6FsdsLCJmCwTiy4FeA40hwaZO0/hNEMx0eZHtXpXnoQln8+RjD Jg5Ad5IzkK0VsZfdaYK0euNjZkWZBKVx6snEhG1GL2WOWc5dVYOb/zsPhr7GASaxLzz2 cw+xRF6C+QbwLWGfFkC1gbm1ndZTsjiHfwSJPzF3ELGf8jPT9dYLOXyQoj3QllWFbOk/ VKwMj3A0JBgb/okZyVrvA8ZWh8PLJA9iV8BnpS4SZ9bZlnyOFAh3EsH6kXiYfGgal8G9 02KQ== X-Gm-Message-State: AO0yUKV7GuEkUgPCXNCbSI6WGRncLOZk98zB6BOdkNua7n5ZPjMaOIiI bmio8cnkyCeR63K6M1T2/2GJQo8tH590iA2QO5aTpQYj X-Google-Smtp-Source: AK7set85l6lXbVQ94Zga6Znq7KBFCn9OboKai0qdOZ2+My6oVagDUVMFDD++sC1JVWXenpsh7/3z4GH0PiQkYg2UK5w= X-Received: by 2002:a17:906:aac1:b0:87b:fa21:7953 with SMTP id kt1-20020a170906aac100b0087bfa217953mr5251214ejb.8.1677760462602; Thu, 02 Mar 2023 04:34:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 2 Mar 2023 12:34:11 +0000 Message-ID: To: Rowan Tommins Cc: PHP Internals List Content-Type: multipart/alternative; boundary="0000000000006446a105f5ea0c59" Subject: Re: [PHP-DEV] RFC Idea - json_validate() validate schema From: bukka@php.net (Jakub Zelenka) --0000000000006446a105f5ea0c59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 2, 2023 at 12:00=E2=80=AFPM Rowan Tommins 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 =3D 512, int $flags =3D 0, strin= g > > $json_schema =3D 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 t= wo > 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, wil= l > 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 P= HP > 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 specificatio= n? > > 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 a= n > 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 whic= h > can be installed at the project level, and follow a much more agile relea= se > 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 --0000000000006446a105f5ea0c59--