[Json] JSON Schema Language is nearly done

Ulysse Carion <ulysse@segment.com> Mon, 22 July 2019 03:37 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 BA2A412007C for <json@ietfa.amsl.com>; Sun, 21 Jul 2019 20:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 mf8SZoX7V8qs for <json@ietfa.amsl.com>; Sun, 21 Jul 2019 20:37:21 -0700 (PDT)
Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 55BCB120033 for <json@ietf.org>; Sun, 21 Jul 2019 20:37:21 -0700 (PDT)
Received: by mail-io1-xd42.google.com with SMTP id k20so70805221ios.10 for <json@ietf.org>; Sun, 21 Jul 2019 20:37:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=hD2/qB0K/uAQFGxVhLNIS3WlXzsDaq/3jDVc+xaPtRg=; b=TwJA8bP0RrhWQr+VA1RA27IBLmkyupag/fUiDqZxJwVm3VeQaugXjqW5/hCBaZ977K yYTkcybQFPVQr6gdsmaBO3SfP1ePHyi2VcMpidPaTx8B3HVc4GoFV2avWOO2PtjR0gls 5PYyEkYEkn1w9oHtKxUKwv7NnGA4714f8JEV8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hD2/qB0K/uAQFGxVhLNIS3WlXzsDaq/3jDVc+xaPtRg=; b=f+R2PBNz1MOY8zy8rRvBUXzCY78J7Czj9n3xeB0ITYKrsWcfUWuBr4eD93NLqkpYU7 70JDBuxySheRWGotv+UUB+8HwHxpKgUWDI2MblT+L8nKkaqLgEi+lUv1yLyHWLw+OTg3 tJ3lpoXwNrEchcIks3TLOHeRMUhfCRVtsK6fgfQzaKTyhEjy162MBfX/xfrkNZGfb87a t1TtgYbKWsAYDAw0H/R1kt653IPBOyjXnMh6XuDgIYwosfhZTu4xwREHphFT/In2m8Kh WELGt2ZPHi+Vs17BVK0oqrGEHzZTDEdepgTYd0+AZEr2i2cbZWN0p9mmj5/EzaKU24qq 1PZw==
X-Gm-Message-State: APjAAAW8zS1saUSagImPR5iAVucQg8z7eXIq5bHaIcBlFC3EWj+XY76e XzBtflJW0eMV7uF1rwS+m3hAzCqej0ybz+R/lKhGZoh2pxk=
X-Google-Smtp-Source: APXvYqy1Jzdz1c2uy+2ZjSXjGYzcorfJUw13VC67QcUcrXku8D9gHkYJS+3YQfQmBhXclGC1Vo3z8TtLd9o7HVqfxZU=
X-Received: by 2002:a6b:90c3:: with SMTP id s186mr64802496iod.114.1563766640440; Sun, 21 Jul 2019 20:37:20 -0700 (PDT)
MIME-Version: 1.0
From: Ulysse Carion <ulysse@segment.com>
Date: Sun, 21 Jul 2019 20:37:09 -0700
Message-ID: <CAJK=1RgmB89s=tZFHmVNZNR7TgHwmiQ+3js7wqME0zqRj4e-vg@mail.gmail.com>
To: JSON WG <json@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001dc87e058e3ccb74"
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/W5k7W204RrpErkQswys-FNeTKH4>
Subject: [Json] JSON Schema Language is nearly done
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: Mon, 22 Jul 2019 03:37:24 -0000

Hi all,

I've just submitted an I-D of JSON Schema Language:

https://tools.ietf.org/html/draft-json-schema-language-02

I believe this iteration is suited to be the penultimate draft; I see no
features in this spec worth adding, nor any features worth removing. I know
of a few minor problems with the language in the spec, and those issues are
tracked on GitHub here <https://github.com/json-schema-language/spec/issues>
.

In this draft, I introduced fine-grained numerical types -- "float32",
"float64", "int8", "uint64", etc. -- because they are immensely useful for
real-world code generation. The spec details these types here
<https://tools.ietf.org/html/draft-json-schema-language-02#section-3.3.3>
(Table 2). "float32" and "float64" have no effect on validation versus
"number", but they do signal intent, and act as a hint for code generators.

The question of JSON integers has been contentious in the past -- I
explicitly call out that 10.0 is considered a fine "int8". I did this out
of the robustness principle, and the fact that the alternative (considering
10.0 unacceptable) is one which fewer will be able to enforce. Some
implementations may in practice be more restrictive in what they accept
than the spec describes. I think that's acceptable; it seems clear that
either approach will lead to people deviating from the spec.

Let me know what y'all think about JSON Schema Language as a whole! If you
relish in the concrete, here are working implementations of validators
built on this iteration of JSON Schema Language:

https://github.com/json-schema-language/json-schema-language-go
https://github.com/json-schema-language/json-schema-language-typescript
https://github.com/json-schema-language/json-schema-language-rust

The GitHub org also contains tooling built on JSL, but they have not been
updated to support the fine-grained numerical types yet. I'll be working on
that soon.

I view JSL as being nearly complete, so any and all criticism is most
welcome.

Thanks,
Ulysse