Re: [Json] JSON Schema Language

Ulysse Carion <ulysse@segment.com> Tue, 07 May 2019 23:57 UTC

Return-Path: <ulysse@segment.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474F8120073 for <json@ietfa.amsl.com>; Tue, 7 May 2019 16:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A1fcPVZS22g for <json@ietfa.amsl.com>; Tue, 7 May 2019 16:57:14 -0700 (PDT)
Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13ED81200CD for <json@ietf.org>; Tue, 7 May 2019 16:57:14 -0700 (PDT)
Received: by mail-it1-x12c.google.com with SMTP id q14so1156277itk.0 for <json@ietf.org>; Tue, 07 May 2019 16:57:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iHymrwLZYkLiA2GP/XQV+rg29gJYzTqWBpfXWKloVmk=; b=ZoDzdVS3KClZ8lSRKHMtS2FuRGRpZy2dOUopps5+76Yk/5xfYeMwcqMpE9TpEfUPl6 oHqXdQISpLyN7e+aQFEdT0XeDevZiGl8rqWQ0W5yNOEbJXBebQG8ktkL297+k52H7+G/ hXBI1HOj6T8DuqSaRsnkIeRBErWW5Ro50NbJ4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iHymrwLZYkLiA2GP/XQV+rg29gJYzTqWBpfXWKloVmk=; b=WGMTtXlYWEQNn/w8Q35Nt6whO7AZe1i9mVsK35wqZk2Lr7wDi9WqsMI9dNJ7m4sSeY L+uFPnNDdiAmYj5GqnMOQqbOcbsEY0V6ug8e4WbnsModVnNzIQdcDTedOhW5lKT1INN5 CtkK8qkQ+rvE9VzVX5p5HKiF009nUuNtZ08b7Rc8Yd/yu9KfLnXPuO7qECuhkHHHA7oo JdBFZkLzRfiMGtGAMFgJdE+5RGQP/LR20aZqr69WQmO5vEgx6vjzN/V2bUD2OaYGZtiL 4PZZI7NW6jWENez+itMpIKNav4kEz1s3ZpOWdeXR90q9wZvQLT8KGgzu2/v3U0ppff0I XlyA==
X-Gm-Message-State: APjAAAWUAW0PEnrW6s/Ky+uqEfsBg5iwLMJgHR/5+vSkeMQo9hpgcQGW YWkkGCspHuBOoIjKYDMtu4GFMosc64/Q+NIJfx1Wbw==
X-Google-Smtp-Source: APXvYqzdiVAXM/zU0+HqyOz02zvQCJmh1mIjKq6whR355E97S5sDFPKOpW2jpDN8inRxv5dj5+k0WUxTIChgP/UjUNE=
X-Received: by 2002:a24:3ec6:: with SMTP id s189mr1091862its.138.1557273433124; Tue, 07 May 2019 16:57:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAJK=1RjV1uv0eOdtFZ8cKn-FfCwCiGP5r2hOz1UamiM6YV4H1A@mail.gmail.com> <CAHBU6itE8kub1qtdRoW8BqxaOmzMv=vUo1aDeuAr3HX141NUGg@mail.gmail.com> <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <CEF72901-5077-4305-BA68-60624DCE952D@bzfx.net> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <CAMm+LwjyVjnJuWE4+a9Ea=_X1uuEGuK+O4KojzN3uVQ+s+HqUQ@mail.gmail.com> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost>
In-Reply-To: <20190507221726.GR21049@localhost>
From: Ulysse Carion <ulysse@segment.com>
Date: Tue, 07 May 2019 16:57:01 -0700
Message-ID: <CAJK=1Rj7PBD-bbwvsqgjQQzp4Aoidb-W2q5Lj6asMHHDHaTVYQ@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Erik Wilde <erik.wilde@dret.net>, Anders Rundgren <anders.rundgren.net@gmail.com>, Austin Wright <aaa@bzfx.net>, Phillip Hallam-Baker <ietf@hallambaker.com>, Tim Bray <tbray@textuality.com>, JSON WG <json@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/KaoGn0MWR0Fq2_pvMoCS-4mgqLo>
Subject: Re: [Json] JSON Schema Language
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 May 2019 23:57:16 -0000

Hi all,

I'd like to offer a summary of what has been stated thus far, so as to
make a bit more sense of the conversation.

1. Considerable ink has been spilled on the question of integers in a
schema language. The main question has been how such an integral
constraint should relate to serialization.

2. Some have raised questions around the terseness of JSON Schema and
JSON Schema Language. Proposed alternatives are JCR and CDDL, by their
respective editors.

On the first question, I would agree with Messrs. Bormann and Bray,
who both suggest that a generic JSON parser runs first, followed by a
second pass over the data to convert the parsed data in the context of
a schema. On such a view, "3" and "3.0" are typically
indistinguishable by the time the schema is taken into account.
Bormann aptly notes that the alternative runs the risk of de facto
forking JSON itself. I don't think there is much more to be said on
the matter.

The second question is perhaps more interesting, although it has
provoked less discussion. I went with JSON as the representation
because it makes building tooling atop of JSON Schema Language much
easier, since it doesn't require that the implementor write a parser.
Such ease of extension is valuable: JSON is widespread largely because
of how easy it is to build atop of, and we should not readily
sacrifice this. JSON as the representation also unlocks syntax
highlighting, formatting, and other such niceties for free.
Furthermore, and most importantly, using JSON as a representation does
not preclude later creating a RELAX NG-style compact representation
later on.

I would also like to echo Bray's point about the real-world utility of
such a system. My day-job involves APIs, event-sourcing, and analytics
messages. In all three, JSON is the lingua franca, and in all three
considerable tedium is involved in writing and maintaining validators
and language-idiomatic containers for JSON messages. No
language-portable solution to this problem exists today, short of
moving away from JSON toward something like Protobufs or CBOR.

I'd like to return to the initial question of this thread, this time rephrased:

Are we in agreement that the question of describing JSON, and from
that description generating validators and idiomatic
classes/types/etc, is a problem worth solving?

Are we in agreement that something along the lines of the proposed I-D
may be a way we address this problem?

Best,
Ulysse

On Tue, May 7, 2019 at 3:17 PM Nico Williams <nico@cryptonector.com> wrote:
>
> On Tue, May 07, 2019 at 02:56:10PM -0700, Erik Wilde wrote:
> > On 2019-05-07 14:48, Phillip Hallam-Baker wrote:
> > >     at the risk of referring to XSD too much, but i think they got it right:
> > >
> > >     - constraining facets for constraining the value space.
> > >     - lexical facets for constraining the representation of values.
> > >
> > > I disagree on the constraining facets part. The only values I have found
> > > useful to put in a schema are 0 or 1 minimum occurrences and 1 or
> > > infinity maximum occurrences.
> >
> > there may be a misunderstanding here. constraining facets are limiting the
> > value space of datatypes, for example by defining minimum and maximum
> > values.
>
> As long as they don't constrain the encoding when multiple
> representations are available.
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json