From nobody Mon Jul 1 01:20:31 2019 Return-Path: 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 CA950120026 for ; Mon, 1 Jul 2019 01:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1FuuOgQMuWtZ for ; Mon, 1 Jul 2019 01:20:27 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 492D712004E for ; Mon, 1 Jul 2019 01:20:27 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id e3so3169304wrs.11 for ; Mon, 01 Jul 2019 01:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=RNGjjtKA1VGE2a5uVdl8jvUz2AbFXq1tY0Qg0t9Kd7I=; b=fJMvdT7HbvE5ZggCZR2lEm+CsyeGv1HmbRCK8NP7UzrB8ZwOXh2WJV1/yCbHtoRWkk IAEQPW0HGMUBkDLx7X9xXnjIUxjK5Eu87gh8Rp0sw6egj7jhZ9h2C9bLLZG/vCGdx4Ni +6lpG5tdbusIafWRXXZ9HQAU1cQgO5fWMxS9ajIFIaWm4CpI4X84gjMEAcJOwkG9uvPm GXopeO53Icygy4NgsPBBGxLdZBHMpgd40UNTBgVdbUHQlSjoF7bhOn5DysGQc/p43v8n /I/OaekB6Ib83OkY6vns5tXto1XI382aVjQjPlxuh2zOWAEl98F5PFdaZ4luXa8nzRV1 kjVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RNGjjtKA1VGE2a5uVdl8jvUz2AbFXq1tY0Qg0t9Kd7I=; b=Iqeb18kF7MwstwvQBG2dCtURcwY4AnbhOf95qUGCsuEIrJo4lWzdt8Bt/x0z2FdXW+ SroZIv235qgJL0c+yptOTejwY0vhZixYQeD8GhnSb6lC1MtBHjDg7pWNyoI0rjvHz6VK vms5NjXvPY91s1OcNQVFhh65qMkxFn6WBL0LOhE3UpoS+EztIvf+S+xob+mwImQ15kQz +Y+ZKIWHw0kfUgBuP1cDK4l0goWwJdm3zgEjJFYw7iW0lEIWxD7fTorGi9Bh20wWC9rV q14luXDEfE7PgRg5Cgr/1GnbHIgaOmRQQcx1k8Ur5y0simFQJnkkq0N07xJ2ZAdvwuum p6LQ== X-Gm-Message-State: APjAAAU2awo1hAiP5eo3CO2urqli4p7kU2DJkzHvX0KmxJZXI+NB78Ci nigBgMY5B4UkTXh9bKAxBsJBY74UjPo= X-Google-Smtp-Source: APXvYqyv5z6LekFHVHLi0tx9ZkD67mMXdA8rUuS44sx13cAzXSA6Vvg1IlJbzZvAwDk7osTWHjccnw== X-Received: by 2002:adf:f483:: with SMTP id l3mr19194040wro.256.1561969225415; Mon, 01 Jul 2019 01:20:25 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id v4sm10745230wmg.22.2019.07.01.01.20.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jul 2019 01:20:24 -0700 (PDT) To: Ulysse Carion , JSON WG References: From: Anders Rundgren Message-ID: <7d7d39ef-c1cb-3648-b6df-222902d3391a@gmail.com> Date: Mon, 1 Jul 2019 10:20:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] JSON Schema Language, Draft 01 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 08:20:30 -0000 Hi Ulysse, Since you are asking for feedback... https://tools.ietf.org/html/draft-json-schema-language-01#section-3.3.3 "Type" The lack of support for common numeric types such as byte, int64, double etc. IMHO makes JCL fairly limited and unsuitable for code generation for languages like Java and C#. thanx, Anders On 2019-06-29 21:00, Ulysse Carion wrote: > Hi all, > > I wanted to provide an update on working tooling I've built on top of the latest draft of JSON Schema Language. I believe the ease with which such tooling can be written can be seen as an important reason why a minimal schema language for JSON is useful. > > I've made a code generator (jsl-codegen), a schema inference tool (jsl-infer), and a test data generator / fuzzer (jsl-fuzz). They're all open-source and available here: > > * https://github.com/json-schema-language/jsl-codegen > * https://github.com/json-schema-language/jsl-infer > * https://github.com/json-schema-language/jsl-fuzz > > The jsl-codegen tool supports Java, Golang, and TypeScript. It's similar to protoc in the gRPC world, or the OpenAPI code generator tools. > > The final tool, jsl-fuzz, is similar to the "json-generate" feature in the CDDL tool in: > > https://www.rfc-editor.org/rfc/rfc8610.html#appendix-F > > jsl-infer can be seen as the inverse of jsl-fuzz. > > The small size of the JSL spec means that making tooling like this is rather trivial. jsl-infer and jsl-fuzz are 350 and 150 LOC, respectively. > > I'm curious if folks have thoughts / criticisms on this tooling? > > Regards, > Ulysse > > On Thu, Jun 6, 2019 at 8:04 PM Ulysse Carion > wrote: > > Oh wait, another big change -- I got rid of the URI-based reference stuff. Thanks to Tim Bray for pointing out it's kind of needlessly complex. > > On Thu, Jun 6, 2019 at 5:18 PM Ulysse Carion > wrote: > > Hi folks, > > Working off discussion in this mailing list, I've published a draft -01 of JSON Schema Language: > > https://tools.ietf.org/html/draft-json-schema-language-01 > > Notable changes are the addition of "timestamp" (RFC3339) as a type, as well as the addition of enums. The syntax of JSL is now defined mostly through CDDL, and an informative appendix maps some JSL schemas to CDDL ones. The rest of the changes mostly serve to make the spec easier to read and implement, nothing dramatic. > > Would love feedback! What more should be removed or added to move this forward? > > Best, > Ulysse > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Sun Jul 21 20:37:24 2019 Return-Path: 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 ; 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 ; 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 ; Sun, 21 Jul 2019 20:37:21 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id k20so70805221ios.10 for ; 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 Date: Sun, 21 Jul 2019 20:37:09 -0700 Message-ID: To: JSON WG Content-Type: multipart/alternative; boundary="0000000000001dc87e058e3ccb74" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 03:37:24 -0000 --0000000000001dc87e058e3ccb74 Content-Type: text/plain; charset="UTF-8" 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 . 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 (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 --0000000000001dc87e058e3ccb74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I've just submit= ted an I-D of JSON Schema Language:


I belie= ve 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.

In this draft, I introduced fine-gra= ined numerical types -- "float32", "float64", "int= 8", "uint64", etc. -- because they are immensely useful for = real-world code generation. The spec details these types here = (Table 2). "float32" and "float64" have no effect on va= lidation versus "number", but they do signal intent, and act as a= hint for code generators.

The question of JSO= N integers has been contentious in the past -- I explicitly call out that 1= 0.0 is considered a fine "int8". I did this out of the robustness= principle, and the fact that the alternative (considering 10.0 unacceptabl= e) 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 kno= w 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 t= his iteration of JSON Schema Language:


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

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

Thanks,
Ulysse
--0000000000001dc87e058e3ccb74-- From nobody Mon Jul 22 04:37:19 2019 Return-Path: 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 5A50D1200C1 for ; Mon, 22 Jul 2019 04:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PjNVw4URf_8y for ; Mon, 22 Jul 2019 04:37:16 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F2512006F for ; Mon, 22 Jul 2019 04:37:16 -0700 (PDT) Received: from dhcp-9fb3.meeting.ietf.org (dhcp-9fb3.meeting.ietf.org [31.133.159.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45sfj5637hzyqT; Mon, 22 Jul 2019 13:37:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Mon, 22 Jul 2019 07:37:12 -0400 Cc: JSON WG X-Mao-Original-Outgoing-Id: 585488230.8613-d2ab86acdeecffd831e168f41a07f982 Content-Transfer-Encoding: quoted-printable Message-Id: <9405C824-3B7E-40D2-B6A7-61597E7845B6@tzi.org> References: To: Ulysse Carion X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 11:37:18 -0000 Thanks. At the hackathon, as part of the WISHI work on model = translation, I started a tool that can translate json-schema-org = definitions into CDDL. I probably won=E2=80=99t have time to complete = it this week, but I=E2=80=99ll sure add a translation function into CDDL = for JSL to the tool. Doing the inverse is more interesting (pretty much = pattern recognition), but I think it can (and should) be done as well. The exercise is useful in itself, but it also can be used to assess the = level of bizarreness of a data definition language. The translations in https://mailarchive.ietf.org/arch/msg/json/1WpdpfsXr3gEIdXb8OV0R_J-O4E demonstrated that the version of JSL we had at the time has a quite low = level of bizarreness, measured from the vantage point of CDDL. Gr=C3=BC=C3=9Fe, Carsten > On Jul 21, 2019, at 23:37, Ulysse Carion wrote: >=20 > Hi all, >=20 > I've just submitted an I-D of JSON Schema Language: >=20 > https://tools.ietf.org/html/draft-json-schema-language-02 >=20 > 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. >=20 > 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 (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. >=20 > 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. >=20 > 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: >=20 > 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 >=20 > 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. >=20 > I view JSL as being nearly complete, so any and all criticism is most = welcome. >=20 > Thanks, > Ulysse > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Tue Jul 23 21:08:09 2019 Return-Path: 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 84C271200B6 for ; Tue, 23 Jul 2019 21:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.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 KLBrpKTABLzB for ; Tue, 23 Jul 2019 21:08:04 -0700 (PDT) Received: from ipxdvo.tcif.telstra.com.au (ipxdvo.tcif.telstra.com.au [203.35.135.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DBE12008F for ; Tue, 23 Jul 2019 21:08:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,300,1559484000"; d="scan'208,217";a="170435457" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipodvi.tcif.telstra.com.au with ESMTP; 24 Jul 2019 14:08:01 +1000 Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbvi.tcif.telstra.com.au with ESMTP; 24 Jul 2019 14:08:00 +1000 Received: from wsapp5873.srv.dir.telstra.com (10.75.11.109) by wsmsg3706.srv.dir.telstra.com (172.49.40.80) with Microsoft SMTP Server (TLS) id 8.3.485.1; Wed, 24 Jul 2019 14:07:47 +1000 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5873.srv.dir.telstra.com (10.75.11.109) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 24 Jul 2019 14:07:46 +1000 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.101.126) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 24 Jul 2019 14:07:46 +1000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZyD90vKYW3ET73AYUWECQZMy0p8f12wWZE0G+Q4Ovtyk2bkqjqUBkGOs4i3vk3KS0S93puqTa8fp65rj+w15q1yEym0vyd+AYp54a9XnARt8vrjiiCzXcTJywZo+HHA/3nMt+MuNbnVQ3BSPD6ko6KUZ4nhy3s0BQJvdq4ba72VmTPkqIkELwc0VKaCSueB52zlfL53WRQBmG2uay1ARm/jFfOHker83XmLMxH4kilLc64uqf5KUWxG9M4oicr3WxbQp6JzFW18VTdUh3vl/TVAW1YFoiAfAho+8rsi6c8Nx1xbd+2DYaxkHfKb24YOGHLAHKuMKkPbyv8BW8aUSMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gpxN1nJ7EqRKF5biMpjnSbGF1Yjj2vbyBDs8yxYTnp4=; b=S//F1Ibdv/HTROk/56k7WLPcNXekephnbausRDgfNw27V39i2HnAP8WpxWnHR//GZBqOhD2iGD59c5k60nJ40h0vTbjbZn6Vc9y5c9pwQFmWwLJzd71yUsm2MJwa2eJXpXb7uIDBMPQZfh/gh/rAMP9B/ECYeR0B8i2Xo+paSdkrhO/LxuzxmXZcu5v9G0I8Z2yIgNgqJtpeLyVnO570/bRtphfrCvuUuMz38p2H9SvtSYITPAhwN8HBUXuq4j8xt9pW+75qsa0RzA3aGhhjy4mXRHsOYID3zazfyq3icWbXngDmJepPbldmG0Av9zss3QsQDyufory42lgrTos6FQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=team.telstra.com;dmarc=pass action=none header.from=team.telstra.com;dkim=pass header.d=team.telstra.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gpxN1nJ7EqRKF5biMpjnSbGF1Yjj2vbyBDs8yxYTnp4=; b=AEoi08zDQNX7WVBFOauNC8HBBlGscU1isEWaN0PlCZOOQnFypdJAg0hZE69CGVGgRd2AZdwFpCbVvVAJdDQpSZehWTemy2Ta4HinHFxj/bGolu2sT/omWNXShloV3qRMs6Z58DknH3IVZF37OBDuOeEAJ6n7ziB8Mv4+Y3J66FM= Received: from SY2PR01MB2764.ausprd01.prod.outlook.com (52.134.190.138) by SY2PR01MB2457.ausprd01.prod.outlook.com (52.134.187.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Wed, 24 Jul 2019 04:07:46 +0000 Received: from SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::a080:9084:3e2f:68ab]) by SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::a080:9084:3e2f:68ab%4]) with mapi id 15.20.2094.013; Wed, 24 Jul 2019 04:07:46 +0000 From: "Manger, James" To: Ulysse Carion , JSON WG Thread-Topic: [Json] JSON Schema Language is nearly done Thread-Index: AQHVQD7nFMS5gbkqY0aU295wfEYotqbZHX0w Date: Wed, 24 Jul 2019 04:07:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.35.9.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0815a025-527a-47a1-18fd-08d70fec7beb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SY2PR01MB2457; x-ms-traffictypediagnostic: SY2PR01MB2457: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39850400004)(366004)(136003)(376002)(346002)(199004)(189003)(99286004)(6246003)(186003)(478600001)(26005)(66066001)(6506007)(86362001)(81166006)(81156014)(6306002)(66446008)(53936002)(66476007)(8676002)(9686003)(76116006)(446003)(486006)(66946007)(102836004)(54896002)(14454004)(71190400001)(71200400001)(64756008)(66556008)(11346002)(55016002)(3846002)(2906002)(256004)(316002)(110136005)(476003)(6436002)(25786009)(5660300002)(52536014)(76176011)(8936002)(68736007)(790700001)(33656002)(229853002)(7696005)(6116002)(7736002)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:SY2PR01MB2457; H:SY2PR01MB2764.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pPXOWQVygrIqHmIkV5/WRo4ZGv12RfMDTNgs9SBbHEEnAcEGLxI9+lRfTvMPk9rWtfGm7EcdhMQpRTTohEs5Ezh/M/IxJ/xweS8+UG/PUNTNTiSm9jl4U/RrxuQ7rM9P0Nqm9wxWj+KJUM5wg5HzImlG5cFWqvgjX7YJwh/PMjRzWpycPLB2dyVmrj0GruNUnS5ixXhfqi8TryAQRusSgyS5Wa6NV11cXb+k6/vH3hwg3/bu+CbssGZgOHfnObobdzQc9awtvEoU3I+vdQdplANArzgJJbJKiz54MBRSWUFZDDsMBs3VeHfuI3sS6i9MddkfgpUHZcbZamgDvZ3/N9E6S/o4VWpSk9AgskAAGQCDCZLqtyUf6GPrO2CTm87SRXOTAf5jLHwV4iq1CZVUPkyKJMMeuwdfqLzq873VWwo= Content-Type: multipart/alternative; boundary="_000_SY2PR01MB2764901C1F73A86581D7870AE5C60SY2PR01MB2764ausp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0815a025-527a-47a1-18fd-08d70fec7beb X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 04:07:46.0558 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: James.H.Manger@team.telstra.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY2PR01MB2457 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 04:08:08 -0000 --_000_SY2PR01MB2764901C1F73A86581D7870AE5C60SY2PR01MB2764ausp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJbiB0aGlzIGRyYWZ0LCBJIGludHJvZHVjZWQgZmluZS1ncmFpbmVkIG51bWVyaWNhbCB0eXBl cyAtLSAiZmxvYXQzMiIsICJmbG9hdDY0IiwgImludDgiLCAidWludDY0IiwgZXRjLiAtLSBiZWNh dXNlIHRoZXkgYXJlIGltbWVuc2VseSB1c2VmdWwgZm9yIHJlYWwtd29ybGQgY29kZSBnZW5lcmF0 aW9uLg0KDQpNaWdodCBiZSBtb3JlIHVzZWZ1bCB0byBoYXZlIGludDUzLiBUaGF0IGVuY291cmFn ZXMgZGVzaWduZXJzIHRvIHVzZSBpbnRlZ2VycyB0aGF0IGludGVyb3AgbmljZWx5IHdpdGggSS1K U09OLCBFQ01BU2NyaXB0IGV0Yy4NCg0KPiBJIGV4cGxpY2l0bHkgY2FsbCBvdXQgdGhhdCAxMC4w IGlzIGNvbnNpZGVyZWQgYSBmaW5lICJpbnQ4Ii4NCg0KU2hvdWxkIGFsc28gY2FsbCBvdXQgdGhh dCAxLjAwZTEgaXMgY29uc2lkZXJlZCBhIGZpbmUg4oCcaW50OOKAnS4NCg0KaW50NjQvdWludDY0 IGFyZSBkZWZpbmVkIGluIDMuMy4zLiDigJxUeXBl4oCdIGFuZCB0YWJsZSAyLCBidXQgbm90IGlu Y2x1ZGVkIGluIG51bV90eXBlICgyIOKAnFN5bnRheOKAnSkuIEnigJlkIGRyb3AgaW50NjQvdWlu dDY0IHRvdGFsbHkgZHVlIHRvIHRoZSBpbnRlcm9wIHByb2JsZW1zLiBTb21lIEpTT04gdG9vbHMg c3RhcnQgc2VuZGluZyBpbnRlZ2VycyBhcyBzdHJpbmdzIGlmIHRoZXkgYXJlIGFib3ZlIDJeNTMu DQoNCg0K4oCccmVm4oCdIG9ubHkgcmVmZXJyaW5nIHRvIGRlZmluaXRpb25zIGF0IHRoZSBfcm9v dF8gbGV2ZWwgc2VlbXMgdW5oZWxwZnVsbHkgcmVzdHJpY3RpdmUuIEl0IGRvZXNu4oCZdCBzZWVt IHRvIHBsYXkgbmljZWx5IHdpdGggdGhlIGdvYWwgb2YgYmVpbmcgYWJsZSB0byBlbWJlZCB0aGUg c2NoZW1hIGluIG90aGVyIEpTT04gZG9jcy4gSXQgZG9lc27igJl0IHdvcmsgd2VsbCB3aXRoIHRo ZSByZWN1cnNpdmUgbmF0dXJlIG9mIHNjaGVtYSAoZWcgYSBzY2hlbWEgZm9yIGFuIG9iamVjdCB3 aXRoLCBzYXksIDIgcHJvcGVydGllcyBuZWVkaW5nIDIgb3RoZXIgc2NoZW1hcyBmb3IgdGhlIGFs bG93ZWQgdmFsdWVzIG9mIHRob3NlIHByb3BlcnRpZXMpLiBXb3VsZCBhIGJldHRlciBydWxlIGJl IHRoYXQgYSBkZWZpbml0aW9uIG11c3QgYXBwZWFyIGFsb25nIHRoZSBwYXRoIGZyb20gdGhlIF9y b290XyB0byB0aGUg4oCccmVm4oCdOyB0aGF0IGlzLCBhIGRlZmluaXRpb24gbXVzdCBiZSDigJxh Ym92ZeKAnSBhIOKAnHJlZuKAnS4NCg0KDQo+IEkgc2VlIG5vIGZlYXR1cmVzIGluIHRoaXMgc3Bl YyB3b3J0aCBhZGRpbmcNCg0KQSBzaWduaWZpY2FudCBtaXNzaW5nIGZlYXR1cmUgaXMgYSBjaG9p Y2Ugb2YgdHlwZXMuIEZvciBpbnN0YW5jZSwgYSBmaWVsZCBjYW4gYmUgYW4gYXJyYXkgb2Ygc3Ry aW5ncyBvciBqdXN0IGEgc3RyaW5nOyBhIGZpZWxkIGNhbiBiZSBhbiBudW1iZXIgb3IgYSBudW1i ZXIgaW4gcXVvdGVzIChpZSBhIHN0cmluZykuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== --_000_SY2PR01MB2764901C1F73A86581D7870AE5C60SY2PR01MB2764ausp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUFVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEluIHRo aXMgZHJhZnQsIEkgaW50cm9kdWNlZCBmaW5lLWdyYWluZWQgbnVtZXJpY2FsIHR5cGVzIC0tICZx dW90O2Zsb2F0MzImcXVvdDssICZxdW90O2Zsb2F0NjQmcXVvdDssICZxdW90O2ludDgmcXVvdDss ICZxdW90O3VpbnQ2NCZxdW90OywgZXRjLiAtLSBiZWNhdXNlIHRoZXkgYXJlIGltbWVuc2VseSB1 c2VmdWwgZm9yIHJlYWwtd29ybGQgY29kZSBnZW5lcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5NaWdodCBiZSBtb3JlIHVzZWZ1bCB0byBoYXZlIGludDUzLiBUaGF0IGVuY291cmFnZXMg ZGVzaWduZXJzIHRvIHVzZSBpbnRlZ2VycyB0aGF0IGludGVyb3AgbmljZWx5IHdpdGggSS1KU09O LCBFQ01BU2NyaXB0IGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSSBl eHBsaWNpdGx5IGNhbGwgb3V0IHRoYXQgMTAuMCBpcyBjb25zaWRlcmVkIGEgZmluZSAmcXVvdDtp bnQ4JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG91bGQgYWxzbyBjYWxsIG91dCB0 aGF0IDEuMDBlMSBpcyBjb25zaWRlcmVkIGEgZmluZSDigJxpbnQ44oCdLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5pbnQ2NC91aW50NjQgYXJlIGRlZmluZWQgaW4gMy4zLjMuIOKAnFR5cGXigJ0g YW5kIHRhYmxlIDIsIGJ1dCBub3QgaW5jbHVkZWQgaW4gbnVtX3R5cGUgKDIg4oCcU3ludGF44oCd KS4gSeKAmWQgZHJvcCBpbnQ2NC91aW50NjQgdG90YWxseSBkdWUgdG8gdGhlIGludGVyb3AgcHJv YmxlbXMuIFNvbWUgSlNPTiB0b29scyBzdGFydCBzZW5kaW5nIGludGVnZXJzIGFzIHN0cmluZ3Mg aWYgdGhleSBhcmUgYWJvdmUgMl41My48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxyZWbigJ0gb25seSByZWZlcnJp bmcgdG8gZGVmaW5pdGlvbnMgYXQgdGhlIF9yb290XyBsZXZlbCBzZWVtcyB1bmhlbHBmdWxseSBy ZXN0cmljdGl2ZS4gSXQgZG9lc27igJl0IHNlZW0gdG8gcGxheSBuaWNlbHkgd2l0aCB0aGUgZ29h bCBvZiBiZWluZyBhYmxlIHRvIGVtYmVkIHRoZSBzY2hlbWEgaW4gb3RoZXIgSlNPTiBkb2NzLiBJ dCBkb2VzbuKAmXQgd29yayB3ZWxsIHdpdGggdGhlIHJlY3Vyc2l2ZSBuYXR1cmUgb2YNCiBzY2hl bWEgKGVnIGEgc2NoZW1hIGZvciBhbiBvYmplY3Qgd2l0aCwgc2F5LCAyIHByb3BlcnRpZXMgbmVl ZGluZyAyIG90aGVyIHNjaGVtYXMgZm9yIHRoZSBhbGxvd2VkIHZhbHVlcyBvZiB0aG9zZSBwcm9w ZXJ0aWVzKS4gV291bGQgYSBiZXR0ZXIgcnVsZSBiZSB0aGF0IGEgZGVmaW5pdGlvbiBtdXN0IGFw cGVhciBhbG9uZyB0aGUgcGF0aCBmcm9tIHRoZSBfcm9vdF8gdG8gdGhlIOKAnHJlZuKAnTsgdGhh dCBpcywgYSBkZWZpbml0aW9uIG11c3QgYmUg4oCcYWJvdmXigJ0NCiBhIOKAnHJlZuKAnS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7IEkgc2VlIG5vIGZlYXR1cmVzIGluIHRoaXMgc3BlYyB3b3J0aCBhZGRpbmc8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBzaWduaWZpY2FudCBtaXNzaW5nIGZlYXR1cmUgaXMg YSBjaG9pY2Ugb2YgdHlwZXMuIEZvciBpbnN0YW5jZSwgYSBmaWVsZCBjYW4gYmUgYW4gYXJyYXkg b2Ygc3RyaW5ncyBvciBqdXN0IGEgc3RyaW5nOyBhIGZpZWxkIGNhbiBiZSBhbiBudW1iZXIgb3Ig YSBudW1iZXIgaW4gcXVvdGVzIChpZSBhIHN0cmluZykuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KYW1lcyBNYW5nZXI8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SY2PR01MB2764901C1F73A86581D7870AE5C60SY2PR01MB2764ausp_-- From nobody Wed Jul 24 11:59:45 2019 Return-Path: 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 C04991203B5 for ; Wed, 24 Jul 2019 11:59:42 -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 SPcuhQwp1RrS for ; Wed, 24 Jul 2019 11:59:40 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 11D431203A5 for ; Wed, 24 Jul 2019 11:59:40 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id h6so5302193iom.7 for ; Wed, 24 Jul 2019 11:59:40 -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=tcA57ahVnkfnGx+MIljvWBPMtJqIIutc9Jm95BwER28=; b=F1cjFqSXuoThvwqKCo38j24lc2281M9ukZZg1QAcxHwOwjvruQS3SzqClJhq07Wyms mco4yIyIgP7ByX2pFB/NcbK5zAUsp2nChJs7jcR2dlLYG/KKIYDlh5qninPp5Lp/PfU/ KskDu7aKD1E1AILXUkz14ORe4465YXUwSoZ8w= 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=tcA57ahVnkfnGx+MIljvWBPMtJqIIutc9Jm95BwER28=; b=kaQGUVkq8Lex2+dvP1PN3kIbl6rPOESJTrTgyVdOfieDw3Pvpao1WPmjlUHaFoiOoP W0yIHTfKtUdoVFrJMbor9WdNhIHBzeUgQ1En//dm47oT6cfqIuAA6ZZF56yMmrr9BuZy pK9IjFf+yl+5LnTVVSgbD5RAo8UeIQ1uJP6DMQRQj2sNoVj9YeQKJBLvkuo5hgI6+jNo RlenqbLNMCecCvC6TpOTiJJsMZpW8U9a9Ol4j9N3DbUzgWxQAUlggV5Ho1wzvf9t35ao uzdbmuvzwHhXpwunNi6FL3fjImsxxVU2WqkZOEyJMcVvMuVUoA/p6OzP7R9GP4q9Ef/t ydPA== X-Gm-Message-State: APjAAAWRoZpxYQCLm2ZudTOj23QH+fGHAAC3ZVDa34+wnRySgWI295A7 l6OU6qbVf/bHindDzmiQrIQ1N6kGYoYkFOMKUeNFtA== X-Google-Smtp-Source: APXvYqzS4Poze4CBLnJcrMiSAmiOsYvFUAjikjaHXxPnizMoCGbVnSEJwhPrPVGSGe9yA2CRueENd0N3lT2+Bh0w1vs= X-Received: by 2002:a5d:96d8:: with SMTP id r24mr15813802iol.269.1563994779188; Wed, 24 Jul 2019 11:59:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulysse Carion Date: Wed, 24 Jul 2019 11:59:28 -0700 Message-ID: To: "Manger, James" Cc: JSON WG Content-Type: multipart/alternative; boundary="0000000000003eed37058e71e949" Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 18:59:43 -0000 --0000000000003eed37058e71e949 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Should also call out that 1.00e1 is considered a fine =E2=80=9Cint8=E2=80= =9D. This is a great point. I'll fix this in the next draft. On your points regarding numbers beyond 2^53/int53, do you feel that the warning about I-JSON is insufficient? Many systems using JSON aren't concerned about JavaScript, and for these systems being able to use integers beyond 2^32 is useful. 64-bit integers is the idiomatic way to represent these types, and so that's why I added those to the spec. > =E2=80=9Cref=E2=80=9D only referring to definitions at the _root_ level s= eems unhelpfully restrictive. It doesn=E2=80=99t seem to play nicely with the goal of being = able to embed the schema in other JSON docs. It doesn=E2=80=99t work well with the recursive nature of schema (eg a schema for an object with, say, 2 properties needing 2 other schemas for the allowed values of those properties). Would a better rule be that a definition must appear along the path from the _root_ to the =E2=80=9Cref=E2=80=9D; that is, a definition mu= st be =E2=80=9Cabove=E2=80=9D a =E2=80=9Cref=E2=80=9D. This is a good point. I started with the design you propose, but moved away from it because it complicates code generation, requiring code generators to implement some sort of name mangling. The generated code is likely to be less useful as a result. Furthermore, it introduces annoying subtleties, such as clarifying whether a "definitions" appearing within "discriminator" (i.e, appearing as a sibling of "tag" and "mapping", see https://tools.ietf.org/html/draft-json-schema-language-02#section-3.3.8) counts or not. But perhaps I'm overestimating the difficulty here? Put another way: by saying "definitions only matter at the root", a large class of ambiguity goes away. It immediately becomes clearer exactly how JSL works in detail. That struck me as a good property. As you point out, this does have the consequence that it becomes more difficult to embed a JSL schema within a broader one, since all of its definitions have to be moved to the top level. Tooling can help here, but I agree this is a design decision with shortcomings. > A significant missing feature is a choice of types. For instance, a field can be an array of strings or just a string; a field can be an number or a number in quotes (ie a string). This is intentionally left out. It's difficult to portably code-generate for this case. Instead, I was thinking users would either use an empty schema for this case (essentially marking the data as "any"), or use a discriminator. Does that strike you as good enough? On Tue, Jul 23, 2019 at 9:08 PM Manger, James < James.H.Manger@team.telstra.com> wrote: > > In this draft, I introduced fine-grained numerical types -- "float32", > "float64", "int8", "uint64", etc. -- because they are immensely useful fo= r > real-world code generation. > > > > Might be more useful to have int53. That encourages designers to use > integers that interop nicely with I-JSON, ECMAScript etc. > > > > > I explicitly call out that 10.0 is considered a fine "int8". > > > > Should also call out that 1.00e1 is considered a fine =E2=80=9Cint8=E2=80= =9D. > > > > int64/uint64 are defined in 3.3.3. =E2=80=9CType=E2=80=9D and table 2, bu= t not included in > num_type (2 =E2=80=9CSyntax=E2=80=9D). I=E2=80=99d drop int64/uint64 tota= lly due to the interop > problems. Some JSON tools start sending integers as strings if they are > above 2^53. > > > > > > =E2=80=9Cref=E2=80=9D only referring to definitions at the _root_ level s= eems unhelpfully > restrictive. It doesn=E2=80=99t seem to play nicely with the goal of bein= g able to > embed the schema in other JSON docs. It doesn=E2=80=99t work well with th= e > recursive nature of schema (eg a schema for an object with, say, 2 > properties needing 2 other schemas for the allowed values of those > properties). Would a better rule be that a definition must appear along t= he > path from the _root_ to the =E2=80=9Cref=E2=80=9D; that is, a definition = must be =E2=80=9Cabove=E2=80=9D a > =E2=80=9Cref=E2=80=9D. > > > > > > > I see no features in this spec worth adding > > > > A significant missing feature is a choice of types. For instance, a field > can be an array of strings or just a string; a field can be an number or = a > number in quotes (ie a string). > > > > -- > > James Manger > --0000000000003eed37058e71e949 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Should also call out that 1.00e1 is considered a= fine =E2=80=9Cint8=E2=80=9D.

This is a great = point. I'll fix this in the next draft.

On you= r points regarding numbers beyond 2^53/int53, do you feel that the warning = about I-JSON is insufficient? Many systems using JSON aren't concerned = about JavaScript, and for these systems being able to use integers beyond 2= ^32 is useful. 64-bit integers is the idiomatic way to represent these type= s, and so that's why I added those to the spec.

> =E2=80=9Cref=E2=80=9D only referring to definitions at the _root= _=20 level seems unhelpfully restrictive. It doesn=E2=80=99t seem to play nicely= with the goal of being able to embed the schema in other JSON docs. It=20 doesn=E2=80=99t work well with the recursive nature of schema (eg a schema for an object with, say, 2 properties needing 2=20 other schemas for the allowed values of those properties). Would a=20 better rule be that a definition must appear along the path from the=20 _root_ to the =E2=80=9Cref=E2=80=9D; that is, a definition must be =E2=80= =9Cabove=E2=80=9D a =E2=80=9Cref=E2=80=9D.

This is a good point. I = started with the design you propose, but moved away from it because it comp= licates code generation, requiring code generators to implement some sort o= f name mangling. The generated code is likely to be less useful as a result= . Furthermore, it introduces annoying subtleties, such as clarifying whethe= r a "definitions" appearing within "discriminator" (i.e= , appearing as a sibling of "tag" and "mapping", see https://tools.ietf.org/html/draft-json-schema-language-02#section-3.= 3.8) counts or not. But perhaps I'm overestimating the difficulty h= ere?

Put another way: by saying "definitions = only matter at the root", a large class of ambiguity goes away. It imm= ediately becomes clearer exactly how JSL works in detail. That struck me as= a good property.

As you point out, this does = have the consequence that it becomes more difficult to embed a JSL schema w= ithin a broader one, since all of its definitions have to be moved to the t= op level. Tooling can help here, but I agree this is a design decision with= shortcomings.

> A significant missing feat= ure is a choice of types. For instance, a field can be an array of strings or just a string; a=20 field can be an number or a number in quotes (ie a string).

<= /div>
This is intentionally left out. It's difficult to portably co= de-generate for this case. Instead, I was thinking users would either use a= n empty schema for this case (essentially marking the data as "any&quo= t;), or use a discriminator. Does that strike you as good enough?

On T= ue, Jul 23, 2019 at 9:08 PM Manger, James <James.H.Manger@team.telstra.com> wrote:

> In this draft, I introduced fine-grained numeri= cal types -- "float32", "float64", "int8", &q= uot;uint64", etc. -- because they are immensely useful for real-world = code generation.

=C2=A0

Might be more useful to have int53. That encourages = designers to use integers that interop nicely with I-JSON, ECMAScript etc.<= u>

=C2=A0

> I explicitly call out that 10.0 is considered a= fine "int8".

=C2=A0

Should also call out that 1.00e1 is considered a fin= e =E2=80=9Cint8=E2=80=9D.

=C2=A0

int64/uint64 are defined in 3.3.3. =E2=80=9CType=E2= =80=9D and table 2, but not included in num_type (2 =E2=80=9CSyntax=E2=80= =9D). I=E2=80=99d drop int64/uint64 totally due to the interop problems. So= me JSON tools start sending integers as strings if they are above 2^53.<= /u>

=C2=A0

=C2=A0

=E2=80=9Cref=E2=80=9D only referring to definitions = at the _root_ level seems unhelpfully restrictive. It doesn=E2=80=99t seem = to play nicely with the goal of being able to embed the schema in other JSO= N docs. It doesn=E2=80=99t work well with the recursive nature of schema (eg a schema for an object with, say, 2 properties needing 2 other = schemas for the allowed values of those properties). Would a better rule be= that a definition must appear along the path from the _root_ to the =E2=80= =9Cref=E2=80=9D; that is, a definition must be =E2=80=9Cabove=E2=80=9D a =E2=80=9Cref=E2=80=9D.

=C2=A0

=C2=A0

> I see no features in this spec worth adding<= /u>

=C2=A0

A significant missing feature is a choice of types. = For instance, a field can be an array of strings or just a string; a field = can be an number or a number in quotes (ie a string).

=C2=A0

--

James Manger

--0000000000003eed37058e71e949-- From nobody Wed Jul 24 22:35:30 2019 Return-Path: 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 4F27F120046 for ; Wed, 24 Jul 2019 22:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.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 EOKNOoffrqNd for ; Wed, 24 Jul 2019 22:35:26 -0700 (PDT) Received: from ipxdvo.tcif.telstra.com.au (ipxdvo.tcif.telstra.com.au [203.35.135.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D42120018 for ; Wed, 24 Jul 2019 22:35:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,305,1559484000"; d="scan'208,217";a="170721072" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipodvi.tcif.telstra.com.au with ESMTP; 25 Jul 2019 15:35:22 +1000 Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcbvi.tcif.telstra.com.au with ESMTP; 25 Jul 2019 15:35:22 +1000 Received: from wsapp5870.srv.dir.telstra.com (10.75.139.12) by wsmsg3752.srv.dir.telstra.com (172.49.40.173) with Microsoft SMTP Server (TLS) id 8.3.485.1; Thu, 25 Jul 2019 15:33:17 +1000 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5870.srv.dir.telstra.com (10.75.139.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 25 Jul 2019 15:33:16 +1000 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.101.125) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 25 Jul 2019 15:33:16 +1000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i15q8QKnmcrzGfhlOg0OWBBXTM0/j+CCdO8JpTvMYllZhZ0BiBb4wRj7QOTmboImzFFUiEwLcKb88JdqMUHrAJg2PMGzhSLtncUAtmheL8d3qnEco9UaVK93VuqZDcW9ix0nPWldrn+Qgl9WVzrnJrNUmCrT2UBUlNqL45Iio59kcOsQo2HmfBjN+ZJKFfdoV2B+lxeqDvwY1ZQAoI2TklCOiKkOrkhScZ8IrLzjjWYOZzHJ9bQGpArFi2kofBhByxR+ZaxBE8zPYVHOc7h4mlUzRbAwEpaNcU0Haat17JifQjDl4Tod1k7aiegyAGO5I7z+Lgpy6xcsIJ+k94tLnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OVcmoT+Y9uSNQF+pLzGNyBjEO71JAd5QiXHSB1fAgR0=; b=bHY0XIrKCG4OokyvLF8/D/tWGSJ5ELiIUwFP2tyGopp8g6xxM97RzQzjk6TmHV5kmk60Y/jk1mh8UN01nY/s9zYW24xZNKbyNwSa3KkjAPTuvNVXyD/WDURK5QnKf36b66RLt81pJedlURSZnDfA6nFnsKZVIU11de23vy4+B06+I0vzEJ3gz7Qus1qdhlY9pB5x8Rrm6oJBGnFhw82N7N79EPWVYU+10+vBLQaUpzFr7entMZl49izPR5L+pW6iCu0g3KBf4BawjrIdEdb1x4J3xFciWf7owl/cdRbkyp1Qejyy5IJGiBfyZzTm9YJ3gzSQVcqiiyTy0K9m3+uKvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=team.telstra.com;dmarc=pass action=none header.from=team.telstra.com;dkim=pass header.d=team.telstra.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OVcmoT+Y9uSNQF+pLzGNyBjEO71JAd5QiXHSB1fAgR0=; b=QZjSn0hvAu760hDkHLqhwl29DCVZVHh9yT+I4zBD2PKkxqSDMuLB+5D3ctbcJ62TifWiPN4asiQgiaLcLurK23MzrviaYJ70tw5WaRTAiHOpeXM7oxarvl/1na+l4TNqVxx76z+4U+ja1sjR6R53jtK/JbkIj2nY1Ld0Nxccgtg= Received: from SY2PR01MB2764.ausprd01.prod.outlook.com (52.134.190.138) by SY2PR01MB2555.ausprd01.prod.outlook.com (52.134.190.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Thu, 25 Jul 2019 05:33:15 +0000 Received: from SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::a080:9084:3e2f:68ab]) by SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::a080:9084:3e2f:68ab%4]) with mapi id 15.20.2094.013; Thu, 25 Jul 2019 05:33:15 +0000 From: "Manger, James" To: Ulysse Carion CC: JSON WG Thread-Topic: [Json] JSON Schema Language is nearly done Thread-Index: AQHVQD7nFMS5gbkqY0aU295wfEYotqbZHX0wgAEF2wCAAE0s0A== Date: Thu, 25 Jul 2019 05:33:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.35.9.18] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b866949-92fe-45dc-1731-08d710c197b1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SY2PR01MB2555; x-ms-traffictypediagnostic: SY2PR01MB2555: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0109D382B0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(39860400002)(346002)(366004)(136003)(396003)(189003)(199004)(7696005)(2906002)(102836004)(71190400001)(14454004)(99286004)(71200400001)(76116006)(86362001)(55016002)(8936002)(26005)(6246003)(6916009)(76176011)(66556008)(66446008)(66946007)(64756008)(6506007)(66476007)(6436002)(68736007)(3846002)(7736002)(186003)(81166006)(81156014)(8676002)(236005)(9686003)(6306002)(486006)(229853002)(316002)(25786009)(54896002)(53546011)(476003)(53936002)(74316002)(4326008)(446003)(5660300002)(478600001)(14444005)(256004)(11346002)(33656002)(66066001)(6116002)(790700001)(52536014); DIR:OUT; SFP:1102; SCL:1; SRVR:SY2PR01MB2555; H:SY2PR01MB2764.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IqpgCjer+ByU0oinSc+HtWyCPvIPp4RoJvo8WcqRP+cquJbWZ4ckkoEr7o0helahQei66QuEgp9FQ+Ynv4lgYAmwU8jYu0LHLj4GNvUY8SFiLXHMDXd9A3d483dTMEIyJbrmBPPsHGTzF8hEX74iZ6wLvi+PPzD660sOb91IDuvakbwyZf/mDXQLt3uY52MKvkJ4oQs1OS0Lj9N1J66B7pOZBT/hvaxewqGWGR47Bp/NnV1kj8XsUHQmd8QO3r6srTgf+0di5pNFxgCSxaLihCsYW0OJocOvlDaSR7oshzmjp1mF06sE+L/Rs6IS0xJrN4tq76VmFWqVBUs1VMjmyfU/HlPjALhzQloHRtQQABeeVsN4yeUmI/7FIdG2p7H76yxHoGR1aZeZjbyw6wWoLaDuOodCL8GbFJuxbufFQ8U= Content-Type: multipart/alternative; boundary="_000_SY2PR01MB2764E827C3109492AEC70F4AE5C10SY2PR01MB2764ausp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4b866949-92fe-45dc-1731-08d710c197b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 05:33:15.5412 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: James.H.Manger@team.telstra.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY2PR01MB2555 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 05:35:29 -0000 --_000_SY2PR01MB2764E827C3109492AEC70F4AE5C10SY2PR01MB2764ausp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBPbiB5b3VyIHBvaW50cyByZWdhcmRpbmcgbnVtYmVycyBiZXlvbmQgMl41My9pbnQ1MywgZG8g eW91IGZlZWwgdGhhdCB0aGUgd2FybmluZyBhYm91dCBJLUpTT04gaXMgaW5zdWZmaWNpZW50PyBN YW55IHN5c3RlbXMgdXNpbmcgSlNPTiBhcmVuJ3QgY29uY2VybmVkIGFib3V0IEphdmFTY3JpcHQs IGFuZCBmb3IgdGhlc2Ugc3lzdGVtcyBiZWluZyBhYmxlIHRvIHVzZSBpbnRlZ2VycyBiZXlvbmQg Ml4zMiBpcyB1c2VmdWwuIDY0LWJpdCBpbnRlZ2VycyBpcyB0aGUgaWRpb21hdGljIHdheSB0byBy ZXByZXNlbnQgdGhlc2UgdHlwZXMsIGFuZCBzbyB0aGF0J3Mgd2h5IEkgYWRkZWQgdGhvc2UgdG8g dGhlIHNwZWMuDQoNCldhcm5pbmcgYWJvdXQgSS1KU09OIGlzIGluc3VmZmljaWVudC4NCkl04oCZ cyBub3QganVzdCBKYXZhU2NyaXB0Lg0KQSBjb2RlIGdlbmVyYXRvciBzZWVpbmcg4oCcaW50NTPi gJ0gY2FuIHVzZSBhIOKAnGxvbmfigJ0gaW4gdGhlIGNvZGUgKGFuZCBvdGhlciBnZW5lcmF0b3Jz IGNhbiB1c2UgYSDigJxkb3VibGXigJ0pLg0KT2ZmZXJpbmcg4oCcaW50NjTigJ0gd2lsbCBsZWFk IHBlb3BsZSB0byBpbnRlcm9wIHByb2JsZW1zIHdoZW4gc29tZSBvZiB0aGVpciB2YWx1ZXMgYnJl YWsuIElmIHlvdSB3YW50IHRvIHVzZSBpbnRlZ2VycyBvdmVyIDJeNTMgaW4gSlNPTiBkb27igJl0 IHVzZSBKU09O4oCZcyBuYXRpdmUgbnVtYmVyIHN5bnRheDogdXNlIGEgc3RyaW5nIGluc3RlYWQg KHByb2JhYmx5IGJhc2U2NHVybC1lbmNvZGVkIGZvciByZWFsbHkgbGFyZ2UgY3J5cHRvIG51bWJl cnMpLg0KSWYgeW91IGhhdmUgYSBzeXN0ZW0gdGhhdCB5b3UgYXJlIGNlcnRhaW4gd2lsbCBuZXZl ciBuZWVkIHRvIGludGVyb3Agd2l0aCBvbmUgdGhhdCBhdCBzb21lIHBvaW50IGluIGl0cyBwYXJz aW5nIHRyZWF0cyBKU09OIG51bWJlcnMgYXMgZG91YmxlcyDigKYgd2VsbCB5b3UgYXJlIGluIGEg Y2xvc2VkIHN5c3RlbSBzbyB5b3UgZG9u4oCZdCByZWFsbHkgbmVlZHMgYW4gSUVURiBzcGVjIOKA piBhbmQgeW91IGFyZSBtYWtpbmcgZGFuZ2Vyb3VzIGFzc3VtcHRpb25zIGFib3V0IHlvdXIgZnV0 dXJlIHRlY2huaWNhbCBzdGFjayDigKYgKHBsdXMgeW91IGNhbiBwdXQg4oCcaW50NTPigJ0gaW4g eW91ciBzY2hlbWEsIGdldCBhIOKAnGxvbmfigJ0gaW4geW91ciBnZW5lcmF0ZWQgY29kZSwgYnV0 IGRvbuKAmXQgcHV0IGFueSAyXjUzIGNoZWNrcyBpbiB0aGUgY29kZSkuDQoNCg0KPj4gQSBzaWdu aWZpY2FudCBtaXNzaW5nIGZlYXR1cmUgaXMgYSBjaG9pY2Ugb2YgdHlwZXMuIEZvciBpbnN0YW5j ZSwgYSBmaWVsZCBjYW4gYmUgYW4gYXJyYXkgb2Ygc3RyaW5ncyBvciBqdXN0IGEgc3RyaW5nOyBh IGZpZWxkIGNhbiBiZSBhbiBudW1iZXIgb3IgYSBudW1iZXIgaW4gcXVvdGVzIChpZSBhIHN0cmlu ZykuDQoNCj4gVGhpcyBpcyBpbnRlbnRpb25hbGx5IGxlZnQgb3V0LiBJdCdzIGRpZmZpY3VsdCB0 byBwb3J0YWJseSBjb2RlLWdlbmVyYXRlIGZvciB0aGlzIGNhc2UuIEluc3RlYWQsIEkgd2FzIHRo aW5raW5nIHVzZXJzIHdvdWxkIGVpdGhlciB1c2UgYW4gZW1wdHkgc2NoZW1hIGZvciB0aGlzIGNh c2UgKGVzc2VudGlhbGx5IG1hcmtpbmcgdGhlIGRhdGEgYXMgImFueSIpLCBvciB1c2UgYSBkaXNj cmltaW5hdG9yLiBEb2VzIHRoYXQgc3RyaWtlIHlvdSBhcyBnb29kIGVub3VnaD8NCg0KVGhpcyBp cyBhIG1ham9yIGxpbWl0YXRpb24gZm9yIHNvbWV0aGluZyBjYWxsaW5nIGl0c2VsZiDigJxKU09O IFNjaGVtYSBMYW5ndWFnZeKAnSwgYXMgb3Bwb3NlZCB0bywgc2F5LCDigJxTY2hlbWEgTGFuZ3Vh Z2UgZm9yIGEgU3Vic2V0IG9mIEpTT07igJ0uIEFsbCBjb2RlIGdlbmVyYXRvcnMgbmVlZHMgdG8g YmUgYWJsZSB0byBpbnNlcnQg4oCcYW554oCdLiBJdHMgbm90IHRoZSBlbmQgb2YgdGhlIHdvcmxk IGlmIHNvbWUgY29kZSBnZW5lcmF0b3JzIHVzZSDigJxhbnnigJ0gd2hlbmV2ZXIgdGhlIHNjaGVt YSBhbGxvd3MgbXVsdGlwbGUgdHlwZXMgaWYgZG9pbmcgYmV0dGVyIGlzIHRvbyBkaWZmaWN1bHQu DQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KDQpPbiBUdWUsIEp1bCAyMywgMjAxOSBhdCA5OjA4IFBN IE1hbmdlciwgSmFtZXMgPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208bWFpbHRvOkph bWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+PiB3cm90ZToNCj4gSW4gdGhpcyBkcmFmdCwg SSBpbnRyb2R1Y2VkIGZpbmUtZ3JhaW5lZCBudW1lcmljYWwgdHlwZXMgLS0gImZsb2F0MzIiLCAi ZmxvYXQ2NCIsICJpbnQ4IiwgInVpbnQ2NCIsIGV0Yy4gLS0gYmVjYXVzZSB0aGV5IGFyZSBpbW1l bnNlbHkgdXNlZnVsIGZvciByZWFsLXdvcmxkIGNvZGUgZ2VuZXJhdGlvbi4NCg0KTWlnaHQgYmUg bW9yZSB1c2VmdWwgdG8gaGF2ZSBpbnQ1My4gVGhhdCBlbmNvdXJhZ2VzIGRlc2lnbmVycyB0byB1 c2UgaW50ZWdlcnMgdGhhdCBpbnRlcm9wIG5pY2VseSB3aXRoIEktSlNPTiwgRUNNQVNjcmlwdCBl dGMuDQoNCj4gSSBleHBsaWNpdGx5IGNhbGwgb3V0IHRoYXQgMTAuMCBpcyBjb25zaWRlcmVkIGEg ZmluZSAiaW50OCIuDQoNClNob3VsZCBhbHNvIGNhbGwgb3V0IHRoYXQgMS4wMGUxIGlzIGNvbnNp ZGVyZWQgYSBmaW5lIOKAnGludDjigJ0uDQoNCmludDY0L3VpbnQ2NCBhcmUgZGVmaW5lZCBpbiAz LjMuMy4g4oCcVHlwZeKAnSBhbmQgdGFibGUgMiwgYnV0IG5vdCBpbmNsdWRlZCBpbiBudW1fdHlw ZSAoMiDigJxTeW50YXjigJ0pLiBJ4oCZZCBkcm9wIGludDY0L3VpbnQ2NCB0b3RhbGx5IGR1ZSB0 byB0aGUgaW50ZXJvcCBwcm9ibGVtcy4gU29tZSBKU09OIHRvb2xzIHN0YXJ0IHNlbmRpbmcgaW50 ZWdlcnMgYXMgc3RyaW5ncyBpZiB0aGV5IGFyZSBhYm92ZSAyXjUzLg0KDQoNCuKAnHJlZuKAnSBv bmx5IHJlZmVycmluZyB0byBkZWZpbml0aW9ucyBhdCB0aGUgX3Jvb3RfIGxldmVsIHNlZW1zIHVu aGVscGZ1bGx5IHJlc3RyaWN0aXZlLiBJdCBkb2VzbuKAmXQgc2VlbSB0byBwbGF5IG5pY2VseSB3 aXRoIHRoZSBnb2FsIG9mIGJlaW5nIGFibGUgdG8gZW1iZWQgdGhlIHNjaGVtYSBpbiBvdGhlciBK U09OIGRvY3MuIEl0IGRvZXNu4oCZdCB3b3JrIHdlbGwgd2l0aCB0aGUgcmVjdXJzaXZlIG5hdHVy ZSBvZiBzY2hlbWEgKGVnIGEgc2NoZW1hIGZvciBhbiBvYmplY3Qgd2l0aCwgc2F5LCAyIHByb3Bl cnRpZXMgbmVlZGluZyAyIG90aGVyIHNjaGVtYXMgZm9yIHRoZSBhbGxvd2VkIHZhbHVlcyBvZiB0 aG9zZSBwcm9wZXJ0aWVzKS4gV291bGQgYSBiZXR0ZXIgcnVsZSBiZSB0aGF0IGEgZGVmaW5pdGlv biBtdXN0IGFwcGVhciBhbG9uZyB0aGUgcGF0aCBmcm9tIHRoZSBfcm9vdF8gdG8gdGhlIOKAnHJl ZuKAnTsgdGhhdCBpcywgYSBkZWZpbml0aW9uIG11c3QgYmUg4oCcYWJvdmXigJ0gYSDigJxyZWbi gJ0uDQoNCg0KPiBJIHNlZSBubyBmZWF0dXJlcyBpbiB0aGlzIHNwZWMgd29ydGggYWRkaW5nDQoN CkEgc2lnbmlmaWNhbnQgbWlzc2luZyBmZWF0dXJlIGlzIGEgY2hvaWNlIG9mIHR5cGVzLiBGb3Ig aW5zdGFuY2UsIGEgZmllbGQgY2FuIGJlIGFuIGFycmF5IG9mIHN0cmluZ3Mgb3IganVzdCBhIHN0 cmluZzsgYSBmaWVsZCBjYW4gYmUgYW4gbnVtYmVyIG9yIGEgbnVtYmVyIGluIHF1b3RlcyAoaWUg YSBzdHJpbmcpLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= --_000_SY2PR01MB2764E827C3109492AEC70F4AE5C10SY2PR01MB2764ausp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUFVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IE9uIHlv dXIgcG9pbnRzIHJlZ2FyZGluZyBudW1iZXJzIGJleW9uZCAyXjUzL2ludDUzLCBkbyB5b3UgZmVl bCB0aGF0IHRoZSB3YXJuaW5nIGFib3V0IEktSlNPTiBpcyBpbnN1ZmZpY2llbnQ/IE1hbnkgc3lz dGVtcyB1c2luZyBKU09OIGFyZW4ndCBjb25jZXJuZWQgYWJvdXQgSmF2YVNjcmlwdCwgYW5kIGZv ciB0aGVzZSBzeXN0ZW1zIGJlaW5nIGFibGUgdG8gdXNlIGludGVnZXJzIGJleW9uZCAyXjMyIGlz DQogdXNlZnVsLiA2NC1iaXQgaW50ZWdlcnMgaXMgdGhlIGlkaW9tYXRpYyB3YXkgdG8gcmVwcmVz ZW50IHRoZXNlIHR5cGVzLCBhbmQgc28gdGhhdCdzIHdoeSBJIGFkZGVkIHRob3NlIHRvIHRoZSBz cGVjLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2FybmluZyBhYm91dCBJLUpTT04g aXMgaW5zdWZmaWNpZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXTi gJlzIG5vdCBqdXN0IEphdmFTY3JpcHQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BIGNvZGUgZ2VuZXJhdG9yIHNlZWluZyDigJxpbnQ1M+KAnSBjYW4gdXNlIGEg4oCcbG9u Z+KAnSBpbiB0aGUgY29kZSAoYW5kIG90aGVyIGdlbmVyYXRvcnMgY2FuIHVzZSBhIOKAnGRvdWJs ZeKAnSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZmZlcmluZyDigJxp bnQ2NOKAnSB3aWxsIGxlYWQgcGVvcGxlIHRvIGludGVyb3AgcHJvYmxlbXMgd2hlbiBzb21lIG9m IHRoZWlyIHZhbHVlcyBicmVhay4gSWYgeW91IHdhbnQgdG8gdXNlIGludGVnZXJzIG92ZXIgMl41 MyBpbiBKU09OIGRvbuKAmXQgdXNlIEpTT07igJlzIG5hdGl2ZSBudW1iZXIgc3ludGF4OiB1c2Ug YSBzdHJpbmcgaW5zdGVhZCAocHJvYmFibHkgYmFzZTY0dXJsLWVuY29kZWQgZm9yIHJlYWxseSBs YXJnZQ0KIGNyeXB0byBudW1iZXJzKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklmIHlvdSBoYXZlIGEgc3lzdGVtIHRoYXQgeW91IGFyZSBjZXJ0YWluIHdpbGwgbmV2ZXIg bmVlZCB0byBpbnRlcm9wIHdpdGggb25lIHRoYXQgYXQgc29tZSBwb2ludCBpbiBpdHMgcGFyc2lu ZyB0cmVhdHMgSlNPTiBudW1iZXJzIGFzIGRvdWJsZXMg4oCmIHdlbGwgeW91IGFyZSBpbiBhIGNs b3NlZCBzeXN0ZW0gc28geW91IGRvbuKAmXQgcmVhbGx5IG5lZWRzIGFuIElFVEYgc3BlYyDigKYg YW5kIHlvdSBhcmUgbWFraW5nDQogZGFuZ2Vyb3VzIGFzc3VtcHRpb25zIGFib3V0IHlvdXIgZnV0 dXJlIHRlY2huaWNhbCBzdGFjayDigKYgKHBsdXMgeW91IGNhbiBwdXQg4oCcaW50NTPigJ0gaW4g eW91ciBzY2hlbWEsIGdldCBhIOKAnGxvbmfigJ0gaW4geW91ciBnZW5lcmF0ZWQgY29kZSwgYnV0 IGRvbuKAmXQgcHV0IGFueSAyXjUzIGNoZWNrcyBpbiB0aGUgY29kZSkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsgQSBzaWduaWZpY2FudCBtaXNzaW5n IGZlYXR1cmUgaXMgYSBjaG9pY2Ugb2YgdHlwZXMuIEZvciBpbnN0YW5jZSwgYSBmaWVsZCBjYW4g YmUgYW4gYXJyYXkgb2Ygc3RyaW5ncyBvciBqdXN0IGEgc3RyaW5nOyBhIGZpZWxkIGNhbiBiZSBh biBudW1iZXIgb3IgYSBudW1iZXIgaW4gcXVvdGVzIChpZSBhIHN0cmluZykuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgVGhpcyBpcyBp bnRlbnRpb25hbGx5IGxlZnQgb3V0LiBJdCdzIGRpZmZpY3VsdCB0byBwb3J0YWJseSBjb2RlLWdl bmVyYXRlIGZvciB0aGlzIGNhc2UuIEluc3RlYWQsIEkgd2FzIHRoaW5raW5nIHVzZXJzIHdvdWxk IGVpdGhlciB1c2UgYW4gZW1wdHkgc2NoZW1hIGZvciB0aGlzIGNhc2UgKGVzc2VudGlhbGx5IG1h cmtpbmcgdGhlIGRhdGEgYXMgJnF1b3Q7YW55JnF1b3Q7KSwgb3IgdXNlIGEgZGlzY3JpbWluYXRv ci4gRG9lcw0KIHRoYXQgc3RyaWtlIHlvdSBhcyBnb29kIGVub3VnaD88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEgbWFqb3IgbGltaXRhdGlvbiBmb3Igc29tZXRoaW5n IGNhbGxpbmcgaXRzZWxmIOKAnEpTT04gU2NoZW1hIExhbmd1YWdl4oCdLCBhcyBvcHBvc2VkIHRv LCBzYXksIOKAnFNjaGVtYSBMYW5ndWFnZSBmb3IgYSBTdWJzZXQgb2YgSlNPTuKAnS4gQWxsIGNv ZGUgZ2VuZXJhdG9ycyBuZWVkcyB0byBiZSBhYmxlIHRvIGluc2VydCDigJxhbnnigJ0uIEl0cyBu b3QgdGhlIGVuZCBvZiB0aGUgd29ybGQgaWYgc29tZSBjb2RlDQogZ2VuZXJhdG9ycyB1c2Ug4oCc YW554oCdIHdoZW5ldmVyIHRoZSBzY2hlbWEgYWxsb3dzIG11bHRpcGxlIHR5cGVzIGlmIGRvaW5n IGJldHRlciBpcyB0b28gZGlmZmljdWx0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1bCAyMywgMjAxOSBhdCA5OjA4IFBNIE1hbmdlciwgSmFt ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tIj5K YW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jmd0OyBJbiB0aGlzIGRyYWZ0LCBJIGludHJvZHVjZWQgZmluZS1ncmFpbmVkIG51bWVy aWNhbCB0eXBlcyAtLSAmcXVvdDtmbG9hdDMyJnF1b3Q7LCAmcXVvdDtmbG9hdDY0JnF1b3Q7LCAm cXVvdDtpbnQ4JnF1b3Q7LCAmcXVvdDt1aW50NjQmcXVvdDssIGV0Yy4gLS0gYmVjYXVzZSB0aGV5 IGFyZSBpbW1lbnNlbHkgdXNlZnVsIGZvciByZWFsLXdvcmxkIGNvZGUgZ2VuZXJhdGlvbi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1pZ2h0IGJlIG1vcmUgdXNlZnVsIHRvIGhhdmUgaW50 NTMuIFRoYXQgZW5jb3VyYWdlcyBkZXNpZ25lcnMgdG8gdXNlIGludGVnZXJzIHRoYXQgaW50ZXJv cCBuaWNlbHkgd2l0aCBJLUpTT04sIEVDTUFTY3JpcHQgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZndDsgSSBleHBsaWNpdGx5IGNhbGwgb3V0IHRoYXQgMTAuMCBpcyBj b25zaWRlcmVkIGEgZmluZSAmcXVvdDtpbnQ4JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+U2hvdWxkIGFsc28gY2FsbCBvdXQgdGhhdCAxLjAwZTEgaXMgY29uc2lkZXJlZCBhIGZp bmUg4oCcaW50OOKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmludDY0L3VpbnQ2NCBh cmUgZGVmaW5lZCBpbiAzLjMuMy4g4oCcVHlwZeKAnSBhbmQgdGFibGUgMiwgYnV0IG5vdCBpbmNs dWRlZCBpbiBudW1fdHlwZSAoMiDigJxTeW50YXjigJ0pLiBJ4oCZZCBkcm9wIGludDY0L3VpbnQ2 NCB0b3RhbGx5IGR1ZSB0byB0aGUgaW50ZXJvcCBwcm9ibGVtcy4gU29tZSBKU09OIHRvb2xzIHN0 YXJ0DQogc2VuZGluZyBpbnRlZ2VycyBhcyBzdHJpbmdzIGlmIHRoZXkgYXJlIGFib3ZlIDJeNTMu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+4oCccmVm4oCdIG9ubHkgcmVmZXJyaW5nIHRvIGRlZmluaXRpb25z IGF0IHRoZSBfcm9vdF8gbGV2ZWwgc2VlbXMgdW5oZWxwZnVsbHkgcmVzdHJpY3RpdmUuIEl0IGRv ZXNu4oCZdCBzZWVtIHRvIHBsYXkgbmljZWx5IHdpdGggdGhlIGdvYWwgb2YgYmVpbmcgYWJsZSB0 byBlbWJlZCB0aGUgc2NoZW1hIGluIG90aGVyIEpTT04NCiBkb2NzLiBJdCBkb2VzbuKAmXQgd29y ayB3ZWxsIHdpdGggdGhlIHJlY3Vyc2l2ZSBuYXR1cmUgb2Ygc2NoZW1hIChlZyBhIHNjaGVtYSBm b3IgYW4gb2JqZWN0IHdpdGgsIHNheSwgMiBwcm9wZXJ0aWVzIG5lZWRpbmcgMiBvdGhlciBzY2hl bWFzIGZvciB0aGUgYWxsb3dlZCB2YWx1ZXMgb2YgdGhvc2UgcHJvcGVydGllcykuIFdvdWxkIGEg YmV0dGVyIHJ1bGUgYmUgdGhhdCBhIGRlZmluaXRpb24gbXVzdCBhcHBlYXIgYWxvbmcgdGhlIHBh dGggZnJvbQ0KIHRoZSBfcm9vdF8gdG8gdGhlIOKAnHJlZuKAnTsgdGhhdCBpcywgYSBkZWZpbml0 aW9uIG11c3QgYmUg4oCcYWJvdmXigJ0gYSDigJxyZWbigJ0uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0 OyBJIHNlZSBubyBmZWF0dXJlcyBpbiB0aGlzIHNwZWMgd29ydGggYWRkaW5nPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5BIHNpZ25pZmljYW50IG1pc3NpbmcgZmVhdHVyZSBpcyBhIGNob2lj ZSBvZiB0eXBlcy4gRm9yIGluc3RhbmNlLCBhIGZpZWxkIGNhbiBiZSBhbiBhcnJheSBvZiBzdHJp bmdzIG9yIGp1c3QgYSBzdHJpbmc7IGEgZmllbGQgY2FuIGJlIGFuIG51bWJlciBvciBhIG51bWJl ciBpbiBxdW90ZXMgKGllIGEgc3RyaW5nKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0t PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkphbWVzIE1hbmdlcjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SY2PR01MB2764E827C3109492AEC70F4AE5C10SY2PR01MB2764ausp_-- From nobody Thu Jul 25 15:12:43 2019 Return-Path: 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 39E32120284 for ; Thu, 25 Jul 2019 15:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20150623.gappssmtp.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 5Z4Hcb4rCCCc for ; Thu, 25 Jul 2019 15:12:36 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 F2CF51202F2 for ; Thu, 25 Jul 2019 15:12:35 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id z3so100674006iog.0 for ; Thu, 25 Jul 2019 15:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vZOQQtLBT/9Tt2SS+GQ4YgsfxO6Gh4Ijz+yE7oLJhlE=; b=D9S/WcpcC0V09pn58pNVUtwRgLJaeBBECwXs7km+nlNeGlSmVncWUmsozdDoR8+Slu BcNxrK4MtlhSkdwnc/7kyl/QteWKQ2R3yfQeGtpA0Mqk6VRVFBtEqtBGp+jIY0qaJC1t QgxNlp3sAH6afIcGtquYvJuYLdma9rBz2cQvn6/5X9EaiVfi1Kqw9mBunXqDcBkkoVjo CFyW2LKN3yVzc6xsC8VyUEDRm9yAhFnTOnlmQT7/fpIzgfAi7f7c+LrAY1GVsUvDID7p /XQ9sgOnhJpA/GtwIOMTBMBufmFGnqa/yF4SnHoQphs2Dh6GBT4X23jXbJhuJ9P3Nb1f U11w== 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:content-transfer-encoding; bh=vZOQQtLBT/9Tt2SS+GQ4YgsfxO6Gh4Ijz+yE7oLJhlE=; b=VgfMKaRDUwj9uHEydTseKb4Hd/a8KfMiICH/g5QJWm055mbGoTeXkzW63ySqBeaSnh q6qBv6KhZ+K50+Z0bjcTRA9Yh6ULi9PppF+wJIXiqkRVhoQ7zA82oBBhxGTr7e5rv2Zv BMRmyZqFI2LNjq8CywwrPhzIs2GExWDKjDBlaZSzeHnYW52HyVplPjG4EhI1zzA1uY+h Yr9bZ0ZMycyscHWn9z0DVhTNX0IEI2Yq3V2EvrAWrzIook+6TA6tOGoAjwDrmD2nTIUQ W+jGESMDG94UJ4/frS/O3X+nQeA3WGPkobSwNCkR1QF9brnKCRrSslw15m1UzyPGRC8v sDUw== X-Gm-Message-State: APjAAAUnTMyjsHV1NwyFOl73q/6DGBd0azc3Yfl2k3nybmWzjR783ThJ rE5RUXVkHjMFQ83hBw9UdFWqQcfHtxc+I+4YamA= X-Google-Smtp-Source: APXvYqwAwwHtvdz079r4UKG9BodrUmx/Xf5Tmqbl0ynVPjIj6UQeiovFZ0OB4+pG6+wPvFG9le0GxV/lbXBp6DESwVs= X-Received: by 2002:a5d:9291:: with SMTP id s17mr14369048iom.10.1564092755021; Thu, 25 Jul 2019 15:12:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Newton Date: Thu, 25 Jul 2019 18:12:24 -0400 Message-ID: To: Ulysse Carion Cc: JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 22:12:43 -0000 What relationship does this have with JSON Schema (https://json-schema.org/)? Is it a separate effort (which it appears to be)? There maybe a name collision here. I'll note that json-schema.org has and continues to submit I-Ds. In the end, I believe no effort in the IETF to put a JSON ddl on the standards track would be legitimate without the involvement of json-schema.org (I said as much in London when I presented JCR). They have a larger community than we have here and a specification baked into many tools. Giving this some more thought, the time for the IETF to be doing a JSON ddl may have passed. Discussions on the topic have been on and off for at least six years. In the meantime, JSON Schema (json-schema.org) has made its way into many tools. Additionally, other standards have materialized such as Swagger/OpenAPI to address other aspects of JSON usage in REST, etc... Due to the emergence of new formats such as TOML (to compete against YAML) and RCON and JSONLines to compete against JSON, it maybe that the undiscovered territory is that which PHB has been pointing towards for years: an abstraction language. But such a thing is far from the IETF's stomping grounds. -andy On Sun, Jul 21, 2019 at 11:37 PM Ulysse Carion wrote: > > 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 ar= e tracked on GitHub here. > > In this draft, I introduced fine-grained numerical types -- "float32", "f= loat64", "int8", "uint64", etc. -- because they are immensely useful for re= al-world code generation. The spec details these types here (Table 2). "flo= at32" 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 expli= citly 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 implementati= ons may in practice be more restrictive in what they accept than the spec d= escribes. I think that's acceptable; it seems clear that either approach wi= ll lead to people deviating from the spec. > > Let me know what y'all think about JSON Schema Language as a whole! If yo= u relish in the concrete, here are working implementations of validators bu= ilt 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 o= n that soon. > > I view JSL as being nearly complete, so any and all criticism is most wel= come. > > Thanks, > Ulysse > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Thu Jul 25 15:37:03 2019 Return-Path: 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 4D9311201F1 for ; Thu, 25 Jul 2019 15:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7reXDE7JvYt8 for ; Thu, 25 Jul 2019 15:37:00 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A321201D1 for ; Thu, 25 Jul 2019 15:37:00 -0700 (PDT) Received: from dhcp-80d9.meeting.ietf.org (dhcp-80d9.meeting.ietf.org [31.133.128.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45vnBy2gSCz10Bp; Fri, 26 Jul 2019 00:36:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 25 Jul 2019 18:36:56 -0400 Cc: Ulysse Carion , JSON WG X-Mao-Original-Outgoing-Id: 585787014.9491661-ca2ee3e5203300418474a273068401c5 Content-Transfer-Encoding: quoted-printable Message-Id: <1D53CC7E-38A6-4F93-93F8-FE9227554B2B@tzi.org> References: To: Andrew Newton X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 22:37:02 -0000 On Jul 25, 2019, at 18:12, Andrew Newton wrote: >=20 > Due to the emergence of new formats such as TOML (to compete against > YAML) and RCON and JSONLines to compete against JSON, A data definition language (what we call =E2=80=9Cschema language=E2=80=9D= here) describes data in a (generic) data model, not data serialized in = a format. The formats you mention have a high degree of commonality in = their generic data models, so I don=E2=80=99t know why a simple data = definition language cannot cover all of them [but then I don=E2=80=99t = know RCON]. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 25 23:15:57 2019 Return-Path: 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 3D45C1202B1 for ; Thu, 25 Jul 2019 23:15:55 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 mFozdeh6uHMN for ; Thu, 25 Jul 2019 23:15:52 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 2E52A1202AA for ; Thu, 25 Jul 2019 23:15:52 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id r1so53080443wrl.7 for ; Thu, 25 Jul 2019 23:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MN8/0FmmGPrDrCZx4zvWi1zS4yrwZ45s8L+DPRVmpaU=; b=KhfzrsCFX9iWYl7KrY4JH1hFA1Y/F81sVTbzn12mNQcbT8TzNxKdKVhqqDEM0Cl3AW fHWRbRsIKueHwwI3ZVuD0EAekLOnKzr4K/KQMjmWC8Lkr8axaxr7ODx2RPvRiJvWxaC7 oj0AwS6D7KUOmb3lo1EJu7YuJ2CQmrV5A8naXhIS8oW+lf3WNdJPSB/hf9KPuQEu9vb5 Xnaxj7RZGsmkBgA41fzPNEIwf1/2tBhxMXI0YC8pVeaF/OtqeNEAKcF22E2/pntjPD8S 8lNIM0zoVbI/bwBIuE8pDpOjhqypp/SqarCJplBUoMhLVIGyPOfdQp3QbtMq/jJc1wiz QeYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MN8/0FmmGPrDrCZx4zvWi1zS4yrwZ45s8L+DPRVmpaU=; b=H+elF7LK8aJYDJ9vKgB5KVzdCfzH4wit1FRcwzjqP69bZXcbXP4YEbyWxFwdPsZkR2 cFukHgIYBNgg2eXHZ7krinkpC85W9lM/C6bNUkeraBuCuZwQFq6CcGiKvymOLESVl77A sNZcp6W/ry3u7NPFi082bMsPiDSAYcNA57loKzuVVKp7T2FIOUx+3pU6pE2nUQNo7fGF eZ8afFjb/jX+PLHSYkLVWttL3yBQv1kMHBqsxNol4NiODyHoU0fCnRlucs2ebGrNtMTz MG7Y1O8HkVu+XGxsTGVMMJXxdR2hefJl8ead1T4v73YqkPLUZo6m4481Vg0SJIk2J9x/ nHjg== X-Gm-Message-State: APjAAAWE8/ULRKyuB+6N49zy+Nklo+ZyJKQAJ9JgmxfvEiw8cQ27f+JR sTr0+N43j2UjHZlEHAfKZya/yseA X-Google-Smtp-Source: APXvYqxy2rJ3Cd4y6wupu4vvNzHrvcItgjeRf3JtS5er4eV0VBL7DTXL2AKDFMEv2lBiA1QMyaydmA== X-Received: by 2002:a5d:65c5:: with SMTP id e5mr51056211wrw.266.1564121750036; Thu, 25 Jul 2019 23:15:50 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id a64sm50032086wmf.1.2019.07.25.23.15.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 23:15:49 -0700 (PDT) To: Andrew Newton , Ulysse Carion Cc: JSON WG References: From: Anders Rundgren Message-ID: <14ac316b-0f79-02c1-91c0-e99538b4ca68@gmail.com> Date: Fri, 26 Jul 2019 08:15:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 06:15:56 -0000 I'm still waiting (most likely in vain) for a JSON schema language that better reflects the actual use of JSON, and in particular numbers. That is: - monetary types are distinct from other numbers since they don't build on FP math. - big integers are in IETF standards (AFAIK without exceptions) expressed as quoted strings which in turn may be coded as decimal, hex, base64url etc. Anders On 2019-07-26 00:12, Andrew Newton wrote: > What relationship does this have with JSON Schema > (https://json-schema.org/)? Is it a separate effort (which it appears > to be)? There maybe a name collision here. I'll note that > json-schema.org has and continues to submit I-Ds. > > In the end, I believe no effort in the IETF to put a JSON ddl on the > standards track would be legitimate without the involvement of > json-schema.org (I said as much in London when I presented JCR). They > have a larger community than we have here and a specification baked > into many tools. > > Giving this some more thought, the time for the IETF to be doing a > JSON ddl may have passed. Discussions on the topic have been on and > off for at least six years. In the meantime, JSON Schema > (json-schema.org) has made its way into many tools. Additionally, > other standards have materialized such as Swagger/OpenAPI to address > other aspects of JSON usage in REST, etc... > > Due to the emergence of new formats such as TOML (to compete against > YAML) and RCON and JSONLines to compete against JSON, it maybe that > the undiscovered territory is that which PHB has been pointing towards > for years: an abstraction language. But such a thing is far from the > IETF's stomping grounds. > > -andy > > On Sun, Jul 21, 2019 at 11:37 PM Ulysse Carion wrote: >> >> 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. >> >> 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 (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 >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Fri Jul 26 00:58:08 2019 Return-Path: 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 38F671202C5 for ; Fri, 26 Jul 2019 00:58:07 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 Q7iODfzIEnb7 for ; Fri, 26 Jul 2019 00:58:04 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 2B95E1202C3 for ; Fri, 26 Jul 2019 00:58:04 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id g67so42742089wme.1 for ; Fri, 26 Jul 2019 00:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=c9yVyM2FOM5YOPTKmqp6qw+5zcJFjgswwaxcAm0Dm4M=; b=HCCTXWB+zivzXG7db00oeNj/HhtxFMFFnxQiEskrwO8ubDp7RGu+OFMFizVxpolUjl 6t44c19BXUuNtp5wuQhqBa1LZblGUETpAvpID7YrbOjQtUi/inoJlmxoQK+5aFVA7ZBt SaTd0YlU3jAU1wzcW1zszf0EHHtGePFss9Sl4XFz0eJrz+WN6SBoDWtxWWwku7F7I052 DhlittPfaWlgV74aPcs4FKbAkJN3CGQ2BqSR3IpAogPAZck0dQIwZN7FoZurgGQmFrKe oadunDyi/8g5STIhJagH7MRUgD6sKbYgHiOK4RBnxQDCoiG1GCc/+G7SmZLoIaWulvQ0 e+EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=c9yVyM2FOM5YOPTKmqp6qw+5zcJFjgswwaxcAm0Dm4M=; b=QbGTCdutb+DjuNk6d9VojrGV1M8Oud7g5JyATGpg5sqoi8+/rsGjmugjb2i7cYGVF1 M//tLoBX6INkcQnJ/MZYL230Hrp3ru8osGdOW0au+Ztn1S3PB4VMgP7Vk1KdozoEBi6p WHVoOi7GuZsCxZxgOEJ7JCx8Cwu+S396gBZL6wqYh2EcFCDOlLXqhnq4g6q7fjTXuH+F 835qlg64mFsD5k/FXcc8ZX5Qsplv0o4bFEa1cJpm+zj7WT8eukHsE9ZvKEMcZ1sD2FI0 +erfXFvUzblC3ESyOy93jMSlhxuOT/NuHU+cXHTzmuSEEYfuEFAfrAEaNzfZJwjDM+DI B4fA== X-Gm-Message-State: APjAAAXj/4YyH0SthZI0qkoxyH2Bs7iT+cQKVct7KQHveFZCscNx9s98 VeXpcKWtklSJMHqOPhTao4A= X-Google-Smtp-Source: APXvYqwfZ+C9Cn60hF13AELclWmWrWkBX6HAraEmehJBWF0vs1p2lYAdMTNqBRXkoVPADqa3vubU8A== X-Received: by 2002:a1c:c005:: with SMTP id q5mr44082683wmf.59.1564127882415; Fri, 26 Jul 2019 00:58:02 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id z1sm52157052wrp.51.2019.07.26.00.58.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jul 2019 00:58:01 -0700 (PDT) From: Anders Rundgren To: Henry Andrews Cc: JSON WG References: <14ac316b-0f79-02c1-91c0-e99538b4ca68@gmail.com> <429085535.787488.1564124880030@mail.yahoo.com> Message-ID: Date: Fri, 26 Jul 2019 09:57:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <429085535.787488.1564124880030@mail.yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 07:58:07 -0000 On 2019-07-26 09:08, Henry Andrews wrote: > Hi Anders, Hi Henry, >   As long as you are not relying on the text representation of JSON (e.g. using JSON numbers and needing to distinguish between 1, 1.0, and 1.00) then you should be able to easily make a re-usable JSON Schema extension vocabulary for this.  Since it sounds like you are using strings to get around that problem, then it should be fine.  There is also already a keyword to indicate encoded strings, including RFC 4648 base64url. I'm not particularly concerned about my own use of JSON, but about the ability to for example expressing an RSA JWK [1] or an amount in PaymentRequest [2] using some kind of JSON schema. >   Some of these number-in-string issues have been proposed to be solved with the "format" keyword, but "format" is kind of a disaster due to its optional best-effort validation behavior.  We are making some changes in this draft to try to make it more reliably predictable and give schema authors some control over how it is processed, but we will be strongly encouraging people to write their own keyword vocabulary rather than custom formats. I don't understand exactly what the problem is here. IMO all integer types could schema wise be treated identical (albeit some with warnings) and be supplied as: - JSON Number - "JSON Number" - "hex" - "base64" - "base64url" - "base58" Real numbers would probably only gain by the two first notations. The monetary type is separate from the rest. It has a very specific syntax like a date type. This should cover 99% of existing and future JSON use cases. Yes, this is a slightly risky statement... Pardon for being somewhat low-level but if the low level isn't right, the upper parts tend to fall as well :-) thanx, Anders 1] https://tools.ietf.org/html/rfc7520#section-3.3 2] https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value > >   It's a lot easier to manage different keyword sets than to have this one keyword into which everything higher-level data type somehow must be shoved. > >   Once we have the new draft out, it would be an interesting test of the feature to see how easy it would be to design such a keyword vocabulary. > > thanks, > -henry > > > On Thursday, July 25, 2019, 11:16:03 PM PDT, Anders Rundgren wrote: > > > I'm still waiting (most likely in vain) for a JSON schema language > that better reflects the actual use of JSON, and in particular numbers. > > That is: > - monetary types are distinct from other numbers since they don't build on FP math. > - big integers are in IETF standards (AFAIK without exceptions) expressed as quoted strings which in turn may be coded as decimal, hex, base64url etc. > > Anders > > On 2019-07-26 00:12, Andrew Newton wrote: > > What relationship does this have with JSON Schema > > (https://json-schema.org/)? Is it a separate effort (which it appears > > to be)? There maybe a name collision here. I'll note that > > json-schema.org has and continues to submit I-Ds. > > > > In the end, I believe no effort in the IETF to put a JSON ddl on the > > standards track would be legitimate without the involvement of > > json-schema.org (I said as much in London when I presented JCR). They > > have a larger community than we have here and a specification baked > > into many tools. > > > > Giving this some more thought, the time for the IETF to be doing a > > JSON ddl may have passed. Discussions on the topic have been on and > > off for at least six years. In the meantime, JSON Schema > > (json-schema.org) has made its way into many tools. Additionally, > > other standards have materialized such as Swagger/OpenAPI to address > > other aspects of JSON usage in REST, etc... > > > > Due to the emergence of new formats such as TOML (to compete against > > YAML) and RCON and JSONLines to compete against JSON, it maybe that > > the undiscovered territory is that which PHB has been pointing towards > > for years: an abstraction language. But such a thing is far from the > > IETF's stomping grounds. > > > > -andy > > > > On Sun, Jul 21, 2019 at 11:37 PM Ulysse Carion > wrote: > >> > >> 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. > >> > >> 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 (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 > >> _______________________________________________ > >> json mailing list > >> json@ietf.org > >> https://www.ietf.org/mailman/listinfo/json > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Fri Jul 26 02:26:44 2019 Return-Path: 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 CBDF31202F2 for ; Fri, 26 Jul 2019 02:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20150623.gappssmtp.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 L4rfQw7t-Zs1 for ; Fri, 26 Jul 2019 02:26:41 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 32A611202F8 for ; Fri, 26 Jul 2019 02:26:41 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id k20so103373872ios.10 for ; Fri, 26 Jul 2019 02:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dRxK9GYVcN+MHkACRNnmaJqoh720rqQRhGkSH8lwmfU=; b=zxlme6zA2QDNWP4IptUljbs8PUCwT6JZ+qWMuKE0gKocF3a+xZGnCOx5tZ+EFx/FVI a+AqzZMESSAr/nVPb6bUJZ3+mvIKhttf8QpvMoDLZndZMUdGMQKsvVSjXdUWCXtLSW8J pMAUSYHn6T4WaTmZ+rz6vQZUoIPUnp7HuU114cCYVeIysC3fLIe+IRJiY6GjySailENR Dh52YeqNzg86JWg5EPo2ApQqMXDMf+9P4eVH8+vdRcLWU3yXwV6Z80APON7w2hQsCP2v h9Ke4axxJadcdVogJC9AU0ZtnI06LCkcCoHJ3+WdF33856oPWueuQDpnZGMVzRVgYl5k i7OQ== 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:content-transfer-encoding; bh=dRxK9GYVcN+MHkACRNnmaJqoh720rqQRhGkSH8lwmfU=; b=mmK7rc6SuQSzeMaiWDpBFHyoBZSYaf3PWqlLnHMoSU4dpQ+9dtgssliDtuTXDBfxPj iY1JebuXTKlS6fZxOLxuxuoYBqQPASwFhebtn27gJnzKe75LmGk5OG0DyJIEdPNdVu9M j9i2GtGY/Yy9TvbBsny+EG7zGw3AZKJ+7RqLjE0m2d9GZKKqPCUKGEUpuXWoYMjfauxm 69jK8zvZRd+Z0lsNlPryaLMIMqV/ypK9gOJ5H1vgWi6Iw9Tb6Ip0doNvN6+Hbk/v7pW4 MlqvThV4nVAwI6baEPv0IzsOcKmEUOeIok4tQ18/isLPPVrOnBgQ6WH9oLRwDkPa8qUw 0m/A== X-Gm-Message-State: APjAAAXlf7vr7O0fYIzXRC+9aMxadhhTuUZoYmQTn4lOCROZU/v/i9SC WhBmbCZ0MDMZ4Ej3PF6stlc+S6KeGNcd578liVw= X-Google-Smtp-Source: APXvYqwCceqmLWc573BBfVPcQAxsQONnrfbjdcAMnSDjDUb9WY7G1gJ1DiJjC8eUtCIXmyXXwQuBOsOXJd3bHfVVLXA= X-Received: by 2002:a5d:9047:: with SMTP id v7mr18019549ioq.18.1564133200438; Fri, 26 Jul 2019 02:26:40 -0700 (PDT) MIME-Version: 1.0 References: <1D53CC7E-38A6-4F93-93F8-FE9227554B2B@tzi.org> In-Reply-To: <1D53CC7E-38A6-4F93-93F8-FE9227554B2B@tzi.org> From: Andrew Newton Date: Fri, 26 Jul 2019 05:26:29 -0400 Message-ID: To: Carsten Bormann Cc: Ulysse Carion , JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 09:26:43 -0000 On Thu, Jul 25, 2019 at 6:36 PM Carsten Bormann wrote: > > On Jul 25, 2019, at 18:12, Andrew Newton wrote: > > > > Due to the emergence of new formats such as TOML (to compete against > > YAML) and RCON and JSONLines to compete against JSON, > > A data definition language (what we call =E2=80=9Cschema language=E2=80= =9D here) describes data in a (generic) data model, not data serialized in = a format. The formats you mention have a high degree of commonality in the= ir generic data models, so I don=E2=80=99t know why a simple data definitio= n language cannot cover all of them [but then I don=E2=80=99t know RCON]. I agree with the concept. The IETF already has YANG. And things like GraphQL are fairly popular in the industry. So what work is left to do? -andy From nobody Fri Jul 26 14:19:47 2019 Return-Path: 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 8EE0F12006E for ; Fri, 26 Jul 2019 14:19:45 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 (2048-bit key) header.d=yahoo.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 o2UV2ouCHoZA for ; Fri, 26 Jul 2019 14:19:42 -0700 (PDT) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 9AC55120047 for ; Fri, 26 Jul 2019 14:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1564175981; bh=5gDkdtiitGyZCIPNbAxHb1lsUN6o3EqQq6oZndBtCW8=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=EsOW2eztUhI2prATwT4zolD50Whgt9flvT0THGD1y0T6+HYlWPe+RGYiBIMARnQwrfYsbWIsD6+AfHVuu7Lizbvzj4fMfH5ZdGyfKkg6xtfvysBMGRb2iTvim8xFF21A+PUUCpaoTYsJ7J1gy0e2k7OUhonA/bUP3FFtvjllniBsrykjPEb6fcx4nOJU5yjjMDGvIDtEqypIBUlfxJ2RdOO/AHabh1Uc2yubtehVJn6tbH5g+YzQfNA1NOXxofWAObOgKeCqkCHQIy6lNqY4gx6YifYd7dk2Bpi9iHavxh5Hlw1T/p0WUJ8uW6v7QCm62tlfZhgtu31pnlUc7tSq/g== X-YMail-OSG: TgmvQHQVM1lAX8oAqFK32wIsxiQXkom.PbxM_acUglBjEcL.DXULaEmjQiUJWMx JJW6kwG1QuaLdtfN8d1h6fkseylgyiy.Z45xlBp0lfGVFrI8gRbpO_MLsEhrh6RLvxUKdX2RLZQd yc..hmavg2xxvph8H0hiKumdA4W2kk5isSn90NlPabkWuZh32A2UX0msM_6nD7lAmISDv4y3oW7M eqQiFbewj2UVLkLQWGax_JrYlNaYGo3DCeZZpl7E3ECuP6iVzzwek9iTkfFJACWvOcDvFi7EAy94 bFqMlK6xwAjdZYrqSVHaN.G2pXtAt3znpqFK2mEUoLJHXuccDrXkmbYl5rnQG9XPPUt9OujgEdpu QvoKamnurqB0tNeY4TfO2asF14GjaAcAv66T.u.vBXx3.KDbHFXirFROwviTDRZA9dJQGEcIXP8u j8h5b5shfdD.Wr.TkSypYhzja2x8AwBXxT8KnjJxUrC_pJbkLBXg6QRZ5ENF75Pe62DPkusjjria ieZVeGtBHpJio0Fv6cetYNDYFoYgJxVmLybgFZQ_t54vKMFKBRMEnWUZ0umQ7Io16rMlsKiA.9rM KWvIrumRIThvjmF1eXA.200aaCeX2zVXjIGx8lssH0d5PtS68ZznACIGh.oIZTvx28ybB.MwtBqZ Mbg.GvTuVhlnQlzWS6zd4XgIaEVeNjkSGvjl0_eMvMDD.z4c9vNc4ILBGd0IPaaKuznPblALr2e5 2Pb26jn6q_SeC_j0.yitrzi3GaDfCIIIZhkuYl2KAI1RMFape9WkFOAK_K_lsOg58SnynXiMCSNA 64WaJwFKEjb2an0WcchB6uTeOIWBPznkTgIPiQAVIC8xqRCwkDh5r8kfBe3geO1dBGDFlRsJBYeh ZzMczY_fayvB1pyjp6eZO2THfNwjzUXGzA85us.jsu_zZoxyWZn8fyvrJNW4_XAzriOkItgulKgI BZggz1A_VF4Cid7VVv7jFfkAE0OriEN0.boRh.qV7D61RDUiKZ.sV1U338ZkIqrnMb7ysgCQ7tE9 zsh8kdFXC4Oh_jxIjU3X8uoCiD3FjisxtDjAfsUXZc2nvAFhdmSsa5f4oGYECpvBiYPQxQvZF.gU JbIwVB6ys4xkchzbr0jf_c8CjNpfmyvGe62w6eSq0rPM7L1t419lGIfG1e.6EjoU4HLP5uDt8ykz a6AT35B8xyGK8XLZYvCmcmdw.r0OEBf.SdFqp_wbexINZttCbGwT2W9LMr6lTTZcY Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Jul 2019 21:19:41 +0000 Date: Fri, 26 Jul 2019 21:19:39 +0000 (UTC) From: Henry Andrews Reply-To: Henry Andrews To: Anders Rundgren , JSON WG Message-ID: <542280484.639365.1564175979269@mail.yahoo.com> In-Reply-To: References: <14ac316b-0f79-02c1-91c0-e99538b4ca68@gmail.com> <429085535.787488.1564124880030@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_639364_364749842.1564175979267" X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36 Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 21:19:46 -0000 ------=_Part_639364_364749842.1564175979267 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Anders,=C2=A0 Could you show what those "JSON Number", "hex", etc. thin= gs would look like in a schema?=C2=A0 Are those keywords?=C2=A0 Values for = the "type" keyword?=C2=A0 Values for the "format" keyword?=C2=A0 Something = else? thanks,-henry PS- while I am receiving emails from the JSON list, my replies and new emai= ls seem to be disappearing (perhaps held for moderation?)=C2=A0 I had sent = a more extensive email about JSON Schema and JSL which would make more of w= hat I'm talking about with regards to "vocabularies" in this thread make se= nse.=C2=A0 Hopefully that will appear at some point. On Friday, July 26, 2019, 12:58:15 AM PDT, Anders Rundgren wrote: =20 =20 On 2019-07-26 09:08, Henry Andrews wrote: > Hi Anders, Hi Henry, >=C2=A0 =C2=A0 As long as you are not relying on the text representation of= JSON (e.g. using JSON numbers and needing to distinguish between 1, 1.0, a= nd 1.00) then you should be able to easily make a re-usable JSON Schema ext= ension vocabulary for this.=C2=A0 Since it sounds like you are using string= s to get around that problem, then it should be fine.=C2=A0 There is also a= lready a keyword to indicate encoded strings, including RFC 4648 base64url. I'm not particularly concerned about my own use of JSON, but about the abil= ity to for example expressing an RSA JWK [1] or an amount in PaymentRequest= [2] using some kind of JSON schema. >=C2=A0 =C2=A0 Some of these number-in-string issues have been proposed to = be solved with the "format" keyword, but "format" is kind of a disaster due= to its optional best-effort validation behavior.=C2=A0 We are making some = changes in this draft to try to make it more reliably predictable and give = schema authors some control over how it is processed, but we will be strong= ly encouraging people to write their own keyword vocabulary rather than cus= tom formats. I don't understand exactly what the problem is here.=C2=A0 IMO all integer = types could schema wise be treated identical (albeit some with warnings) an= d be supplied as: - JSON Number - "JSON Number" - "hex" - "base64" - "base64url" - "base58" Real numbers would probably only gain by the two first notations. The monetary type is separate from the rest. It has a very specific syntax = like a date type. This should cover 99% of existing and future JSON use cases.=C2=A0 Yes, thi= s is a slightly risky statement... Pardon for being somewhat low-level but if the low level isn't right, the u= pper parts tend to fall as well :-) thanx, Anders 1] https://tools.ietf.org/html/rfc7520#section-3.3 2] https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value >=20 >=C2=A0 =C2=A0 It's a lot easier to manage different keyword sets than to h= ave this one keyword into which everything higher-level data type somehow m= ust be shoved. >=20 >=C2=A0 =C2=A0 Once we have the new draft out, it would be an interesting t= est of the feature to see how easy it would be to design such a keyword voc= abulary. >=20 > thanks, > -henry >=20 >=20 > On Thursday, July 25, 2019, 11:16:03 PM PDT, Anders Rundgren wrote: >=20 >=20 > I'm still waiting (most likely in vain) for a JSON schema language > that better reflects the actual use of JSON, and in particular numbers. >=20 > That is: > - monetary types are distinct from other numbers since they don't build o= n FP math. > - big integers are in IETF standards (AFAIK without exceptions) expressed= as quoted strings which in turn may be coded as decimal, hex, base64url et= c. >=20 > Anders >=20 > On 2019-07-26 00:12, Andrew Newton wrote: >=C2=A0 > What relationship does this have with JSON Schema >=C2=A0 > (https://json-schema.org/)? Is it a separate effort (which it app= ears >=C2=A0 > to be)? There maybe a name collision here. I'll note that >=C2=A0 > json-schema.org has and continues to submit I-Ds. >=C2=A0 > >=C2=A0 > In the end, I believe no effort in the IETF to put a JSON ddl on = the >=C2=A0 > standards track would be legitimate without the involvement of >=C2=A0 > json-schema.org (I said as much in London when I presented JCR). = They >=C2=A0 > have a larger community than we have here and a specification bak= ed >=C2=A0 > into many tools. >=C2=A0 > >=C2=A0 > Giving this some more thought, the time for the IETF to be doing = a >=C2=A0 > JSON ddl may have passed. Discussions on the topic have been on a= nd >=C2=A0 > off for at least six years. In the meantime, JSON Schema >=C2=A0 > (json-schema.org) has made its way into many tools. Additionally, >=C2=A0 > other standards have materialized such as Swagger/OpenAPI to addr= ess >=C2=A0 > other aspects of JSON usage in REST, etc... >=C2=A0 > >=C2=A0 > Due to the emergence of new formats such as TOML (to compete agai= nst >=C2=A0 > YAML) and RCON and JSONLines to compete against JSON, it maybe th= at >=C2=A0 > the undiscovered territory is that which PHB has been pointing to= wards >=C2=A0 > for years: an abstraction language. But such a thing is far from = the >=C2=A0 > IETF's stomping grounds. >=C2=A0 > >=C2=A0 > -andy >=C2=A0 > >=C2=A0 > On Sun, Jul 21, 2019 at 11:37 PM Ulysse Carion > wrote: >=C2=A0 >> >=C2=A0 >> Hi all, >=C2=A0 >> >=C2=A0 >> I've just submitted an I-D of JSON Schema Language: >=C2=A0 >> >=C2=A0 >> https://tools.ietf.org/html/draft-json-schema-language-02 >=C2=A0 >> >=C2=A0 >> I believe this iteration is suited to be the penultimate draft; = I see no features in this spec worth adding, nor any features worth removin= g. I know of a few minor problems with the language in the spec, and those = issues are tracked on GitHub here. >=C2=A0 >> >=C2=A0 >> In this draft, I introduced fine-grained numerical types -- "flo= at32", "float64", "int8", "uint64", etc. -- because they are immensely usef= ul for real-world code generation. The spec details these types here (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. >=C2=A0 >> >=C2=A0 >> 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 o= ut of the robustness principle, and the fact that the alternative (consider= ing 10.0 unacceptable) is one which fewer will be able to enforce. Some imp= lementations may in practice be more restrictive in what they accept than t= he spec describes. I think that's acceptable; it seems clear that either ap= proach will lead to people deviating from the spec. >=C2=A0 >> >=C2=A0 >> Let me know what y'all think about JSON Schema Language as a who= le! If you relish in the concrete, here are working implementations of vali= dators built on this iteration of JSON Schema Language: >=C2=A0 >> >=C2=A0 >> https://github.com/json-schema-language/json-schema-language-go >=C2=A0 >> https://github.com/json-schema-language/json-schema-language-typ= escript >=C2=A0 >> https://github.com/json-schema-language/json-schema-language-rus= t >=C2=A0 >> >=C2=A0 >> 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. >=C2=A0 >> >=C2=A0 >> I view JSL as being nearly complete, so any and all criticism is= most welcome. >=C2=A0 >> >=C2=A0 >> Thanks, >=C2=A0 >> Ulysse >=C2=A0 >> _______________________________________________ >=C2=A0 >> json mailing list >=C2=A0 >> json@ietf.org >=C2=A0 >> https://www.ietf.org/mailman/listinfo/json >=C2=A0 > >=C2=A0 > _______________________________________________ >=C2=A0 > json mailing list >=C2=A0 > json@ietf.org >=C2=A0 > https://www.ietf.org/mailman/listinfo/json >=C2=A0 > >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json =20 ------=_Part_639364_364749842.1564175979267 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Anders,
  Could you show what those "JSON Number", = "hex", etc. things would look like in a schema?  Are those keywords?&n= bsp; Values for the "type" keyword?  Values for the "format" keyword?&= nbsp; Something else?

thanks,
-henry

PS- while I am receiving emails f= rom the JSON list, my replies and new emails seem to be disappearing (perha= ps held for moderation?)  I had sent a more extensive email about JSON= Schema and JSL which would make more of what I'm talking about with regard= s to "vocabularies" in this thread make sense.  Hopefully that will ap= pear at some point.

<= div>
=20
=20
On Friday, July 26, 2019, 12:58:15 AM PDT, Anders Rundg= ren <anders.rundgren.net@gmail.com> wrote:


On 2019-07-26 09:08, Henry Andrews wr= ote:
> Hi Anders,

Hi Henry,

>    As long a= s you are not relying on the text representation of JSON (e.g. using JSON n= umbers and needing to distinguish between 1, 1.0, and 1.00) then you should= be able to easily make a re-usable JSON Schema extension vocabulary for th= is.  Since it sounds like you are using strings to get around that pro= blem, then it should be fine.  There is also already a keyword to indi= cate encoded strings, including RFC 4648 base64url.

I'm not particularly concerned about my own use of JSON, but = about the ability to for example expressing an RSA JWK [1] or an amount in = PaymentRequest [2] using some kind of JSON schema.


>    Some of these number-in-s= tring issues have been proposed to be solved with the "format" keyword, but= "format" is kind of a disaster due to its optional best-effort validation = behavior.  We are making some changes in this draft to try to make it = more reliably predictable and give schema authors some control over how it = is processed, but we will be strongly encouraging people to write their own= keyword vocabulary rather than custom formats.

I don't understand exactly what the problem is here.  IMO al= l integer types could schema wise be treated identical (albeit some with wa= rnings) and be supplied as:
- JSON Number
- "JSON Number"
- "hex"
- "base64"- "base64url"
- "base58"

Real numbers would probably only gain by the two firs= t notations.

The monetary type is sepa= rate from the rest. It has a very specific syntax like a date type.

This should cover 99% of existing and future = JSON use cases.  Yes, this is a slightly risky statement...

Pardon for being somewhat low-level but if the= low level isn't right, the upper parts tend to fall as well :-)

thanx,
Anders

1] https://tools.= ietf.org/html/rfc7520#section-3.3
2] https://www.w3.org/TR/payment-re= quest/#dfn-valid-decimal-monetary-value


>
>    It's a l= ot easier to manage different keyword sets than to have this one keyword in= to which everything higher-level data type somehow must be shoved.
>
>    Once we have the new dr= aft out, it would be an interesting test of the feature to see how easy it = would be to design such a keyword vocabulary.
>
> thanks,
> -henry
&= gt;
>
> On Thursday, July 25, 2= 019, 11:16:03 PM PDT, Anders Rundgren <anders.ru= ndgren.net@gmail.com> wrote:
>
>
> I'm still waiting (most likely in vain) for= a JSON schema language
> that better reflects the act= ual use of JSON, and in particular numbers.
>
> That is:
> - monetary types are distin= ct from other numbers since they don't build on FP math.
= > - big integers are in IETF standards (AFAIK without exceptions) expres= sed as quoted strings which in turn may be coded as decimal, hex, base64url= etc.
>
> Anders
>
> On 2019-07-26 00:12, Andrew Newton wrote:>  > What relationship does this have with JSON= Schema
>  > (https://json-schema.= org/)? Is it a separate effort (which it appears
>=   > to be)? There maybe a name collision here. I'll note that
>  > json-schema.org has and continues to submit I-= Ds.
>  >
>  > In = the end, I believe no effort in the IETF to put a JSON ddl on the
>  > standards track would be legitimate without the i= nvolvement of
>  > json-schema.org (I said as = much in London when I presented JCR). They
>  >= ; have a larger community than we have here and a specification baked
>  > into many tools.
>  = >
>  > Giving this some more thought, the t= ime for the IETF to be doing a
>  > JSON ddl m= ay have passed. Discussions on the topic have been on and
>  > off for at least six years. In the meantime, JSON Schema>  > (json-schema.org) has made its way into ma= ny tools. Additionally,
>  > other standards h= ave materialized such as Swagger/OpenAPI to address
>&= nbsp; > other aspects of JSON usage in REST, etc...
&g= t;  >
>  > Due to the emergence of new= formats such as TOML (to compete against
>  >= YAML) and RCON and JSONLines to compete against JSON, it maybe that
>  > the undiscovered territory is that which PHB ha= s been pointing towards
>  > for years: an abs= traction language. But such a thing is far from the
>&= nbsp; > IETF's stomping grounds.
>  >
>  > -andy
>  >
>  > On Sun, Jul 21, 2019 at 11:37 PM Ulysse Carion = <ulysse@segment.com <mailto:ulysse@se= gment.com>> wrote:
>  >>
>  >> Hi all,
>  >>=
>  >> I've just submitted an I-D of JSON S= chema Language:
>  >>
>= ;  >> https://tools= .ietf.org/html/draft-json-schema-language-02
>&nbs= p; >>
>  >> 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 wi= th the language in the spec, and those issues are tracked on GitHub here.>  >>
>  >> = In this draft, I introduced fine-grained numerical types -- "float32", "flo= at64", "int8", "uint64", etc. -- because they are immensely useful for real= -world code generation. The spec details these types here (Table 2). "float= 32" and "float64" have no effect on validation versus "number", but they do= signal intent, and act as a hint for code generators.
&g= t;  >>
>  >> The question of JSO= N integers has been contentious in the past -- I explicitly call out that 1= 0.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 b= e more restrictive in what they accept than the spec describes. I think tha= t's acceptable; it seems clear that either approach will lead to people dev= iating from the spec.
>  >>
>  >> Let me know what y'all think about JSON Schema Langu= age as a whole! If you relish in the concrete, here are working implementat= ions 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
>  >>
>  >> Th= e GitHub org also contains tooling built on JSL, but they have not been upd= ated to support the fine-grained numerical types yet. I'll be working on th= at soon.
>  >>
> = >> I view JSL as being nearly complete, so any and all criticism is = most welcome.
>  >>
>&= nbsp; >> Thanks,
>  >> Ulysse
>  >> ____________________________________________= ___
>  >> json mailing list
>  >> json@ietf.org <mailto:json@i= etf.org>
>  >> https://www.ietf.org/mailman/listinfo/json
&= gt;  >
>  > __________________________= _____________________
>  > json mailing list>  > json@ietf.org <mailto:json@ietf.org>
>  > https://www.ietf.org/mailman/listinfo/json
>  >
>
> ________= _______________________________________
> json mailing= list
> json@ietf.org <mailto:= json@ietf.org>

> https:= //www.ietf.org/mailman/listinfo/json

_______________________________________________
json m= ailing list
json@ietf.org
<= a shape=3D"rect" href=3D"https://www.ietf.org/mailman/listinfo/json" rel=3D= "nofollow" target=3D"_blank">https://www.ietf.org/mailman/listinfo/json=
------=_Part_639364_364749842.1564175979267-- From nobody Fri Jul 26 14:20:48 2019 Return-Path: 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 72347120047 for ; Fri, 26 Jul 2019 14:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=yahoo.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 6MG7UEVcyuhn for ; Fri, 26 Jul 2019 14:20:43 -0700 (PDT) Received: from sonic306-3.consmr.mail.bf2.yahoo.com (sonic306-3.consmr.mail.bf2.yahoo.com [74.6.132.42]) (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 38964120071 for ; Fri, 26 Jul 2019 14:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1564176040; bh=jtY5QPlv3bj8N6G+DoS5UWwuv/QB01Fxs5uBRrwTpwk=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=rpM8crus8T0aki07dNz4Xdti7yQvW2SjTp3nXU/nHVA7GWEzS1PUFRE5V6XuGAAHXNEe7l2BQHkjlpILNmzk5T+e7pfx6rD30wihDF7rWvTd7vGap1gERmPj3OpgX2Tmf3OTUE/5Sla9bPUz2cTuD0MAt6LmhwK6APQJhl0i57ibnqfKqr3r+OhqrBRui19NlYeez62V9r0ilSWtxW6p8T1DPckRIDa/esxzwgm3vyFtfU279G7u+hTT0VZnJe3irN8MhVjc/SQ5tgtNfbZ9h9HkrNu/quN8zD2QuSPZox1La9nJz7cLNv6UV7ISNOPv4datUyf0R2BCUNmv/ZNy3g== X-YMail-OSG: YYeLKAcVM1n8x_NJSn6lnYo0mlIUk13wcUp9vbvSDCXixRktt2UPCLbst59XHdx DHXAkuRH8SCFmVDCpDm.3GHdMIspTF2ESDuls0iEqHwkLbaNj8E2qol2HduDvuQNoW22SYb2dOMT zPD.M0RDIxu88ea2TFHBVe5WP6QHGawsADA4oHDJQBLz5yDT3w.HkDOdIw0wpMZgVyP8SpcmKzGB Gh4zrygPImVyGlge8MknH_TcEht1ZJ9CXbAO1vCIK1v4qo9fOneDov82FfKc_4WHWyCLtdkU5AmS M0ccwsRQXyoInyZfrKQrs3963NAiYvzEIHIDt3TjMX.3zviaWDdmdaUJShsqiZLR1.1HWpZ2xCFE 1jjtSIhClg8C7O5uJe6YSWRYPJms9tKCaoVjRJ.KLE0yvcUZlTkCUvcztqkK5jkRf4gj9G_OGwPW w.DZ3VxEUB8YqVZvrU2VAO7bcRezLMOL3ql95y5JLM4BO6hEu8V7ZOnijFLkqU3CN6YFhIM4WwFn QU8a1.E_ANCw7ux7APd68B6mLb4RggzWQVfMakd8k.360xPsjlpjpbBJoVbN1PMpHhn7bFObUFEw zXtrT1EA9bRFUgW88GROCgdwXY7fOmV9AZEZsKewRx50V7y6AfjQKYUyiI4XzkeEeJ.4zKnQg_p2 mcayEoBagYlsW59qsqgFP86.HOtjlfo3YOA_tEHXwJNMstspXXLreFLd7QNJ45rE3JWXFG7vuAoT 8ii3.i35xUTQrDo2dbYe6gEFoAvpJpiRuopRgvyUWFLxVJnDfouxtc7QKDa4mKfW0RcyfxS6Dk1r mbQQAHEwFmaZYP9tsW7HBE7Wzqu5w.EIrRrACh0vplhmmaNYD2aBQF5kL1tge.dBdOY1TbH9yGKT pEJbmykWU.MZO8YKMXdK4_kx5iX7ABNNEKG6ri_iSuCJjC8drg9q_QB9uzqRN6ELk8mhLwvsu8aV SYGdCTLyXfQCm9Tyg0bqY.PUkVS92_iUyLEwZH67GP97ATgD_Z1okI1Ij5sZxhAIx72YlrN5H9oX Y42QbXJOo2VyoRwGQ59lxgFf5VlruzsM6XfPcc8UyCrfoLavVkb9qL4I8AfMxPM9OGhGW2pnNgnH q2kFciSyM2ksO4kz32R2B5a6YoFl_L7Y9a_6FzkNtpRn.3Ze0gdfA0jmkOTepgGwoAY9stcupvta .vIeBx_A2aGgIUyGrHvLXXSUrjsP.RtydIDx0L.dg6PzevRSS4xj.6LaYwbLutn6shMqK Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Jul 2019 21:20:40 +0000 Date: Fri, 26 Jul 2019 21:20:37 +0000 (UTC) From: Henry Andrews Reply-To: Henry Andrews To: Anders Rundgren , JSON WG Message-ID: <1257074036.701246.1564176037853@mail.yahoo.com> In-Reply-To: <542280484.639365.1564175979269@mail.yahoo.com> References: <14ac316b-0f79-02c1-91c0-e99538b4ca68@gmail.com> <429085535.787488.1564124880030@mail.yahoo.com> <542280484.639365.1564175979269@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_701245_1379756573.1564176037850" X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36 Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 21:20:47 -0000 ------=_Part_701245_1379756573.1564176037850 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oh hey this reply worked... I guess I'll re-send that other one? On Friday, July 26, 2019, 02:19:55 PM PDT, Henry Andrews wrote: =20 =20 Hi Anders,=C2=A0 Could you show what those "JSON Number", "hex", etc. thi= ngs would look like in a schema?=C2=A0 Are those keywords?=C2=A0 Values for= the "type" keyword?=C2=A0 Values for the "format" keyword?=C2=A0 Something= else? thanks,-henry PS- while I am receiving emails from the JSON list, my replies and new emai= ls seem to be disappearing (perhaps held for moderation?)=C2=A0 I had sent = a more extensive email about JSON Schema and JSL which would make more of w= hat I'm talking about with regards to "vocabularies" in this thread make se= nse.=C2=A0 Hopefully that will appear at some point. On Friday, July 26, 2019, 12:58:15 AM PDT, Anders Rundgren wrote: =20 =20 On 2019-07-26 09:08, Henry Andrews wrote: > Hi Anders, Hi Henry, >=C2=A0 =C2=A0 As long as you are not relying on the text representation of= JSON (e.g. using JSON numbers and needing to distinguish between 1, 1.0, a= nd 1.00) then you should be able to easily make a re-usable JSON Schema ext= ension vocabulary for this.=C2=A0 Since it sounds like you are using string= s to get around that problem, then it should be fine.=C2=A0 There is also a= lready a keyword to indicate encoded strings, including RFC 4648 base64url. I'm not particularly concerned about my own use of JSON, but about the abil= ity to for example expressing an RSA JWK [1] or an amount in PaymentRequest= [2] using some kind of JSON schema. >=C2=A0 =C2=A0 Some of these number-in-string issues have been proposed to = be solved with the "format" keyword, but "format" is kind of a disaster due= to its optional best-effort validation behavior.=C2=A0 We are making some = changes in this draft to try to make it more reliably predictable and give = schema authors some control over how it is processed, but we will be strong= ly encouraging people to write their own keyword vocabulary rather than cus= tom formats. I don't understand exactly what the problem is here.=C2=A0 IMO all integer = types could schema wise be treated identical (albeit some with warnings) an= d be supplied as: - JSON Number - "JSON Number" - "hex" - "base64" - "base64url" - "base58" Real numbers would probably only gain by the two first notations. The monetary type is separate from the rest. It has a very specific syntax = like a date type. This should cover 99% of existing and future JSON use cases.=C2=A0 Yes, thi= s is a slightly risky statement... Pardon for being somewhat low-level but if the low level isn't right, the u= pper parts tend to fall as well :-) thanx, Anders 1] https://tools.ietf.org/html/rfc7520#section-3.3 2] https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value >=20 >=C2=A0 =C2=A0 It's a lot easier to manage different keyword sets than to h= ave this one keyword into which everything higher-level data type somehow m= ust be shoved. >=20 >=C2=A0 =C2=A0 Once we have the new draft out, it would be an interesting t= est of the feature to see how easy it would be to design such a keyword voc= abulary. >=20 > thanks, > -henry >=20 >=20 > On Thursday, July 25, 2019, 11:16:03 PM PDT, Anders Rundgren wrote: >=20 >=20 > I'm still waiting (most likely in vain) for a JSON schema language > that better reflects the actual use of JSON, and in particular numbers. >=20 > That is: > - monetary types are distinct from other numbers since they don't build o= n FP math. > - big integers are in IETF standards (AFAIK without exceptions) expressed= as quoted strings which in turn may be coded as decimal, hex, base64url et= c. >=20 > Anders >=20 > On 2019-07-26 00:12, Andrew Newton wrote: >=C2=A0 > What relationship does this have with JSON Schema >=C2=A0 > (https://json-schema.org/)? Is it a separate effort (which it app= ears >=C2=A0 > to be)? There maybe a name collision here. I'll note that >=C2=A0 > json-schema.org has and continues to submit I-Ds. >=C2=A0 > >=C2=A0 > In the end, I believe no effort in the IETF to put a JSON ddl on = the >=C2=A0 > standards track would be legitimate without the involvement of >=C2=A0 > json-schema.org (I said as much in London when I presented JCR). = They >=C2=A0 > have a larger community than we have here and a specification bak= ed >=C2=A0 > into many tools. >=C2=A0 > >=C2=A0 > Giving this some more thought, the time for the IETF to be doing = a >=C2=A0 > JSON ddl may have passed. Discussions on the topic have been on a= nd >=C2=A0 > off for at least six years. In the meantime, JSON Schema >=C2=A0 > (json-schema.org) has made its way into many tools. Additionally, >=C2=A0 > other standards have materialized such as Swagger/OpenAPI to addr= ess >=C2=A0 > other aspects of JSON usage in REST, etc... >=C2=A0 > >=C2=A0 > Due to the emergence of new formats such as TOML (to compete agai= nst >=C2=A0 > YAML) and RCON and JSONLines to compete against JSON, it maybe th= at >=C2=A0 > the undiscovered territory is that which PHB has been pointing to= wards >=C2=A0 > for years: an abstraction language. But such a thing is far from = the >=C2=A0 > IETF's stomping grounds. >=C2=A0 > >=C2=A0 > -andy >=C2=A0 > >=C2=A0 > On Sun, Jul 21, 2019 at 11:37 PM Ulysse Carion > wrote: >=C2=A0 >> >=C2=A0 >> Hi all, >=C2=A0 >> >=C2=A0 >> I've just submitted an I-D of JSON Schema Language: >=C2=A0 >> >=C2=A0 >> https://tools..ietf.org/html/draft-json-schema-language-02 >=C2=A0 >> >=C2=A0 >> I believe this iteration is suited to be the penultimate draft; = I see no features in this spec worth adding, nor any features worth removin= g. I know of a few minor problems with the language in the spec, and those = issues are tracked on GitHub here. >=C2=A0 >> >=C2=A0 >> In this draft, I introduced fine-grained numerical types -- "flo= at32", "float64", "int8", "uint64", etc. -- because they are immensely usef= ul for real-world code generation. The spec details these types here (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. >=C2=A0 >> >=C2=A0 >> 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 o= ut of the robustness principle, and the fact that the alternative (consider= ing 10.0 unacceptable) is one which fewer will be able to enforce. Some imp= lementations may in practice be more restrictive in what they accept than t= he spec describes. I think that's acceptable; it seems clear that either ap= proach will lead to people deviating from the spec. >=C2=A0 >> >=C2=A0 >> Let me know what y'all think about JSON Schema Language as a who= le! If you relish in the concrete, here are working implementations of vali= dators built on this iteration of JSON Schema Language: >=C2=A0 >> >=C2=A0 >> https://github.com/json-schema-language/json-schema-language-go >=C2=A0 >> https://github.com/json-schema-language/json-schema-language-typ= escript >=C2=A0 >> https://github.com/json-schema-language/json-schema-language-rus= t >=C2=A0 >> >=C2=A0 >> 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. >=C2=A0 >> >=C2=A0 >> I view JSL as being nearly complete, so any and all criticism is= most welcome. >=C2=A0 >> >=C2=A0 >> Thanks, >=C2=A0 >> Ulysse >=C2=A0 >> _______________________________________________ >=C2=A0 >> json mailing list >=C2=A0 >> json@ietf.org >=C2=A0 >> https://www.ietf.org/mailman/listinfo/json >=C2=A0 > >=C2=A0 > _______________________________________________ >=C2=A0 > json mailing list >=C2=A0 > json@ietf.org >=C2=A0 > https://www.ietf.org/mailman/listinfo/json >=C2=A0 > >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json =20 ------=_Part_701245_1379756573.1564176037850 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh hey this reply worked... = I guess I'll re-send that other one?

=20
=20
On Friday, July 26, 2019, 02:19:55 PM PDT, Henry Andrew= s <andrews_henry=3D40yahoo.com@dmarc.ietf.org> wrote:


Hi Anders,
  Could you = show what those "JSON Number", "hex", etc. things would look like in a sche= ma?  Are those keywords?  Values for the "type" keyword?  Va= lues for the "format" keyword?  Something else?
=
thanks,
-he= nry

PS- whi= le I am receiving emails from the JSON list, my replies and new emails seem= to be disappearing (perhaps held for moderation?)  I had sent a more = extensive email about JSON Schema and JSL which would make more of what I'm= talking about with regards to "vocabularies" in this thread make sense.&nb= sp; Hopefully that will appear at some point.


=20
=20
On Friday, July 26, 2019, 12:58:15 AM PDT, Anders Rundg= ren <anders.rundgren.net@gmail.com> wrote:


On 2019-07-26 09:08, Henry Andrews wr= ote:
> Hi Anders,

Hi Henry,

>    As long a= s you are not relying on the text representation of JSON (e.g. using JSON n= umbers and needing to distinguish between 1, 1.0, and 1.00) then you should= be able to easily make a re-usable JSON Schema extension vocabulary for th= is.  Since it sounds like you are using strings to get around that pro= blem, then it should be fine.  There is also already a keyword to indi= cate encoded strings, including RFC 4648 base64url.

I'm not particularly concerned about my own use of JSON, but = about the ability to for example expressing an RSA JWK [1] or an amount in = PaymentRequest [2] using some kind of JSON schema.


>    Some of these number-in-s= tring issues have been proposed to be solved with the "format" keyword, but= "format" is kind of a disaster due to its optional best-effort validation = behavior.  We are making some changes in this draft to try to make it = more reliably predictable and give schema authors some control over how it = is processed, but we will be strongly encouraging people to write their own= keyword vocabulary rather than custom formats.

I don't understand exactly what the problem is here.  IMO al= l integer types could schema wise be treated identical (albeit some with wa= rnings) and be supplied as:
- JSON Number
- "JSON Number"
- "hex"
- "base64"- "base64url"
- "base58"

Real numbers would probably only gain by the two firs= t notations.

The monetary type is sepa= rate from the rest. It has a very specific syntax like a date type.

This should cover 99% of existing and future = JSON use cases.  Yes, this is a slightly risky statement...

Pardon for being somewhat low-level but if the= low level isn't right, the upper parts tend to fall as well :-)

thanx,
Anders

1] https://tools.= ietf.org/html/rfc7520#section-3.3
2] https://www.w3.org/TR/payment-re= quest/#dfn-valid-decimal-monetary-value


>
>    It's a l= ot easier to manage different keyword sets than to have this one keyword in= to which everything higher-level data type somehow must be shoved.
>
>    Once we have the new dr= aft out, it would be an interesting test of the feature to see how easy it = would be to design such a keyword vocabulary.
>
> thanks,
> -henry
&= gt;
>
> On Thursday, July 25, 2= 019, 11:16:03 PM PDT, Anders Rundgren <anders.ru= ndgren.net@gmail.com> wrote:
>
>
> I'm still waiting (most likely in vain) for= a JSON schema language
> that better reflects the act= ual use of JSON, and in particular numbers.
>
> That is:
> - monetary types are distin= ct from other numbers since they don't build on FP math.
= > - big integers are in IETF standards (AFAIK without exceptions) expres= sed as quoted strings which in turn may be coded as decimal, hex, base64url= etc.
>
> Anders
>
> On 2019-07-26 00:12, Andrew Newton wrote:>  > What relationship does this have with JSON= Schema
>  > (https://json-schema.= org/)? Is it a separate effort (which it appears
>=   > to be)? There maybe a name collision here. I'll note that
>  > json-schema.org has and continues to submit I-= Ds.
>  >
>  > In = the end, I believe no effort in the IETF to put a JSON ddl on the
>  > standards track would be legitimate without the i= nvolvement of
>  > json-schema.org (I said as = much in London when I presented JCR). They
>  >= ; have a larger community than we have here and a specification baked
>  > into many tools.
>  = >
>  > Giving this some more thought, the t= ime for the IETF to be doing a
>  > JSON ddl m= ay have passed. Discussions on the topic have been on and
>  > off for at least six years. In the meantime, JSON Schema>  > (json-schema.org) has made its way into ma= ny tools. Additionally,
>  > other standards h= ave materialized such as Swagger/OpenAPI to address
>&= nbsp; > other aspects of JSON usage in REST, etc...
&g= t;  >
>  > Due to the emergence of new= formats such as TOML (to compete against
>  >= YAML) and RCON and JSONLines to compete against JSON, it maybe that
>  > the undiscovered territory is that which PHB ha= s been pointing towards
>  > for years: an abs= traction language. But such a thing is far from the
>&= nbsp; > IETF's stomping grounds.
>  >
>  > -andy
>  >
>  > On Sun, Jul 21, 2019 at 11:37 PM Ulysse Carion = <ulysse@segment.com <mailto:ulysse@se= gment.com>> wrote:
>  >>
>  >> Hi all,
>  >>=
>  >> I've just submitted an I-D of JSON S= chema Language:
>  >>
>= ;  >> https://tools= ..ietf.org/html/draft-json-schema-language-02
>&nb= sp; >>
>  >> I believe this iteration= is suited to be the penultimate draft; I see no features in this spec wort= h adding, nor any features worth removing. I know of a few minor problems w= ith the language in the spec, and those issues are tracked on GitHub here.<= br clear=3D"none">>  >>
>  >>= In this draft, I introduced fine-grained numerical types -- "float32", "fl= oat64", "int8", "uint64", etc. -- because they are immensely useful for rea= l-world code generation. The spec details these types here (Table 2). "floa= t32" and "float64" have no effect on validation versus "number", but they d= o signal intent, and act as a hint for code generators.
&= gt;  >>
>  >> The question of JS= ON 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 principl= e, 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 th= at's acceptable; it seems clear that either approach will lead to people de= viating from the spec.
>  >>
>  >> Let me know what y'all think about JSON Schema Lang= uage as a whole! If you relish in the concrete, here are working implementa= tions of validators built on this iteration of JSON Schema Language:
>  >>
>  >> https://github.com/json-schem= a-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>  >>
>  >> T= he GitHub org also contains tooling built on JSL, but they have not been up= dated to support the fine-grained numerical types yet. I'll be working on t= hat soon.
>  >>
> = ; >> I view JSL as being nearly complete, so any and all criticism is= most welcome.
>  >>
>=   >> Thanks,
>  >> Ulysse
>  >> ___________________________________________= ____
>  >> json mailing list
>  >> json@ietf.org <mailto:json@i= etf.org>
>  >> https://www.ietf.org/mailman/listinfo/json
=
>  >
>  > ______= _________________________________________
>  >= json mailing list
>  > json@ietf.org= <mailto:json@ietf.org>
>  = > https://www.ietf.org/mailman/listinfo/js= on
>  >
>
> _______________________________________________
> json mailing list
> json@ietf.org<= /a> <mailto:json@ietf.org>

> https://ww= w.ietf.org/mailman/listinfo/json

_= ______________________________________________
json maili= ng list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
_______________________________________________<= br clear=3D"none">json mailing list
json@ietf.org=
https://www.ietf.org/m= ailman/listinfo/json
------=_Part_701245_1379756573.1564176037850-- From nobody Fri Jul 26 14:29:09 2019 Return-Path: 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 75D9A12006E for ; Fri, 26 Jul 2019 14:29:08 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 1EYTAGYKaUQ7 for ; Fri, 26 Jul 2019 14:29:05 -0700 (PDT) Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (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 0CE49120047 for ; Fri, 26 Jul 2019 14:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1564176544; bh=N6UsfAj6E/1Laov/myHqrA37z/D5V5Y4CFmZYX3WikM=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=oKNygbaYSgQE+ZSMz48B9+yemOv5MdS+Jv3ZLMXfCYbgFtVztqTJJ6Eza6I3fF93oqBF8bKIsbd+Z3Ht0t2BSmSAQQzxcLIabn2UwaZa7Nld65+Dp/kfXV/Ijk6XmOsoSBgARl08n1NJx+qeq5hnzoJ5OTy9hGqKr4xbAy5ohpXzW6pL1hv1OalCglxw7MvrRywH4xkfAizkJTZH7GFWiYINAJmQsGZeX8LQ5fhtZfKCRT9qS1NmS2OPb9UydFTUdP1szHCDgkc77eOjc4ddoFdj6DMPLit1nPJCzD2yvDx3Pejq1qxa2xmUjzNS8WHxW6rtkkc1xYGCQUbfFn9Kug== X-YMail-OSG: 7DOMQ.sVM1kl.wPoBmpS0WltxpzZCEnqMEDr.7j__R7dTZSpCmifTOO8NdpsLZW uqF68FobXNHTeN8jcov6ZAFOgpv8Bh3VL7jKKF1OkBsnsZdiGZZZmMEdW7_WWegF1WzWjZnZtFM5 kSlWJeN5Eq.RP4tzEzd90lGT8kFk_dJJ97WF2PixKBki79GPNuR3EMQ3dIVTMGVJf_cfMI5.cDKV kEePEUVHUpi0mMOZUmpbAJIGd_ORh5XYrDx3Vzir9wTEmlWshfyQqLOBOXpUzmYfxSqe9txAZhIT 06cyR8AYop_xEFdQDsMgQqhxeK9X02TRF_6Zw7nxeOAR9hoLVLD6gmtjm5DIpe2IiLzFqMhEd.X_ m2x8pEqCo.gGqF47O1xPYphROHdAzGvOFiE49GitJHPmYGEu8OG1mNdhmHU2xvPLimJNEagNKBfQ Kmd8qyh71BIxFvFV3VyeEp_sFDnTPb9JywqsG1j8RdOqL1fOwh02fXrbw4hlxbTHvqkVgTCt5H8G 2UwvgpSQKWlNc4.wSI4Jo34WeUTiNu39FVH9A_eFULZEVM9zzllcbI2BlzgK87hzr8aYb2RnwtYy SYG7jhiyhD_LUu45PYkvHf9D0DfDFMhZKyLEYVzEIcRNzIFi_QTdUIJX1rTsvjreUOmg3sNfdfey iAtREKUPfZ_FsFxdFdKqVjLrqMBGn7AvCzKR9whg8H9g0A_0oCU6nUWbjloWlsdYwlHtweYniMFD 7_4YPBY_apJ5CrFBvxcV2eq3bbiw46NUYBhs.TwWrqgHX8_s95XacdbgKKV5M2qXKghzDD5kz7bf IR0HX6lPOiV6MsduItzavSuwPE3oeK1wRuCPqH79eXIEVTuMFy.XeRoym68R2D.Ausr0wykZtdIO 2BLCfwdeusTPFbrxdFb7zbSEMvChejpl1NxuVqAYEWLAitm8ExVGCGPcD8NNac80R46mRBthuLDs sHP1la5LMCoL2n_SFp76A5mGyNl0WskZV6V1AW8kc1b_d3F0GIC.MIKKnWbwVV8CQoOYIz6GkLDH q_Sx0MXEGf_wui2oh.oCVIZKrb9DYL1_QVEFS_cCLFd5620Xakt.h7qhiobHgqKAiCXsqk3Y4fm5 y0BjEJHgcYyEFZfSh.jT2WU7zHC4lZlhiFzfuRqDFtAh7z2EEP.Q5rubSIKzfYKOvn0Nw46LBLX5 2jliJVMPwGg0Cxp52Ci5jt3fflccB4BPWd6XMHamzAWjjuAHCQwZLs5QulI_oXcPG Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Jul 2019 21:29:04 +0000 Date: Fri, 26 Jul 2019 21:28:29 +0000 (UTC) From: Henry Andrews Reply-To: Henry Andrews To: Andrew Newton , JSON WG Message-ID: <1264668892.999441.1564176509455@mail.yahoo.com> In-Reply-To: References: <1D53CC7E-38A6-4F93-93F8-FE9227554B2B@tzi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_999440_1735768794.1564176509453" X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36 Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 21:29:08 -0000 ------=_Part_999440_1735768794.1564176509453 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi folks,=C2=A0 I'm one of the current authors/editors of the JSON Schema= specification, along with Austin Wright, Ben Hutton, and Greg Dennis.=C2= =A0=C2=A0 =C2=A0 Andy Newman brought yesterday's thread about JSON Schema Language to= our attention, and I see that he asked about the relationship between JSL = and JSON Schema earlier in the thread here. =C2=A0 There is no relationship between the projects, aside from obviously = drawing on some common ideas.=C2=A0 JSL also draws on some ideas that we de= cided to exclude from JSON Schema.=C2=A0 Ulysse discussed some ideas with u= s a while back but it became clear that our current direction was not what = he was looking for.=C2=A0 I encouraged him to build his own system, as JSON= Schema has a large user base, and some things that he wanted changed would= be too disruptive to that user base.=C2=A0 IIRC (and feel free to correct = if I'm misremembering this, Ulysse), he also disagreed with some key featur= es in the next draft.=C2=A0 Since those features were developed in coordina= tion with large user communities such as OpenAPI, we were not willing to dr= op them based on anyone's individual objections. =C2=A0 My only concern with the JSON Schema Language project is the name: w= hile JSON Schema is purely a series of individual drafts and therefore has = no official IETF status or approval, the name "JSON Schema" has a long hist= ory and a large user base.=C2=A0 Putting out a similar project with a nearl= y-identical name will be very confusing and, in my opinion, bad form.=C2=A0= Contrast with JSON Schema and JSON Content Rules which can easily co-exist= without confusion. =C2=A0 Might I suggest "JSON Definition Language", as the system is primari= ly oriented towards definitions for code generation and the like? =C2=A0 Anyway, if Ulysse calls it something else then, speaking for myself = and not for the whole JSON Schema project, I don't have any problems with J= SL at all. =C2=A0 Andy wrote in his email here about wanting us involved in any standa= rds-track JSON DDL, which I appreciate, but there are a couple of concerns = that make that unlikely.=C2=A0 At least right now. 1.=C2=A0 JSON Schema is not really a data definition language, at least not= in its current form.=C2=A0 It was originally constructed as a constraint s= ystem, with a vaguely-defined concept of annotating instances with other (p= ossibly dynamic, e.g. Hyper-Schema) data.=C2=A0 Next month's draft finishes= formalizing the annotation concept so that it can be interoperable, and fo= rmalizes an extensibility mechanism. =C2=A0 This extensibility mechanism will allow defining a data definition v= ocabulary through annotations within the JSON Schema system, but that will = be further work and presumably be an additional spec on top of the Validati= on spec (again, similar to how Hyper-Schema builds on Validation).=C2=A0 Th= is work on extensibility is primarily motivated by systems such as OpenAPI = code generators and various web form generator libraries, which are otherwi= se an awkward fit. =C2=A0 In another thread, Tim Bray asked if JSL was a compatible subset of = JSON Schema- it is not.=C2=A0 The extensibility mechanism in the forthcomin= g draft does allow constraining JSON Schema in certain ways to define subse= ts (for example if the anyOf/allOf/oneOf/not/if/then/else keywords are not = suitable for some use cases, they could be forbidden without otherwise chan= ging the keyword syntax or semantics).=C2=A0 If the desire is simply to sub= set JSON Schema, there is no need for a separate project. 2.=C2=A0 The last time we checked in with this mailing list, we were told t= hat the JSON working group (or some successor group- I'm a little unclear o= n that) would not be interested in adopting JSON Schema in anything resembl= ing its current form for a Standards Track RFC.=C2=A0 I think Ben (one of t= he other editors) is planning to check back in here on that topic after we = get the next draft out the door, but given our large and well-established u= ser community, discarding what we have is not an option.=C2=A0 Perhaps an I= nformational RFC would be more appropriate, as my understanding is that the= y "may be appropriate when republishing standards produced by a standards b= ody other than the IETF, industry consortia or companies."=C2=A0 (I suppose= the JSON Schema org may be considered an "industry consortia" under a suff= iciently permissive definition :-) =C2=A0 So (again, speaking for myself), I have been assuming that the worki= ng group would at some point start a new project or adopt another project t= han ours (JCR, JSL, whatever).=C2=A0 If relatively simple data definition i= s the only thing that you want, then it would of course be possible to writ= e a more focused system than JSON Schema. =C2=A0 As for the status of JSON Schema, we are indeed still an active proj= ect, and expect to publish a new draft during August.=C2=A0 The regrettable= delay that has left us in an expired draft state for the past half-year wa= s the result of a series of personal difficulties on my side, but fortunate= ly other community members have stepped up to help.=C2=A0 Most of the curre= nt core contributors have been involved since October 2016's draft-wright-j= son-schema-00, and I'm not disappearing entirely, so there is considerable = continuity. =C2=A0 The primary goal of the August draft is to get feedback on the exten= sibility mechanism, the recommended output/error format, and a few other ma= jor new features.=C2=A0 I expect there will be one further significant draf= t (or cluster of small updates so we don't have another big gap) to finish = the extensibility work based on that feedback, at which point hopefully we = can declare the Core and Validation specifications "done", whether that mea= ns publishing some sort of final document or entering a more formal standar= ds process.=C2=A0 Hyper-Schema is on a different timeline, and will not blo= ck Core or Validation. =C2=A0 Please let me know if you have any questions. thanks,-henry ------=_Part_999440_1735768794.1564176509453 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,
  I'm one of the current auth= ors/editors of the JSON Schema specification, along with Austin Wright, Ben= Hutton, and Greg Dennis.  

  Andy Newman brought yesterday's thread about JSON Schema= Language to our attention, and I see that he asked about the relationship = between JSL and JSON Schema earlier in the thread here.

  There is no relationship between the p= rojects, aside from obviously drawing on some common ideas.  JSL also = draws on some ideas that we decided to exclude from JSON Schema.  Ulys= se discussed some ideas with us a while back but it became clear that our c= urrent direction was not what he was looking for.  I encouraged him to= build his own system, as JSON Schema has a large user base, and some thing= s that he wanted changed would be too disruptive to that user base.  I= IRC (and feel free to correct if I'm misremembering this, Ulysse), he also = disagreed with some key features in the next draft.  Since those featu= res were developed in coordination with large user communities such as Open= API, we were not willing to drop them based on anyone's individual objectio= ns.

  My only concern= with the JSON Schema Language project is the name: while JSON Schema is pu= rely a series of individual drafts and therefore has no official IETF statu= s or approval, the name "JSON Schema" has a long history and a large user b= ase.  Putting out a similar project with a nearly-identical name will = be very confusing and, in my opinion, bad form.  Contrast with JSON Sc= hema and JSON Content Rules which can easily co-exist without confusion.

  Might I suggest "JSON= Definition Language", as the system is primarily oriented towards definiti= ons for code generation and the like?

  Anyway, if Ulysse calls it something else then, speaking= for myself and not for the whole JSON Schema project, I don't have any pro= blems with JSL at all.

&nb= sp; Andy wrote in his email here about wanting us involved in any standards= -track JSON DDL, which I appreciate, but there are a couple of concerns tha= t make that unlikely.  At least right now.

<= /div>
1.  JSON Schema is not really a data definition = language, at least not in its current form.  It was originally constru= cted as a constraint system, with a vaguely-defined concept of annotating i= nstances with other (possibly dynamic, e.g. Hyper-Schema) data.  Next = month's draft finishes formalizing the annotation concept so that it can be= interoperable, and formalizes an extensibility mechanism.

  This extensibility mechanism will a= llow defining a data definition vocabulary through annotations within the J= SON Schema system, but that will be further work and presumably be an addit= ional spec on top of the Validation spec (again, similar to how Hyper-Schem= a builds on Validation).  This work on extensibility is primarily moti= vated by systems such as OpenAPI code generators and various web form gener= ator libraries, which are otherwise an awkward fit.
<= br>
  In another thread, Tim Bray asked if JSL w= as a compatible subset of JSON Schema- it is not.  The extensibility m= echanism in the forthcoming draft does allow constraining JSON Schema in ce= rtain ways to define subsets (for example if the anyOf/allOf/oneOf/not/if/t= hen/else keywords are not suitable for some use cases, they could be forbid= den without otherwise changing the keyword syntax or semantics).  If t= he desire is simply to subset JSON Schema, there is no need for a separate = project.

2.  The last= time we checked in with this mailing list, we were told that the JSON work= ing group (or some successor group- I'm a little unclear on that) would not= be interested in adopting JSON Schema in anything resembling its current f= orm for a Standards Track RFC.  I think Ben (one of the other editors)= is planning to check back in here on that topic after we get the next draf= t out the door, but given our large and well-established user community, di= scarding what we have is not an option.  Perhaps an Informational RFC = would be more appropriate, as my understanding is that they "may be appropr= iate when republishing standards produced by a standards body other than th= e IETF, industry consortia or companies."  (I suppose the JSON Schema = org may be considered an "industry consortia" under a sufficiently permissi= ve definition :-)

  So (again, speaking for myself), I have been assuming = that the working group would at some point start a new project or adopt ano= ther project than ours (JCR, JSL, whatever).  If relatively simple dat= a definition is the only thing that you want, then it would of course be po= ssible to write a more focused system than JSON Schema.

  As for the status of JSON Schema,= we are indeed still an active project, and expect to publish a new draft d= uring August.  The regrettable delay that has left us in an expired dr= aft state for the past half-year was the result of a series of personal dif= ficulties on my side, but fortunately other community members have stepped = up to help.  Most of the current core contributors have been involved = since October 2016's draft-wright-json-schema-00, and I'm not disappearing = entirely, so there is considerable continuity.

  The primary goal of= the August draft is to get feedback on the extensibility mechanism, the re= commended output/error format, and a few other major new features.  I = expect there will be one further significant draft (or cluster of small upd= ates so we don't have another big gap) to finish the extensibility work bas= ed on that feedback, at which point hopefully we can declare the Core and V= alidation specifications "done", whether that means publishing some sort of= final document or entering a more formal standards process.  Hyper-Sc= hema is on a different timeline, and will not block Core or Validation.

 = ; Please let me know if you have any questions.

thanks,
-henry

------=_Part_999440_1735768794.1564176509453-- From nobody Fri Jul 26 14:32:25 2019 Return-Path: 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 DF5CA120100 for ; Fri, 26 Jul 2019 14:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=yahoo.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 YYr60G9S714Z for ; Fri, 26 Jul 2019 14:32:22 -0700 (PDT) Received: from sonic303-3.consmr.mail.bf2.yahoo.com (sonic303-3.consmr.mail.bf2.yahoo.com [74.6.131.42]) (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 F2666120071 for ; Fri, 26 Jul 2019 14:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1564176741; bh=Q/NGAoGmeXXWE68nHLaViYlY+AewRMN2LBsN4ZkieZM=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Uc1uWwpzMLBWXJGilF0PXL3JLcoN2FiF+81icfkslE8SA/o75vBtEYVmX6/ELj5Pt+U4NKo4Sla0vtB2c3fbn7j3u9L+sy1YeCl4bzjGHVNRxZresMw6ldufLZ7/nF2aVWkmCOkCGbJnXafky2l6WQ+lzuFxwOxwKnOW/JLHjQ9cMciiRxoK8qn6xosLa3X5F8oLDLQAR4hiaXkqVVQQrvxcYBdSkDdVTQrdB0+9WPgsNZqJK88DgZ6iNdZKICf6v3saSH+YZj8VintiP6yT0Vh/6wWktwjhbrv47/NTOL8/rTWoTdWhvMgj6MtC1QUP7GH1isFDnEwSgcXp+oORyg== X-YMail-OSG: jk9tcrkVM1kUHLJz7Jggj8UwkpmRnE28yuOnpoOjwksno8aqxJaPX1o.Mwg9t2o mCo02hS45zZJ9RxcqRocNKBdh_iwQAab3j0yw6dzvAgaFaAvhWA8Jc3EK6bXt1GlWx5i3sr38zru G2i_eaUt45U2AB77QDka2s6ApeHLUUIyCCy8p7dWUahOYaP5xj5RdGb9jmbfQ8vSLku5nN5BvAnq l2haPix.lxCyLQOoo0lCLk6Y_46PkV6dgKeqx48od0K__fSinOBlOpxTXaeiWa609Q2EEoerd3y6 VA0XY45J7XX_OeZ._438CU3Fv.XCA2MGExr8VJAgFiEkcK8LLCQM3lVzBWLI0NcIcogP86fDABej bRyp8Y9CS3c_.wRj7y4Mm.8oLzkg0VxkkyfPnxDTaaqJ_593t9pkn3tbrzELero1VDCPbCtXJkJc AUARgMdxN7Ox7_l_jwYmUhsud0ylG8y0xAU9N.pr6lplko0hLRpaVwpjBpklTIYmg2uUuU9GdpZF OuJ9sNh..1H1qqUyIfpfVE_atqoRCoGz6UjocDuOSEAmfng6qByKnp67LEmeb5Q0BGpa7ks2.t_X VtZnnady0pukFrtlIPPB0RxDLh9ZwCclCeIxsmlJ..X9csTwtryluu6ZjjApfO3lWEM42l3TV0md IMWfamAgXq9DI029o1IDffRBeFHUc7Jtz7NTU.I9CCa5MHqGZanPY92bS4nWzDV.ZRmxI5slQ.kG C7GKcFOZASwlK3izJBLRXBW2StLM4kB7I3FhQdwQCmPOw_0U2e5.k7eb4FQ0d_ZL.XEMd_j7yKen jdMNIbWS1Wez8U0qSE7E83ZaJfuA_OgqmSuuAOwXHf40w_zaXzP1sXhMxI0xLjkYDHj7azYnroFV h2NKQ9RZwqFEofJq1jt7J9p7E0zS003ZFgzQ_p24IZWZzZIGPbZ5KS81mIIteAg82VGhoVA2yjQS 2EZCFj7qpYt.eCkWXXULXz5kcxlAWvfagTrYF6n8V690YHOhvAR6rRJk9I8IowLqlf1E5rF6f8Vh Qb94jtZwvOXznJB1152zVRg08JFeYXw4N5P5TBoe9t7cX4N4XVvFSuJiTQQLQAxHg5WYoOwe2sw3 fiUx0HmnU81l3ifnu4X2bFqp4P6IJbf9yJ9lea91MvTEljgzVB3d.FHszudR2feNeWSkNo.jrfJ0 fcnfeIdY.0TuVBLpZePJ6wnaptBDUj_G.HqqYpflg4LCAaqI- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Jul 2019 21:32:21 +0000 Date: Fri, 26 Jul 2019 21:32:16 +0000 (UTC) From: Henry Andrews Reply-To: Henry Andrews To: JSON WG Message-ID: <1935603896.665770.1564176736191@mail.yahoo.com> In-Reply-To: References: <1D53CC7E-38A6-4F93-93F8-FE9227554B2B@tzi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_665769_1876911443.1564176736190" X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36 Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 21:32:24 -0000 ------=_Part_665769_1876911443.1564176736190 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One question I am curious about is how JSL got adopted by the working grou= p (being=C2=A0draft-json-schema-language-NN instead of draft-ucarion-json-s= chema-language-NN or draft-ucarion-schema-language-NN)?=C2=A0 I could not f= ind a discussion on this in the archives, although admittedly I did not rea= d all of the messages that seemed to be about details of numeric types or w= hatever yet. thanks,-henry On Friday, July 26, 2019, 02:26:52 AM PDT, Andrew Newton = wrote: =20 =20 On Thu, Jul 25, 2019 at 6:36 PM Carsten Bormann wrote: > > On Jul 25, 2019, at 18:12, Andrew Newton wrote: > > > > Due to the emergence of new formats such as TOML (to compete against > > YAML) and RCON and JSONLines to compete against JSON, > > A data definition language (what we call =E2=80=9Cschema language=E2=80= =9D here) describes data in a (generic) data model, not data serialized in = a format.=C2=A0 The formats you mention have a high degree of commonality i= n their generic data models, so I don=E2=80=99t know why a simple data defi= nition language cannot cover all of them [but then I don=E2=80=99t know RCO= N]. I agree with the concept. The IETF already has YANG. And things like GraphQL are fairly popular in the industry. So what work is left to do? -andy _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json =20 ------=_Part_665769_1876911443.1564176736190 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One question I am curious ab= out is how JSL got adopted by the working group (being draft-jso= n-schema-language-NN instead of draft-ucarion-json-schema-language-NN or dr= aft-ucarion-schema-language-NN)?  I could not find a discussion on thi= s in the archives, although admittedly I did not read all of the messages t= hat seemed to be about details of numeric types or whatever yet.

thanks,
-henry

=20
=20
On Friday, July 26, 2019, 02:26:52 AM PDT, Andrew Newto= n <andy@hxr.us> wrote:


On Thu, Jul 25, 2019 at 6:36 PM Carst= en Bormann <cabo@tzi.org> wrote:
>
=
> On Jul 25, 2019, at 18:12, Andrew Newton <andy@hxr.us&= gt; wrote:
> >
&g= t; > Due to the emergence of new formats such as TOML (to compete agains= t
> > YAML) and RCON and JSONLines to compe= te against JSON,
>
&= gt; A data definition language (what we call =E2=80=9Cschema language=E2=80= =9D here) describes data in a (generic) data model, not data serialized in = a format.  The formats you mention have a high degree of commonality i= n their generic data models, so I don=E2=80=99t know why a simple data defi= nition language cannot cover all of them [but then I don=E2=80=99t know RCO= N].

I agree with the c= oncept. The IETF already has YANG. And things like
GraphQL are fairly popular in the industry. So what work is left to
do?

-andy

_____________= __________________________________
json mailing l= ist
------=_Part_665769_1876911443.1564176736190-- From nobody Fri Jul 26 14:39:04 2019 Return-Path: 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 EA6AD12006E for ; Fri, 26 Jul 2019 14:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OpBYjSt5S7T8 for ; Fri, 26 Jul 2019 14:39:00 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB81120047 for ; Fri, 26 Jul 2019 14:38:59 -0700 (PDT) Received: from [172.20.10.2] (ip-109-40-1-203.web.vodafone.de [109.40.1.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45wMsY1h5VzyVb; Fri, 26 Jul 2019 23:38:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <1935603896.665770.1564176736191@mail.yahoo.com> Date: Fri, 26 Jul 2019 17:38:54 -0400 Cc: JSON WG X-Mao-Original-Outgoing-Id: 585869932.6794651-db90c59462d98cf2b954383f6edf9312 Content-Transfer-Encoding: quoted-printable Message-Id: <68D8D7DE-B2A4-4185-978F-1B088578CF79@tzi.org> References: <1D53CC7E-38A6-4F93-93F8-FE9227554B2B@tzi.org> <1935603896.665770.1564176736191@mail.yahoo.com> To: Henry Andrews X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 21:39:02 -0000 On Jul 26, 2019, at 17:32, Henry Andrews = wrote: >=20 > draft-json-schema-language-NN This is an individual contribution by mx. Json to the Schema working = group about Language. All three don=E2=80=99t exist, but datatracker doesn=E2=80=99t check = that. Working group documents of the JSON working group would look like draft-ietf-json-*-NN See? Other people can play with names and confuse the heck out of the = community, too :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 26 14:41:14 2019 Return-Path: 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 8CD56120100 for ; Fri, 26 Jul 2019 14:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=yahoo.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 U4zuvqRnaFVL for ; Fri, 26 Jul 2019 14:41:07 -0700 (PDT) Received: from sonic307-2.consmr.mail.bf2.yahoo.com (sonic307-2.consmr.mail.bf2.yahoo.com [74.6.134.41]) (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 9F4EC12006E for ; Fri, 26 Jul 2019 14:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1564177266; bh=J+BY3CTHfMgdrdqSBrZ0Tl+bmUDut7Cy5lrvWN4k1Ys=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Wkzij1zU1C5K+oplv6jbaSAVR9sYFK1FnflscvKKKdyuJZn83796PGtOHNyAEpbZCl19euZl7EVkErPcFjfBuzB4TNuRfyBogfn1AawqJEQAl8FQEvJ4fSsJVkv9hmvAHwW4hYM4XDht6gwCUII5WBE6N9Mr5Z9ncHEFNZBU/yG9qNqSRNjcny5oou/HFp0Db+0Fn97XqEs7yI0UEcc7ZIhU1TgTqjSBtahp/H/FzoG3KlKDUPXrarKar3InJ9eGRAI1woLd1xNd9BS17tR6Aoi0BMkZRy4vNQLtVLmKP5JyaO4LumJ4s9qnNeOG08FDy9GNyF2Xr28pEu9+0nJOEA== X-YMail-OSG: Wl0cdK4VM1m6qtYYx0cZKFCVhHHsBLOSRRhNbkywnHLgnvYbIXh_Ef5KM4eql.1 2.ewhO.50OyMXsIbHdhP9.eCH5HZlFGNRTnai4j8OfmcAC_DhWIx2uHgkWLhmNXaMBLDPhIXnctQ M3fyRIR1Q2csbDzWXXyGrIEGnKIqKDGtpM675.Zm5PLUiY_nbuLwUw1LzYgu4EtiJejAKbjd8.qn 1JGS3xoJJtTq1TGn_qAvn3M6pz9EUlQ3sEStjQ9u13Iynelw2.X_JDM8Mv4lGdT6V7yfUYBIifxL 94mBOg08nD_wn0Ok_C2uF6Z7O1MmeHoQd65FpLHY4dC.vMox7U5fowLeJbog3QdXdq7do9qH7Lum 6E3k.DvucW65hxmlEf3zLApSZ_AjeKNCl58p_DtJGZFDwhpWK2G_mo.lT0gunU1z3eJWI09BlOiy 7LXAT2iW.p2blwe9lCbtvea71jFQVKq5eCJZFL_yp2rEDN6gdx4vrpSBYlqhsUmf0GmDHediBDA1 AGgyKFuK47j4Hzf8QcOO9V_3N3HURxdRmKsyH6teaBQT9czo5ZJ4TO3_QGaF_pBxjjNeL4IUCfaS S1zCoBup2ZS_0d5u.AMqAqusSI9PcfKEP1G7wSwyDDhJ166SDnUDKEMxQ9S4uvqt2t0_SG_OtxSx 91AMZ_pY7fgFaqMMzzn2zXAmnNeAhHP0l9B_eFxHAGKT4S940YA2mi86oiWx4egEDuUUdI2f.knQ f8.ot3JMnwZhyzPpvveRPJpYJ2BJ6_d_wnIGAq028iovgVPUh3tNHwJ_GdX3YEaSPaJ8gRF1apxM Hc3btDl4okCw4Ig71oScApKlOlh6YKmAYi.92cHlsflBtlryg.ICEu_fXrM.qjjj0QyhHVyjtL.i bRpnL3WkDBTyyovu1jrsjbiCwu6Z_9pu8G05W6FNMNWVtX3FpR6noN.tH5bPPZSE_ErFD2WzlpFz J1RFZQiKaN6RN9su8ApOUjK8.zBG0cb2teqtaWfkcbJWIxvmn3UeiUieNCl2Cz01tK1UhOuRyTAg 35yJ8UBwZWkX2i5EtdI4pLQ2J.h96eYWsDc_jgwVN_AxMDfm33D_Fp3kxyi514.tQV2v6t3xtTxj eaafiinWDmgralFpYzF1YOEb277Ck1pQHmVypQkioDA8GvK4lTP6lQoPESpzVkUjuPkeGGq0ZWWR roB2qEQGssFyd7UTwePAM_q7MRrpwEp3QEO7I_58rXWAIhALfNpcC2xvVSX8ZpHlImjDp0Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Fri, 26 Jul 2019 21:41:06 +0000 Date: Fri, 26 Jul 2019 21:41:01 +0000 (UTC) From: Henry Andrews Reply-To: Henry Andrews To: Carsten Bormann Cc: JSON WG Message-ID: <1428904851.707331.1564177261937@mail.yahoo.com> In-Reply-To: <68D8D7DE-B2A4-4185-978F-1B088578CF79@tzi.org> References: <1D53CC7E-38A6-4F93-93F8-FE9227554B2B@tzi.org> <1935603896.665770.1564176736191@mail.yahoo.com> <68D8D7DE-B2A4-4185-978F-1B088578CF79@tzi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_707330_1530395236.1564177261936" X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36 Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 21:41:10 -0000 ------=_Part_707330_1530395236.1564177261936 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable LOLOL awesome, that actually does make more sense.=C2=A0 Garbage in, garba= ge out... ;-D -henry On Friday, July 26, 2019, 02:39:12 PM PDT, Carsten Bormann wrote: =20 =20 On Jul 26, 2019, at 17:32, Henry Andrews wrote: >=20 > draft-json-schema-language-NN This is an individual contribution by mx. Json to the Schema working group = about Language. All three don=E2=80=99t exist, but datatracker doesn=E2=80=99t check that. Working group documents of the JSON working group would look like draft-ietf-json-*-NN See?=C2=A0 Other people can play with names and confuse the heck out of the= community, too :-) Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json =20 ------=_Part_707330_1530395236.1564177261936 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
LOLOL awesome, that actually= does make more sense.  Garbage in, garbage out... ;-D

-henry

=20
=20
On Friday, July 26, 2019, 02:39:12 PM PDT, Carsten Borm= ann <cabo@tzi.org> wrote:


On Jul 26, 2019, at 17:32, Henry Andr= ews <andrews_henry=3D40yahoo.com@dmarc.ietf.org= > wrote:
>
> draft-json-schem= a-language-NN

This is an individual co= ntribution by mx. Json to the Schema working group about Language.
All three don=E2=80=99t exist, but datatracker doesn=E2=80=99t ch= eck that.

Working group documents of t= he JSON working group would look like

= draft-ietf-json-*-NN

See?  Other = people can play with names and confuse the heck out of the community, too := -)

Gr=C3=BC=C3=9Fe, Carsten


_______________________________________________
json mailing list
json@ietf.org<= br clear=3D"none">https://www.ietf.org/mailma= n/listinfo/json
------=_Part_707330_1530395236.1564177261936-- From nobody Fri Jul 26 20:44:15 2019 Return-Path: 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 E657812023B for ; Fri, 26 Jul 2019 20:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 tC1mWoW5Ipvj for ; Fri, 26 Jul 2019 20:44:10 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 2E2EC120223 for ; Fri, 26 Jul 2019 20:44:10 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id k20so108821609ios.10 for ; Fri, 26 Jul 2019 20:44:10 -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=HoTL+JQF42FHe0oLfBuLGfm8Wkmkog5jJUohvw3ZVl4=; b=G38AILTl8iiBa0k9Htb33sen3o6ORs6P3SZx+HZDrX80Qqti5OpFc0bUJSznd0ARet g2m6TB03xHawKS14iWzU34a49Xjd05XjpNxNeEfk1OGoUb9d3R8hTMvZ2QTisGcpK/Eh +gmfn0Lz7omkakfMfR58EdSOcu6GIgUOGf5ns= 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=HoTL+JQF42FHe0oLfBuLGfm8Wkmkog5jJUohvw3ZVl4=; b=UvPfv7NLEgy1caxLUixoWTQy3p6aht7RS5eo7WX410RECZR9JCtZHZ7LNcWRFk3l25 +lJpZfIvf5oE9MlFB2PiqQ11iIRfIVoc+gVJOGAygWze1zXUwY9DOTOCn4EjeH661dpG P/cCSKCDv4pBc95bZzou/vz6Yk5kYiOSNbdY0yVG3jDIH/BJNWM0MyesiWUmiq8mR6jv LGPwQgFzAjKW2ALzucqzsKY1Ojc/itC4HG0dpDhANkeaFLF/nZdXKp6to1ex2B1rk0+K pkz+arBbXcgID0yZ92DB++2S/8R90exH1ehPgOGArJKAVAIVzHeyDG655AXtod8mO3Sm Ylog== X-Gm-Message-State: APjAAAXN4xptbqvj0+xiwOo3O6jwLP2oqmQEWqU6ZPFNjpT+qETAVCOQ hn8jQRSwO7xZcsS/clDuWGuYAh9J7d/g7UIpGE0BqQ== X-Google-Smtp-Source: APXvYqzMDBbWW3EGsWRI2gVfuW3fDVOtG0x3KBcekifKgHJ7eYwQJyOkJSIIzC1Aex8t51yiCKwMSDHz1ukReRFH8N4= X-Received: by 2002:a6b:90c3:: with SMTP id s186mr2241848iod.114.1564199049331; Fri, 26 Jul 2019 20:44:09 -0700 (PDT) MIME-Version: 1.0 References: <1D53CC7E-38A6-4F93-93F8-FE9227554B2B@tzi.org> <1935603896.665770.1564176736191@mail.yahoo.com> <68D8D7DE-B2A4-4185-978F-1B088578CF79@tzi.org> <1428904851.707331.1564177261937@mail.yahoo.com> In-Reply-To: <1428904851.707331.1564177261937@mail.yahoo.com> From: Ulysse Carion Date: Fri, 26 Jul 2019 20:43:58 -0700 Message-ID: To: Henry Andrews Cc: Carsten Bormann , JSON WG Content-Type: multipart/alternative; boundary="000000000000b1b068058ea178bf" Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 03:44:13 -0000 --000000000000b1b068058ea178bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi James, > If you have a system that you are certain will never need to interop with one that at some point in its parsing treats JSON numbers as doubles =E2=80= =A6 well you are in a closed system so you don=E2=80=99t really needs an IETF spec = =E2=80=A6 and you are making dangerous assumptions about your future technical stack =E2=80= =A6 (plus you can put =E2=80=9Cint53=E2=80=9D in your schema, get a =E2=80=9Clong=E2= =80=9D in your generated code, but don=E2=80=99t put any 2^53 checks in the code). This is a very strong point, and one which I had given insufficient consideration. Looking at gRPC, they opted to represent int64 as a base-10 strings. In GitHub, I noticed one of the gRPC developers puts the point nicely: > So, rather than pretending that Javascript can handle it (and lose data) proto3 prefers to have the client interact with strings. Fewer footguns =3D= =3D better libraries. ( https://github.com/grpc-ecosystem/grpc-gateway/issues/219#issuecomment-2512= 50029 ) Given that introducing int64 as a JSON number type would be a footgun for many sorts of applications, I agree it should be changed. How would you feel about simply removing int64/uint64, but otherwise keeping everything else as-is? I don't know if adding "native" support for string-represented bigints is a great idea, as there are so many different options. Smaller specs are the ones most frequently implemented correctly and securely. > This is a major limitation for something calling itself =E2=80=9CJSON Sch= ema Language=E2=80=9D, as opposed to, say, =E2=80=9CSchema Language for a Subse= t of JSON=E2=80=9D. All code generators needs to be able to insert =E2=80=9Cany=E2=80=9D. Its not t= he end of the world if some code generators use =E2=80=9Cany=E2=80=9D whenever the schema= allows multiple types if doing better is too difficult. I'm not sure I agree that this is a major limitation. There are many options for data definition languages for JSON. JSL is just one of them, falling on the less-expressive, easier-to-implement end of the spectrum. Or is your concern purely one regarding naming? On Fri, Jul 26, 2019 at 2:41 PM Henry Andrews wrote: > LOLOL awesome, that actually does make more sense. Garbage in, garbage > out... ;-D > > -henry > > On Friday, July 26, 2019, 02:39:12 PM PDT, Carsten Bormann > wrote: > > > On Jul 26, 2019, at 17:32, Henry Andrews 40yahoo.com@dmarc.ietf.org> wrote: > > > > draft-json-schema-language-NN > > This is an individual contribution by mx. Json to the Schema working grou= p > about Language. > All three don=E2=80=99t exist, but datatracker doesn=E2=80=99t check that= . > > Working group documents of the JSON working group would look like > > draft-ietf-json-*-NN > > See? Other people can play with names and confuse the heck out of the > community, too :-) > > Gr=C3=BC=C3=9Fe, Carsten > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --000000000000b1b068058ea178bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi James,

> If you have a= system that you are certain will=20 never need to interop with one that at some point in its parsing treats=20 JSON numbers as doubles =E2=80=A6 well you are in a closed system so you do= n=E2=80=99t=20 really needs an IETF spec =E2=80=A6 and you are making dangerous assumptions about your future technical stack =E2=80=A6 (plus yo= u can put =E2=80=9Cint53=E2=80=9D in your schema, get a =E2=80=9Clong=E2=80=9D i= n your generated code, but=20 don=E2=80=99t put any 2^53 checks in the code).

Th= is is a very strong point, and one which I had given insufficient considera= tion. Looking at gRPC, they opted to represent int64 as a base-10 strings. = In GitHub, I noticed one of the gRPC developers puts the point nicely:
<= /div>

> So, rather than pretending that Javascript ca= n handle it (and lose=20 data) proto3 prefers to have the client interact with strings. Fewer=20 footguns =3D=3D better libraries.


Given that introducing int64 as a JS= ON number type would be a footgun for many sorts of applications, I agree i= t should be changed.

How would you feel about simp= ly removing int64/uint64, but otherwise keeping everything else as-is? I do= n't know if adding "native" support for string-represented bi= gints is a great idea, as there are so many different options. Smaller spec= s are the ones most frequently implemented correctly and securely.

> This is a major limitation for something calling=20 itself =E2=80=9CJSON Schema Language=E2=80=9D, as opposed to, say, =E2=80= =9CSchema Language for a Subset of JSON=E2=80=9D. All code generators needs to be able to insert = =E2=80=9Cany=E2=80=9D.=20 Its not the end of the world if some code generators use =E2=80=9Cany=E2=80=9D whenever the schema allows multiple t= ypes if doing better is too difficult.

I'm not sure I agree= that this is a major limitation. There are many options for data definitio= n languages for JSON. JSL is just one of them, falling on the less-expressi= ve, easier-to-implement end of the spectrum. Or is your concern purely one = regarding naming?

On Fri, Jul 26, 2019 at 2:41 PM Henry Andrews &l= t;andrews_henry=3D40yahoo.com= @dmarc.ietf.org> wrote:
LOLOL awesome, that actually does make more sense.= =C2=A0 Garbage in, garbage out... ;-D

-henry

=20
=20
On Friday, July 26, 2019, 02:39:12 PM PDT, Carsten Borm= ann <cabo@tzi.org&= gt; wrote:


On Jul 26, 2019, at 17:32, Henry Andr= ews <andrews_henry=3D40yahoo.com@dmarc.ietf.org= > wrote:
>
> draft-json-schem= a-language-NN

This is an individual co= ntribution by mx. Json to the Schema working group about Language.
All three don=E2=80=99t exist, but datatracker doesn=E2=80=99t ch= eck that.

Working group documents of t= he JSON working group would look like

= draft-ietf-json-*-NN

See?=C2=A0 Other = people can play with names and confuse the heck out of the community, too := -)

Gr=C3=BC=C3=9Fe, Carsten


_______________________________________________
json m= ailing list
json@ietf.org
<= a shape=3D"rect" href=3D"https://www.ietf.org/mailman/listinfo/json" rel=3D= "nofollow" target=3D"_blank">https://www.ietf.org/mailman/listinfo/json=
_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--000000000000b1b068058ea178bf-- From nobody Fri Jul 26 20:56:31 2019 Return-Path: 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 2E8FD12023F for ; Fri, 26 Jul 2019 20:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 xLCysXP7e0OL for ; Fri, 26 Jul 2019 20:56:27 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 C19C4120223 for ; Fri, 26 Jul 2019 20:56:27 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id h6so22340969iom.7 for ; Fri, 26 Jul 2019 20:56:27 -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=ycJImLhW3ptrc/X10Rl3dz2PfvURuoFU9iruyKvfAD8=; b=Yrmf1fFi56w2/nN0n/0dgRFA+Gkr8nMhN9tZqzp7v7CTj7hASWSn8RBclZRv7GwZPg kNkliMx+Q8L8lqxDd73iTLzwPRsEc5DguQj36ScAdQPOijsiQpbS5yJLjmeiNYEXhW/7 XIZ67yIJwTq49WVkZCZJ/YAd4A1eVAPzdvpys= 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=ycJImLhW3ptrc/X10Rl3dz2PfvURuoFU9iruyKvfAD8=; b=W6GRnHUb4XXUTlimi5Ljvz6VLto2mojAaRMFnux9lvD8HdD+BtIPRFAGMukAqWKsDi XNmF59I9Fbx5jx7ATTjc46IK4ymNBsYfqYsfRRdwKZxJZ7hblL735m7vd+IIqnZ102Qu sz4I8DO83S0740catsYsQE46vvW0ShgEM0jrXvUusMpfBspHGUM/spMKB8rcaCMPAlFz V8bJSaoAjKyM12nyw9AJB5qdhzAxFU/hYcXGqjj5vaDMUXf+bMUki7nAFd1AGk5w1bOP jw6B5rLVwnK0dA81QguDP+9Sw0C4jhKc0lT5ls+LE4cJ5tNsE8XbTWDrEIkHN3UaUz8x 2poQ== X-Gm-Message-State: APjAAAUutqdWIMUMbEwNvuCyf6N7wtgvjGSgHoDUVUp2fAaYeSue6wOw qvzO14Vud01CmwXOuo2A1yKqXEZGLnJYv1xaTHIN7g== X-Google-Smtp-Source: APXvYqyhYQfFvGtXEH/OuEh6Vn8Uc7YmZCn/DMI0Sv2khGb4R5FEvfRoc5+PC1jOTv9dwTDcD/L2AXLBa1Fp9IyBHrE= X-Received: by 2002:a5d:9f4a:: with SMTP id u10mr63222756iot.243.1564199786761; Fri, 26 Jul 2019 20:56:26 -0700 (PDT) MIME-Version: 1.0 References: <1D53CC7E-38A6-4F93-93F8-FE9227554B2B@tzi.org> <1935603896.665770.1564176736191@mail.yahoo.com> <68D8D7DE-B2A4-4185-978F-1B088578CF79@tzi.org> <1428904851.707331.1564177261937@mail.yahoo.com> In-Reply-To: From: Ulysse Carion Date: Fri, 26 Jul 2019 20:56:15 -0700 Message-ID: To: andy@hxr.us Cc: Carsten Bormann , JSON WG Content-Type: multipart/alternative; boundary="000000000000a5f5e9058ea1a4c5" Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 03:56:30 -0000 --000000000000a5f5e9058ea1a4c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andrew, > In the end, I believe no effort in the IETF to put a JSON ddl on the > standards track would be legitimate without the involvement of > json-schema.org (I said as much in London when I presented JCR). They > have a larger community than we have here and a specification baked > into many tools. Just for my own context, do you happen to have any links to minutes / recording of this presentation? I want to better understand your point. Best, Ulysse On Fri, Jul 26, 2019 at 8:43 PM Ulysse Carion wrote: > Hi James, > > > If you have a system that you are certain will never need to interop > with one that at some point in its parsing treats JSON numbers as doubles= =E2=80=A6 > well you are in a closed system so you don=E2=80=99t really needs an IETF= spec =E2=80=A6 > and you are making dangerous assumptions about your future technical stac= k > =E2=80=A6 (plus you can put =E2=80=9Cint53=E2=80=9D in your schema, get a= =E2=80=9Clong=E2=80=9D in your generated > code, but don=E2=80=99t put any 2^53 checks in the code). > > This is a very strong point, and one which I had given insufficient > consideration. Looking at gRPC, they opted to represent int64 as a base-1= 0 > strings. In GitHub, I noticed one of the gRPC developers puts the point > nicely: > > > So, rather than pretending that Javascript can handle it (and lose data= ) > proto3 prefers to have the client interact with strings. Fewer footguns = =3D=3D > better libraries. > > ( > https://github.com/grpc-ecosystem/grpc-gateway/issues/219#issuecomment-25= 1250029 > ) > > Given that introducing int64 as a JSON number type would be a footgun for > many sorts of applications, I agree it should be changed. > > How would you feel about simply removing int64/uint64, but otherwise > keeping everything else as-is? I don't know if adding "native" support fo= r > string-represented bigints is a great idea, as there are so many differen= t > options. Smaller specs are the ones most frequently implemented correctly > and securely. > > > This is a major limitation for something calling itself =E2=80=9CJSON S= chema > Language=E2=80=9D, as opposed to, say, =E2=80=9CSchema Language for a Sub= set of JSON=E2=80=9D. All > code generators needs to be able to insert =E2=80=9Cany=E2=80=9D. Its not= the end of the > world if some code generators use =E2=80=9Cany=E2=80=9D whenever the sche= ma allows multiple > types if doing better is too difficult. > > I'm not sure I agree that this is a major limitation. There are many > options for data definition languages for JSON. JSL is just one of them, > falling on the less-expressive, easier-to-implement end of the spectrum. = Or > is your concern purely one regarding naming? > > On Fri, Jul 26, 2019 at 2:41 PM Henry Andrews 40yahoo.com@dmarc.ietf.org> wrote: > >> LOLOL awesome, that actually does make more sense. Garbage in, garbage >> out... ;-D >> >> -henry >> >> On Friday, July 26, 2019, 02:39:12 PM PDT, Carsten Bormann >> wrote: >> >> >> On Jul 26, 2019, at 17:32, Henry Andrews > 40yahoo.com@dmarc.ietf.org> wrote: >> > >> > draft-json-schema-language-NN >> >> This is an individual contribution by mx. Json to the Schema working >> group about Language. >> All three don=E2=80=99t exist, but datatracker doesn=E2=80=99t check tha= t. >> >> Working group documents of the JSON working group would look like >> >> draft-ietf-json-*-NN >> >> See? Other people can play with names and confuse the heck out of the >> community, too :-) >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > --000000000000a5f5e9058ea1a4c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew,

>=20 In the end, I believe no effort in the IETF to put a JSON ddl on the
>= ; standards track would be legitimate without the involvement of
>= ; json-schema.org (I said as much in London when I presented JCR). They=
> have a larger community than we have here and a specification bake= d
> into many tools.

Just for my own context= , do you happen to have any links to minutes / recording of this presentati= on? I want to better understand your point.

Best,<= /div>
Ulysse

On Fri, Jul 26, 2019 at 8:43 PM Ulysse Carion <= ;ulysse@segment.com> wrote:
<= div>Hi James,

> If you have a system that you a= re certain will=20 never need to interop with one that at some point in its parsing treats=20 JSON numbers as doubles =E2=80=A6 well you are in a closed system so you do= n=E2=80=99t=20 really needs an IETF spec =E2=80=A6 and you are making dangerous assumptions about your future technical stack =E2=80=A6 (plus yo= u can put =E2=80=9Cint53=E2=80=9D in your schema, get a =E2=80=9Clong=E2=80=9D i= n your generated code, but=20 don=E2=80=99t put any 2^53 checks in the code).

Th= is is a very strong point, and one which I had given insufficient considera= tion. Looking at gRPC, they opted to represent int64 as a base-10 strings. = In GitHub, I noticed one of the gRPC developers puts the point nicely:
<= /div>

> So, rather than pretending that Javascript ca= n handle it (and lose=20 data) proto3 prefers to have the client interact with strings. Fewer=20 footguns =3D=3D better libraries.


Given that introdu= cing int64 as a JSON number type would be a footgun for many sorts of appli= cations, I agree it should be changed.

How would y= ou feel about simply removing int64/uint64, but otherwise keeping everythin= g else as-is? I don't know if adding "native" support for str= ing-represented bigints is a great idea, as there are so many different opt= ions. Smaller specs are the ones most frequently implemented correctly and = securely.

> This is a major limitation for some= thing calling=20 itself =E2=80=9CJSON Schema Language=E2=80=9D, as opposed to, say, =E2=80= =9CSchema Language for a Subset of JSON=E2=80=9D. All code generators needs to be able to insert = =E2=80=9Cany=E2=80=9D.=20 Its not the end of the world if some code generators use =E2=80=9Cany=E2=80=9D whenever the schema allows multiple t= ypes if doing better is too difficult.

I'm not sure I agree= that this is a major limitation. There are many options for data definitio= n languages for JSON. JSL is just one of them, falling on the less-expressi= ve, easier-to-implement end of the spectrum. Or is your concern purely one = regarding naming?

On Fri, Jul 26, 2019 at 2:41 PM Henry Andrews &l= t;andrews_henry=3D40yahoo.com@dmarc.ietf.org> wrote:
LOLOL awesome, that actually does make more sense.= =C2=A0 Garbage in, garbage out... ;-D

-henry

=20
=20
On Friday, July 26, 2019, 02:39:12 PM PDT, Carsten Borm= ann <cabo@tzi.org&= gt; wrote:


On Jul 26, 2019, at 17:32, Henry Andr= ews <andrews_henry=3D40yahoo.com@dmarc.ietf.org= > wrote:
>
> draft-json-schem= a-language-NN

This is an individual co= ntribution by mx. Json to the Schema working group about Language.
All three don=E2=80=99t exist, but datatracker doesn=E2=80=99t ch= eck that.

Working group documents of t= he JSON working group would look like

= draft-ietf-json-*-NN

See?=C2=A0 Other = people can play with names and confuse the heck out of the community, too := -)

Gr=C3=BC=C3=9Fe, Carsten


____________________= ___________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--000000000000a5f5e9058ea1a4c5-- From nobody Fri Jul 26 21:00:16 2019 Return-Path: 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 E469A12025F for ; Fri, 26 Jul 2019 21:00:14 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 WgFf5RXEX6BO for ; Fri, 26 Jul 2019 21:00:12 -0700 (PDT) Received: from sonic309-15.consmr.mail.bf2.yahoo.com (sonic309-15.consmr.mail.bf2.yahoo.com [74.6.129.125]) (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 3B8FC120255 for ; Fri, 26 Jul 2019 21:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1564200010; bh=jHMfn2tyf+twpkmLTYWTbGISMS9VOj1iqDPj+l2mZTM=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=t3kiAiLHbDMyzLcAl7bp67QaiE3RLksiDqTWg1jbzUiXaIFBMSX2G7eUeQoMV5+1N6DyhPzRGzD2gGSco8ZpiZoRmWEYioRRx8cc3QrGf8IViAI0gRBVGsXYEHraXTBr58TMLPASQRse+rQrlf58e+L8e7kbc9dpMtUMmOUeCGmC32jqWzId51SCcH0gcOC2w29qfoNtlAqZWTSoHUQDXZKEew1Yzp04CBBrOBsPx9ECpvJjfaEcKjq1QPzCgCku7Y3RflYNQxZnNMYiY/bHV9kT3IKsd1sa6iUXmbWBxDbcqNj65+aKfCZGZdnMjT6FfrorwO70XWmBNYK54p5Ahw== X-YMail-OSG: 0KoBKhEVM1kBLnlc7eR.9FrXPkpVseJU7z6EbLmhzriGrAjoyQ2eVN6uxKdhfDA 6sL2LVxAtPTVu7zZ1nre6rl62FO9c39kg2K_MNtz8nb7rsidN8SAhOiB0QkdbHrRlPhhFrl.G.yW aml6XVhBM7fHGYFYryjcMkA6eJ8n8_kTmsu.yFsOhUy4Pk4W9D2pQMV05Np9m0b3TSvBg9qxskLn niQW8odZX8y9EGphefOAFbiEesXBFC0uGF1iyNi8jOL_UcjBeBqKDUCRMu1H5PUShDBSyHQ7W0i6 MdGHPK2QndAEpYEHAO_JlYE1Xy2UgYTfeP0LedUyFCIC7ghZBxnQN3XkQjzmVdHLwMxLHyD1iq2W 2.jALJM2Cgny5KdF0dVu9PCUiDB5De7v4E13vbuE_iVzPGYCE_lCb8q_.GR84qPXaMB7xPNI9NGc 3x53VEfaw0qJ6e9GepgsmYzOBRzKkHrMSApL7LRvU4JdNbwScT_QUz.jMWUmfLeKzZ_s9z72xcw9 q1DD1pDMqZ2m9PbpMUyplQBBguonMk8f57viybBdHiaClcPtdl819FZ6fTHFqmHOLrCz0h1UQE7w Z5iaI8rxQ3GsN8is_h8YwQ7AFPGhTWutpA0AkzK548aUsg8HSa4TwsSaCxoGv14v8Vppi3epbQDu GU5y.Qhy5sLob2_FmWQGcjjJnd4XZyhJnOkA9fpz3oR7Rky1sJ_zc_rMm923LfAZFGW1cZB7lpXL QJat4hKsaYEW0lZvs2Giz8IF18_y44aQ0kjfnQfH6UhN68rQYBn01r246s0pg57ZCwjqwxMZ_fhu fIjJrWyOniEWXjBC7FybSXbsIvnADKgxxadD69Rm19e_QOepZh9gNzGLxQowl2GoWUv.7dl6m1oW vg_JfTlx74aozxna5ge2AFr1bnDX7pQemCX1LpY51J9cK1VnrY_pHQzgNyQKoVhMluZJKpJZKAPH beFH9sF6UiS0oaGFMVdV6Rlt9w6WgVLXV97dKqh0tyrFvFe6E1zHhQjuqbEch4A1.uOOfxkpEkmS n1.JarEA5LEavKd8azOOcC3oGg1bvvlZR5M1fNrdjv.lkb0c6rJzCw8fE_gUUA.b2j7sIszlXxf2 lDLEVDYP7Y9Gq9XCfWO1XNQVoHT0MDLIEAarRLd1v2qXylzT9H6iqdyDVnWj7EtHhXDB1wr3SimI WvHc8mZmSRhV8Lj4835zbFNCc8zBnuNlkW__08.uRHcOOldOHXCB2Jl6mwv2sKNxRp8LknhsN Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Sat, 27 Jul 2019 04:00:10 +0000 Date: Sat, 27 Jul 2019 04:00:07 +0000 (UTC) From: Henry Andrews Reply-To: Henry Andrews To: JSON WG Message-ID: <790121095.761914.1564200007426@mail.yahoo.com> In-Reply-To: <1264668892.999441.1564176509455@mail.yahoo.com> References: <1D53CC7E-38A6-4F93-93F8-FE9227554B2B@tzi.org> <1264668892.999441.1564176509455@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36 Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 04:00:15 -0000 Hmm.. in the archives it looks like most of my blank lines between paragrap= hs got deleted somewhere (although it looks fine in the actual email back t= o me).=C2=A0 Here's an attempt to make it more readable.=C2=A0=C2=A0 On Friday, July 26, 2019, 02:29:19 PM PDT, Henry Andrews wrote:=20 Hi folks, =C2=A0 I'm one of the current authors/editors of the JSON Schema specificat= ion, along with Austin Wright, Ben Hutton, and Greg Dennis.=C2=A0=C2=A0 =C2=A0 Andy Newman brought yesterday's thread about JSON Schema Language to= our attention, and I see that he asked about the relationship between JSL = and JSON Schema earlier in the thread here. =C2=A0 There is no relationship between the projects, aside from obviously = drawing on some common ideas.=C2=A0 JSL also draws on some ideas that we de= cided to exclude from JSON Schema.=C2=A0 Ulysse discussed some ideas with u= s a while back but it became clear that our current direction was not what = he was looking for.=C2=A0 I encouraged him to build his own system, as JSON= Schema has a large user base, and some things that he wanted changed would= be too disruptive to that user base.=C2=A0 IIRC (and feel free to correct = if I'm misremembering this, Ulysse), he also disagreed with some key featur= es in the next draft.=C2=A0 Since those features were developed in coordina= tion with large user communities such as OpenAPI, we were not willing to dr= op them based on anyone's individual objections. =C2=A0 My only concern with the JSON Schema Language project is the name: w= hile JSON Schema is purely a series of individual drafts and therefore has = no official IETF status or approval, the name "JSON Schema" has a long hist= ory and a large user base.=C2=A0 Putting out a similar project with a nearl= y-identical name will be very confusing and, in my opinion, bad form.=C2=A0= Contrast with JSON Schema and JSON Content Rules which can easily co-exist= without confusion. =C2=A0 Might I suggest "JSON Definition Language", as the system is primari= ly oriented towards definitions for code generation and the like? =C2=A0 Anyway, if Ulysse calls it something else then, speaking for myself = and not for the whole JSON Schema project, I don't have any problems with J= SL at all. =C2=A0 Andy wrote in his email here about wanting us involved in any standa= rds-track JSON DDL, which I appreciate, but there are a couple of concerns = that make that unlikely.=C2=A0 At least right now. 1.=C2=A0 JSON Schema is not really a data definition language, at least not= in its current form.=C2=A0 It was originally constructed as a constraint s= ystem, with a vaguely-defined concept of annotating instances with other (p= ossibly dynamic, e.g. Hyper-Schema) data.=C2=A0 Next month's draft finishes= formalizing the annotation concept so that it can be interoperable, and fo= rmalizes an extensibility mechanism. =C2=A0 This extensibility mechanism will allow defining a data definition v= ocabulary through annotations within the JSON Schema system, but that will = be further work and presumably be an additional spec on top of the Validati= on spec (again, similar to how Hyper-Schema builds on Validation).=C2=A0 Th= is work on extensibility is primarily motivated by systems such as OpenAPI = code generators and various web form generator libraries, which are otherwi= se an awkward fit. =C2=A0 In another thread, Tim Bray asked if JSL was a compatible subset of = JSON Schema- it is not.=C2=A0 The extensibility mechanism in the forthcomin= g draft does allow constraining JSON Schema in certain ways to define subse= ts (for example if the anyOf/allOf/oneOf/not/if/then/else keywords are not = suitable for some use cases, they could be forbidden without otherwise chan= ging the keyword syntax or semantics).=C2=A0 If the desire is simply to sub= set JSON Schema, there is no need for a separate project. 2.=C2=A0 The last time we checked in with this mailing list, we were told t= hat the JSON working group (or some successor group- I'm a little unclear o= n that) would not be interested in adopting JSON Schema in anything resembl= ing its current form for a Standards Track RFC.=C2=A0 I think Ben (one of t= he other editors) is planning to check back in here on that topic after we = get the next draft out the door, but given our large and well-established u= ser community, discarding what we have is not an option.=C2=A0 Perhaps an I= nformational RFC would be more appropriate, as my understanding is that the= y "may be appropriate when republishing standards produced by a standards b= ody other than the IETF, industry consortia or companies."=C2=A0 (I suppose= the JSON Schema org may be considered an "industry consortia" under a suff= iciently permissive definition :-) =C2=A0 So (again, speaking for myself), I have been assuming that the worki= ng group would at some point start a new project or adopt another project t= han ours (JCR, JSL, whatever).=C2=A0 If relatively simple data definition i= s the only thing that you want, then it would of course be possible to writ= e a more focused system than JSON Schema. =C2=A0 As for the status of JSON Schema, we are indeed still an active proj= ect, and expect to publish a new draft during August.=C2=A0 The regrettable= delay that has left us in an expired draft state for the past half-year wa= s the result of a series of personal difficulties on my side, but fortunate= ly other community members have stepped up to help.=C2=A0 Most of the curre= nt core contributors have been involved since October 2016's draft-wright-j= son-schema-00, and I'm not disappearing entirely, so there is considerable = continuity. =C2=A0 The primary goal of the August draft is to get feedback on the exten= sibility mechanism, the recommended output/error format, and a few other ma= jor new features.=C2=A0 I expect there will be one further significant draf= t (or cluster of small updates so we don't have another big gap) to finish = the extensibility work based on that feedback, at which point hopefully we = can declare the Core and Validation specifications "done", whether that mea= ns publishing some sort of final document or entering a more formal standar= ds process.=C2=A0 Hyper-Schema is on a different timeline, and will not blo= ck Core or Validation. =C2=A0 Please let me know if you have any questions. thanks, -henry _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json From nobody Sat Jul 27 06:12:54 2019 Return-Path: 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 442CF12027A for ; Sat, 27 Jul 2019 06:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20150623.gappssmtp.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 RIbL6NC6Kgzh for ; Sat, 27 Jul 2019 06:12:51 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 3B0E9120140 for ; Sat, 27 Jul 2019 06:12:51 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id h6so23957976iom.7 for ; Sat, 27 Jul 2019 06:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=g+/50HFR6Oq65ygf4Xh8IUx1hQuQPV8ocDNVCd+inx8=; b=1kf3F6L2lGsEA40DucL0bvvAh37OqRpR2grbOQNXKSqWRsoxhH/1zpQLAlK6H+FVax 1QzKqcdCp61tlRf/P3G7vt7hULS//qP7oWNOr4fmabgMVSUuYZmFMqrcPPV+v04H96oq b1bQ5Vi4huziKX735UOjLB+snAMwAUMBshu8KWZJqDRWrgwk26Bp9GazcXYuIPpTnPv0 HXorSAI34GfGoZ3ECJ8xtluj9/DjDhdMlA7yGXGb2fJWHdhfQ5N6XIWLusguk6HsqRCg 48O4OosOGDkkkbUCRolziBtunqnHQ8j057Pi+XFxaMIB88HDQ97p9LfHW74+KgxUlc5i ietQ== 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:content-transfer-encoding; bh=g+/50HFR6Oq65ygf4Xh8IUx1hQuQPV8ocDNVCd+inx8=; b=YYUYwCcEaWpRRe8uj/UcOXr/WgY85O4BWMDuHxf9hPYqZ26+viq/yN5sTFT0wO4dQn ARIAE5gYNt3IhFGw0B6aRzHhO/c0TY8uNq/LPo4dz2W6Bfhs41501ksW9OwNNKggZqEC ayM5q7pG+YnSZRkCGyICZOwzvtklGNN+W2USKV7GaQXIRE61JlUtmrLqn80HwAhYt4y8 lxCgQQBsKleWquheVA18h4T4PaItdgZYyZqwwdT2VtSrvn0eonCC2OmiJvE54j4TTh4H 98Wd07Y6c438K1C3qvnhtCNSKCmMyNzl2lTwFS5V7ilpzclYVqnenDrfJ11A8owJftyZ qjWQ== X-Gm-Message-State: APjAAAWexfTEN/pgIVTbtOdVxms3AjOjpoPV4970HR4PCOtCHEDXLyDi F55zIAzMWe5hw+F/japmk4dW2e0W89KZCPmEHQg= X-Google-Smtp-Source: APXvYqze9qFPmJ1jXnnmlpCCCOwLQosJA0kfn7eGBvTgJDmkbKl5HWGTi7qW79ReoDurOVgow+CaRU3UXx7SbQi5K/Q= X-Received: by 2002:a02:c50a:: with SMTP id s10mr105116501jam.106.1564233170455; Sat, 27 Jul 2019 06:12:50 -0700 (PDT) MIME-Version: 1.0 References: <1D53CC7E-38A6-4F93-93F8-FE9227554B2B@tzi.org> <1935603896.665770.1564176736191@mail.yahoo.com> <68D8D7DE-B2A4-4185-978F-1B088578CF79@tzi.org> <1428904851.707331.1564177261937@mail.yahoo.com> In-Reply-To: <1428904851.707331.1564177261937@mail.yahoo.com> From: Andrew Newton Date: Sat, 27 Jul 2019 09:12:41 -0400 Message-ID: To: Henry Andrews Cc: Carsten Bormann , JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2019 13:12:53 -0000 The convention is typically draft-LASTNAME-blabblah... to denote a draft with only individual standing. -andy On Fri, Jul 26, 2019 at 5:41 PM Henry Andrews wrote: > > LOLOL awesome, that actually does make more sense. Garbage in, garbage o= ut... ;-D > > -henry > > On Friday, July 26, 2019, 02:39:12 PM PDT, Carsten Bormann = wrote: > > > On Jul 26, 2019, at 17:32, Henry Andrews wrote: > > > > draft-json-schema-language-NN > > This is an individual contribution by mx. Json to the Schema working grou= p about Language. > All three don=E2=80=99t exist, but datatracker doesn=E2=80=99t check that= . > > Working group documents of the JSON working group would look like > > draft-ietf-json-*-NN > > See? Other people can play with names and confuse the heck out of the co= mmunity, too :-) > > Gr=C3=BC=C3=9Fe, Carsten > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Sun Jul 28 18:02:48 2019 Return-Path: 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 B9711120075 for ; Sun, 28 Jul 2019 18:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.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 X4cw3YjmZrgw for ; Sun, 28 Jul 2019 18:02:44 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E7412003E for ; Sun, 28 Jul 2019 18:02:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,320,1559484000"; d="scan'208,217";a="206518727" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 29 Jul 2019 11:02:38 +1000 Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcavi.tcif.telstra.com.au with ESMTP; 29 Jul 2019 11:02:38 +1000 Received: from wsapp6784.srv.dir.telstra.com (10.75.3.133) by wsmsg3751.srv.dir.telstra.com (172.49.40.172) with Microsoft SMTP Server (TLS) id 8.3.485.1; Mon, 29 Jul 2019 11:02:38 +1000 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp6784.srv.dir.telstra.com (10.75.3.133) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Jul 2019 11:02:37 +1000 Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.101.125) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 29 Jul 2019 11:02:37 +1000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RO8wNaeOwfP0c28dVCP0R2OH90p28o64orJP3OhbztOwwcbTI9duc9k1LdIYCytr/NboapGDxuKXhmgxMzrBaKmrlzmuST1ZGaX1FNIl+HEbLz4I5b1JF7oWJ0xcgl6a6aEhI9NmbYOVQ81nnYPxu43ZmHcFcu4w8OkH9UAOicvic6knR/EKTXjQ6dO+ulp3fk7KjluGaw6/B2BfGksq0fKWDgd4k9ImHNNAwsyYpTaQ0yFIpWM2zwz3/wNej9ay7dHNBVCHK9sogXnUC2y9DlvRgjCzvhBr1tP05ECXcI2fLfEidi0/qYSuZNBIVyq5bERjdnaZIgTAsZqRoyXNBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TgDBbHgnN9ZlWddmMYWSwwpZkjIltLyd57p9b8kGpK0=; b=kx4lbt4VmMa3UYdxCkwPfGTAbOT5rZIHapAM2ov28roLjVa+FYIrJtlVDiawv0RzWHvjFjOEYFaK3zZOyW1WVzoOZCdGebTAtAyY9XJc5x/1o76IrJOJoK1aOUxWrpamIf1/D8CWYLESLT9oZsqdvZSGybdoGVqEEmnsr1qRDlFJTMjlsBu+lW+47nIYJPgt+8pTe7d6VvVpa/4HjfuuvNXeDqGDVqPiYOy1rQBiv3TyJu/M7KUfryA4e93mFjs0Bbk/UKVn1BBmOwlGt6DzBZdR8x4wNpoJQjHDQ3IqhU3VKtxpq6wnzOR8unwPqpC7ENqB8QbEt7VvZsNbBN1yQA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=team.telstra.com;dmarc=pass action=none header.from=team.telstra.com;dkim=pass header.d=team.telstra.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TgDBbHgnN9ZlWddmMYWSwwpZkjIltLyd57p9b8kGpK0=; b=goh42zFEsM8qk/5Bz6Oo8eWbkSpwN061bpVwxx23jf1ZGwPVPpdUSSMa/dTxUfl5zpSZJaTTAbUECavLHOHU4IkOl0MfJisJj7AiXPvPlbWa+aejoTQXNIaO0dC8xA0zJjS1+LGFjvsqyBDTi8OcPbEdZBqo7QGfDC79iEKiiAw= Received: from SY2PR01MB2764.ausprd01.prod.outlook.com (52.134.190.138) by SY2PR01MB2988.ausprd01.prod.outlook.com (52.134.187.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.13; Mon, 29 Jul 2019 01:02:36 +0000 Received: from SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::a080:9084:3e2f:68ab]) by SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::a080:9084:3e2f:68ab%4]) with mapi id 15.20.2115.005; Mon, 29 Jul 2019 01:02:36 +0000 From: "Manger, James" To: Ulysse Carion CC: JSON WG Thread-Topic: [Json] JSON Schema Language is nearly done: int53 Thread-Index: AdVFqS7zAUo6y82iShaTcwTHe50WbA== Date: Mon, 29 Jul 2019 01:02:36 +0000 Message-ID: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.41.142.253] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08ec79ae-5a19-40bd-2d0e-08d713c07218 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SY2PR01MB2988; x-ms-traffictypediagnostic: SY2PR01MB2988: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(396003)(136003)(366004)(376002)(346002)(199004)(189003)(6116002)(790700001)(478600001)(229853002)(4744005)(52536014)(3846002)(7696005)(6436002)(99286004)(33656002)(4326008)(5660300002)(14454004)(53936002)(6246003)(6916009)(9686003)(55016002)(6306002)(54896002)(25786009)(6506007)(66446008)(66946007)(66476007)(66556008)(64756008)(76116006)(102836004)(81166006)(81156014)(8676002)(186003)(486006)(66066001)(316002)(26005)(8936002)(2906002)(86362001)(476003)(68736007)(74316002)(256004)(7736002)(71200400001)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:SY2PR01MB2988; H:SY2PR01MB2764.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TRmTsIbde0pJ1KCPJ4XH8O8AZd4VfOXaopW9ukta/1REjTUGg80XKKbD4drfE3tOFo8Ionz/nODkCpfSoTWfY+1iWBLN2lgwTHrG6ZK/GwkzQXNbaC/1U1qgbWGgB0rULNQmPtyoiMv8/lm4+WQO2bB78p3mvSwER2EAOaDsyDA+jQYi0Bw217dgx2qL8YzvDC1FYv6vU/SkbZeKSC77gtU5uivL9zKBve5Q6eGag2VsjScIL0S6mFngKaJILZwInnbZCJIrrDKPI1wpl8eG5l8o467HlM/S8oLzWvZwdSOrXXrn5ZmvM4MUa61msmxqUTouPEeO2CmiE3U4r1w5Lc+OSu/NbD8GHTp3r+ZlkAXY2411A2f6KlSnoGVsEFJhXcs/JCwGnyI2zDfIkXAYJdM+SlOK4g04MNCZMCoi7rM= Content-Type: multipart/alternative; boundary="_000_SY2PR01MB27642C6983E387C397B11581E5DD0SY2PR01MB2764ausp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 08ec79ae-5a19-40bd-2d0e-08d713c07218 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2019 01:02:36.4480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: James.H.Manger@team.telstra.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY2PR01MB2988 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2019 01:02:47 -0000 --_000_SY2PR01MB27642C6983E387C397B11581E5DD0SY2PR01MB2764ausp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBHaXZlbiB0aGF0IGludHJvZHVjaW5nIGludDY0IGFzIGEgSlNPTiBudW1iZXIgdHlwZSB3b3Vs ZCBiZSBhIGZvb3RndW4gZm9yIG1hbnkgc29ydHMgb2YgYXBwbGljYXRpb25zLCBJIGFncmVlIGl0 IHNob3VsZCBiZSBjaGFuZ2VkLg0KPg0KPiBIb3cgd291bGQgeW91IGZlZWwgYWJvdXQgc2ltcGx5 IHJlbW92aW5nIGludDY0L3VpbnQ2NCwgYnV0IG90aGVyd2lzZSBrZWVwaW5nIGV2ZXJ5dGhpbmcg ZWxzZSBhcy1pcz8gSSBkb24ndCBrbm93IGlmIGFkZGluZyAibmF0aXZlIiBzdXBwb3J0IGZvciBz dHJpbmctcmVwcmVzZW50ZWQgYmlnaW50cyBpcyBhIGdyZWF0IGlkZWEsIGFzIHRoZXJlIGFyZSBz byBtYW55IGRpZmZlcmVudCBvcHRpb25zLiBTbWFsbGVyIHNwZWNzIGFyZSB0aGUgb25lcyBtb3N0 IGZyZXF1ZW50bHkgaW1wbGVtZW50ZWQgY29ycmVjdGx5IGFuZCBzZWN1cmVseS4NCg0KSnVzdCBy ZW1vdmluZyBpbnQ2NC91aW50NjQgaXMgb2suIEnigJlkIHByZWZlciB0byBoYXZlIGludDUzLiBJ dCBjb3ZlcnMgYWxsIGludGVnZXIgY2FzZXMgdGhhdCB3b3JrIHNlbnNpYmx5LiBPdGhlciBvcHRp b25zIChpbnQ4LCB1bml0MzIsIGV0YykgYXJlIG1lcmVseSBuaWNlLXRvLWhhdmUgaGludHMgdGhh dCBjb3VsZCBiZSBvbWl0dGVkIGZvciBhIHNtYWxsZXIgc3BlYy4NCg0KLS0NCkphbWVzIE1hbmdl cg0K --_000_SY2PR01MB27642C6983E387C397B11581E5DD0SY2PR01MB2764ausp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUFVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEdpdmVu IHRoYXQgaW50cm9kdWNpbmcgaW50NjQgYXMgYSBKU09OIG51bWJlciB0eXBlIHdvdWxkIGJlIGEg Zm9vdGd1biBmb3IgbWFueSBzb3J0cyBvZiBhcHBsaWNhdGlvbnMsIEkgYWdyZWUgaXQgc2hvdWxk IGJlIGNoYW5nZWQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0OyBIb3cgd291bGQgeW91IGZlZWwgYWJvdXQgc2ltcGx5IHJlbW92aW5nIGludDY0 L3VpbnQ2NCwgYnV0IG90aGVyd2lzZSBrZWVwaW5nIGV2ZXJ5dGhpbmcgZWxzZSBhcy1pcz8gSSBk b24ndCBrbm93IGlmIGFkZGluZyAmcXVvdDtuYXRpdmUmcXVvdDsgc3VwcG9ydCBmb3Igc3RyaW5n LXJlcHJlc2VudGVkIGJpZ2ludHMgaXMgYSBncmVhdCBpZGVhLCBhcyB0aGVyZSBhcmUgc28gbWFu eSBkaWZmZXJlbnQgb3B0aW9ucy4gU21hbGxlcg0KIHNwZWNzIGFyZSB0aGUgb25lcyBtb3N0IGZy ZXF1ZW50bHkgaW1wbGVtZW50ZWQgY29ycmVjdGx5IGFuZCBzZWN1cmVseS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCByZW1vdmluZyBpbnQ2NC91aW50NjQgaXMg b2suIEnigJlkIHByZWZlciB0byBoYXZlIGludDUzLiBJdCBjb3ZlcnMgYWxsIGludGVnZXIgY2Fz ZXMgdGhhdCB3b3JrIHNlbnNpYmx5LiBPdGhlciBvcHRpb25zIChpbnQ4LCB1bml0MzIsIGV0Yykg YXJlIG1lcmVseSBuaWNlLXRvLWhhdmUgaGludHMgdGhhdCBjb3VsZCBiZSBvbWl0dGVkIGZvciBh IHNtYWxsZXIgc3BlYy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SY2PR01MB27642C6983E387C397B11581E5DD0SY2PR01MB2764ausp_-- From nobody Mon Jul 29 21:09:18 2019 Return-Path: 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 4A140120019 for ; Mon, 29 Jul 2019 21:09:16 -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 pJZEQQu1yhPY for ; Mon, 29 Jul 2019 21:09:14 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 6C01712000F for ; Mon, 29 Jul 2019 21:09:14 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id m24so125114724ioo.2 for ; Mon, 29 Jul 2019 21:09: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=Me3qBscSY5WaITfc1vV3NcIv0v/c2YTU1Ww8TIryEpM=; b=UvohFzyXansSkiI17iRL/1teGgFNU6aKn1UKhO/YYoGT3RKPdZRpuOGOB9mng3Dozh BH/+DTwfR8b2cETkwZaSrXYxlpplHXHG5k6VOh+nD52UJ5HxJa8LE8sUwKTNJr4WqBiO fn3SnqagHDQv0RvwLITcZmsZ4gucnlFu+rzM8= 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=Me3qBscSY5WaITfc1vV3NcIv0v/c2YTU1Ww8TIryEpM=; b=pMEHa+9gguYhQRpDySQ8Tdd9upYxFZV+8BoUE2ZZrZaonX0dy5TXtY8Jh1t7zweW0I izJot7JSM+obSZc5zAkGeBoOF1qkr8S8wu3VQv5jYPjILGijqZ7sBELDbty/CkGuXGCS biqyRV3XX+z0N+rgzwj4p00tUKF+9uhxKZ1B2WEYfdyn3jMXRkNj/ASWaKS0b4fbPc2c DxNJwvBKGgq7lTxces4vb/2YOdsOPrMPW1GvVNJl6kOYtKkllichPcmYBZ19jSwVBWxm 2xTIzTRAY6dl3a0xVHikP4JISGrUWcs8Zn2x56P/Pca+fk3RALir7gr1srPRI19q34qT iclQ== X-Gm-Message-State: APjAAAXeowIPahd1g4wi90gVwX5a/woUWlpf9F8g/MFI7fRHdkYsgBAK VX3nf+pvU4HgPBX8ctiZOPkSXWTUr0Akb6PKEL+u1w== X-Google-Smtp-Source: APXvYqy9Dw2NYF/YVcMKzrVG3J11XPbI1l2TrSRiUOssKjoTGfoWkfxDPGJJAQ7OnRvn70dJWPuIs61fb2A+8x5ZewI= X-Received: by 2002:a02:5185:: with SMTP id s127mr46891696jaa.44.1564459753657; Mon, 29 Jul 2019 21:09:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulysse Carion Date: Mon, 29 Jul 2019 21:09:02 -0700 Message-ID: To: "Manger, James" Cc: JSON WG Content-Type: multipart/alternative; boundary="000000000000e1f252058ede2bfc" Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 04:09:16 -0000 --000000000000e1f252058ede2bfc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Perhaps int53 is a footgun for reasons similar to int64? Folks in practice might pretend int53 is int64 for all intents and purposes, incurring the same problems. In the interest of keeping the spec small, safe, and unsurprising, I think simply removing int64/uint64, but preserving the other types (including less common ones like int8) may be the best option. I'd rather not arbitrarily leave out powers of two or particular signed/unsigned variants, nor leave in features which make it likelier that people make faulty assumptions about interoperable JSON. On Sun, Jul 28, 2019 at 6:02 PM Manger, James < James.H.Manger@team.telstra.com> wrote: > > Given that introducing int64 as a JSON number type would be a footgun > for many sorts of applications, I agree it should be changed. > > > > > > How would you feel about simply removing int64/uint64, but otherwise > keeping everything else as-is? I don't know if adding "native" support fo= r > string-represented bigints is a great idea, as there are so many differen= t > options. Smaller specs are the ones most frequently implemented correctly > and securely. > > > > Just removing int64/uint64 is ok. I=E2=80=99d prefer to have int53. It co= vers all > integer cases that work sensibly. Other options (int8, unit32, etc) are > merely nice-to-have hints that could be omitted for a smaller spec. > > > > -- > > James Manger > --000000000000e1f252058ede2bfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perhaps int53 is a footgun for reasons similar to in= t64? Folks in practice might pretend int53 is int64 for all intents and pur= poses, incurring the same problems.

In the int= erest of keeping the spec small, safe, and unsurprising, I think simply rem= oving int64/uint64, but preserving the other types (including less common o= nes like int8) may be the best option. I'd rather not arbitrarily leave= out powers of two or particular signed/unsigned variants, nor leave in fea= tures which make it likelier that people make faulty assumptions about inte= roperable JSON.

On Sun, Jul 28, 2019 at 6:02 PM Manger, James <= James.H.Manger@team.tels= tra.com> wrote:

> Given that introducing int64 as a JSON number t= ype would be a footgun for many sorts of applications, I agree it should be= changed.

>=C2=A0

> How would you feel about simply removing int64/= uint64, but otherwise keeping everything else as-is? I don't know if ad= ding "native" support for string-represented bigints is a great i= dea, as there are so many different options. Smaller specs are the ones most frequently implemented correctly and securely.<= /u>

=C2=A0

Just removing int64/uint64 is ok. I=E2=80=99d prefer= to have int53. It covers all integer cases that work sensibly. Other optio= ns (int8, unit32, etc) are merely nice-to-have hints that could be omitted = for a smaller spec.

=C2=A0

--

James Manger

--000000000000e1f252058ede2bfc-- From nobody Mon Jul 29 21:35:20 2019 Return-Path: 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 E00D51201E6 for ; Mon, 29 Jul 2019 21:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.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 eP3H2clA4826 for ; Mon, 29 Jul 2019 21:35:07 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E3F1203DD for ; Mon, 29 Jul 2019 21:35:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,325,1559484000"; d="scan'208,217";a="295616889" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 30 Jul 2019 14:35:04 +1000 Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcani.tcif.telstra.com.au with ESMTP; 30 Jul 2019 14:35:04 +1000 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by WSMSG3705.srv.dir.telstra.com (172.49.40.203) with Microsoft SMTP Server (TLS) id 8.3.485.1; Tue, 30 Jul 2019 14:34:56 +1000 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Jul 2019 14:34:07 +1000 Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.229.125) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 30 Jul 2019 14:34:07 +1000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UM5Ifyc2J7dYN2NknGH1NawQHjVSPRe4xvNHXKhs7nZtfqt9llPrJ/PjUeAAKISottOwLYgnkSmYeUzTegEodpMWq5nWn8tY8BCiuQYU9HSehk+K9pQ0faeFB+VwRq27JzlN1hINZ3q+DrbCGzjDJZvIIHqqR5Zd/MnPC06kHhHvjf9A4FV8YEi1OSBq7sW/Q2aHaVPuEYAW639hicliCyL5E7Na0+wslu+TTTNAmolmJ0FQP6F+4mwa1fDhWox22mosoJzbw/IGChQ78aQqCaIgj8NcymrWn/4IUJZfzl7rRwDYtOetlvJNx4g4vgffLrXmxv0c7EFJuQ6XjoQgSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pFzZWiXJKE7Nz6zsyvHA1pEsQSuN3HVMUSXmHcakJmE=; b=UnvVz01ecQqNAIOgcAfhANfZq2ZPjpJju09OVgjUPqu8VbITMjK3i7I0IebhdPpyTkviKpxK7eLLto/JtV9fUoXRY6IfE50UF3UcQJIS3ybByl4KtwQ51R5GXwjumgi8vFLrYedV6MgrLkqVBqKzpPKAjReobckJKHj4G1PwpbbQ+rliGZXYBPCFJpyQrtt7N/dMhyI5dj30tyxRyHyJWeQ3d7Ubrp1G06P8I4eSFJZBagteQIaHBMchzAKQTw6C0wV8DuzcqY2SpxIjPYxGkcYFxYziyfZ6khxZ48gSa3bRad4yYdLUjqr6SF9nx99WrfaBZkv/e7r8JqDSRo+K7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=team.telstra.com;dmarc=pass action=none header.from=team.telstra.com;dkim=pass header.d=team.telstra.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pFzZWiXJKE7Nz6zsyvHA1pEsQSuN3HVMUSXmHcakJmE=; b=aLzLZU3wyilKJGpxuUFOxlqWO+PDobLg5nGoOwMlWaw0UtzFD281M7jjeM//dymveFPl+xf02vrAAdwk5bfhwOFCmhY/FymsHKq+5Ik+CNfIP06b5xtMxM5hsaJ9cpRbrHWLpY8L9HqgesJcYFhBzyJAjegC16whSOuSanDOsmE= Received: from SY2PR01MB2764.ausprd01.prod.outlook.com (52.134.190.138) by SY2PR01MB3115.ausprd01.prod.outlook.com (52.134.169.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.15; Tue, 30 Jul 2019 04:34:07 +0000 Received: from SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::a080:9084:3e2f:68ab]) by SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::a080:9084:3e2f:68ab%4]) with mapi id 15.20.2115.005; Tue, 30 Jul 2019 04:34:06 +0000 From: "Manger, James" To: Ulysse Carion CC: JSON WG Thread-Topic: [Json] JSON Schema Language is nearly done: int53 Thread-Index: AdVFqS7zAUo6y82iShaTcwTHe50WbAA41YoAAAAx+iA= Date: Tue, 30 Jul 2019 04:34:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.35.9.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7eb85235-9c91-4afd-fc2c-08d714a72895 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SY2PR01MB3115; x-ms-traffictypediagnostic: SY2PR01MB3115: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(136003)(39860400002)(366004)(346002)(376002)(199004)(189003)(6246003)(7736002)(74316002)(8936002)(26005)(186003)(478600001)(3846002)(2906002)(6916009)(81156014)(81166006)(8676002)(68736007)(86362001)(486006)(4326008)(6436002)(9686003)(33656002)(229853002)(53936002)(66476007)(316002)(11346002)(52536014)(476003)(5660300002)(66556008)(64756008)(66446008)(446003)(76116006)(66946007)(55016002)(6506007)(790700001)(6116002)(76176011)(14454004)(102836004)(7696005)(14444005)(256004)(71190400001)(71200400001)(6306002)(25786009)(4744005)(54896002)(99286004)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:SY2PR01MB3115; H:SY2PR01MB2764.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EYFqeG1o+5eOuGClF0B5nXnf8VL/SLjnXPvJvmKydl+Vhcqk49tsG0F9FRawBpJoXZ9Ba+TrIrb5orIAQ62WE/0c5rZVZM2mqiRx6geRqW1pAohJSjQN6raJkmCRxvdGJKyraukoG8R2wVpN21KoNIlemamZ/Pmfz8IHMIj3uEj2ZV7wSY0a+4FIy9OWZidoSysck2IZU9tlwfEeuN+GH23ZYLj2ldN8GWRRMPX8Uuqg0WUSRlL0MbhQhRgkCDzZNSD9h13AWKkbi9uXVimRnqLtCHrgZfr/AKAlyZlg8JIlGJd5czPx40BijF0XHux8xBvxoVnLDD419tKXu3SsNItxgdhXQrhNAPYO6vU9Z4K2vp3x1MxMaR5eav6zdp/NbokLNSTEBPP1MuVh2BeniuaUh75n4YH/IxIBLMOt04s= Content-Type: multipart/alternative; boundary="_000_SY2PR01MB2764AD4523625006B1F3DFEBE5DC0SY2PR01MB2764ausp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7eb85235-9c91-4afd-fc2c-08d714a72895 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2019 04:34:06.8756 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: James.H.Manger@team.telstra.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY2PR01MB3115 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 04:35:18 -0000 --_000_SY2PR01MB2764AD4523625006B1F3DFEBE5DC0SY2PR01MB2764ausp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBQZXJoYXBzIGludDUzIGlzIGEgZm9vdGd1biBmb3IgcmVhc29ucyBzaW1pbGFyIHRvIGludDY0 PyBGb2xrcyBpbiBwcmFjdGljZSBtaWdodCBwcmV0ZW5kIGludDUzIGlzIGludDY0IGZvciBhbGwg aW50ZW50cyBhbmQgcHVycG9zZXMsIGluY3VycmluZyB0aGUgc2FtZSBwcm9ibGVtcy4NCg0KWW91 IGhhdmUgdG8gYmUgZmFpcmx5IHdpbGZ1bCB0byBpZ25vcmUgdGhhdCDigJxpbnQ1M+KAnSBpc27i gJl0IGRlc2lnbmVkIGZvciBhbGwgNjQtYml0IGludGVnZXJzLg0KQW5kIGlmIDEgcGFydHkgaWdu b3JlZCB0aGF0LCBpdCBpcyBpbW1lZGlhdGVseSBvYnZpb3VzIHdobyBpcyDigJxhdCBmYXVsdOKA nSB3aGVuIGludGVyb3AgZmFpbHMuDQoNCkhvdyBjcnVjaWFsIGlzIGl0IHRoYXQgY29kZS1nZW4g Y2FuIGNyZWF0ZSB1aW50OCwgaW50MzIgZmllbGRzIGV0Yz8gQXMgSlNPTiBpcyB0aGUgZXhjaGFu Z2UgZm9ybWF0IHlvdSBhcmVu4oCZdCBzYXZpbmcgYW55IGJ5dGVzIGZvciB0cmFuc21pc3Npb24u IEkgZ3Vlc3MgeW91IG1pZ2h0IHNhdmUgYSBmZXcgYnl0ZXMgaW4gbWVtb3J5LiBJ4oCZbSBub3Qg c3VyZSBob3cgaW1wb3J0YW50IHRoYXQgaXMuIElmIGl0IGlzLCB0aG9zZSBjYXNlcyBkb27igJl0 IGhhdmUgdG8gdXNlIGNvZGUtZ2VuLg0KDQpJbmNsdWRlIGludDgsIGludDE2LCAmIGludDMyIGFu ZCBwZW9wbGUgd2lsbCB3YW50IGludDY0IChvciBleHRyYXBvbGF0ZSBzb21lIGltcGxlbWVudGF0 aW9ucyB0byBpbnQ2NCkuDQpJbmNsdWRlIGludDUzIGFuZCB0aGV54oCZbGwga25vdyB0aGF04oCZ cyBhbGwgdGhleSBnZXQuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== --_000_SY2PR01MB2764AD4523625006B1F3DFEBE5DC0SY2PR01MB2764ausp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUFVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZndDsgPC9zcGFuPlBlcmhhcHMgaW50NTMg aXMgYSBmb290Z3VuIGZvciByZWFzb25zIHNpbWlsYXIgdG8gaW50NjQ/IEZvbGtzIGluIHByYWN0 aWNlIG1pZ2h0IHByZXRlbmQgaW50NTMgaXMgaW50NjQgZm9yIGFsbCBpbnRlbnRzIGFuZCBwdXJw b3NlcywgaW5jdXJyaW5nIHRoZSBzYW1lIHByb2JsZW1zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPllvdSBoYXZlIHRvIGJlIGZhaXJseSB3 aWxmdWwgdG8gaWdub3JlIHRoYXQg4oCcaW50NTPigJ0gaXNu4oCZdCBkZXNpZ25lZCBmb3IgYWxs IDY0LWJpdCBpbnRlZ2Vycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFuZCBpZiAxIHBh cnR5IGlnbm9yZWQgdGhhdCwgaXQgaXMgaW1tZWRpYXRlbHkgb2J2aW91cyB3aG8gaXMg4oCcYXQg ZmF1bHTigJ0gd2hlbiBpbnRlcm9wIGZhaWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Ib3cgY3J1Y2lhbCBpcyBpdCB0aGF0 IGNvZGUtZ2VuIGNhbiBjcmVhdGUgdWludDgsIGludDMyIGZpZWxkcyBldGM/IEFzIEpTT04gaXMg dGhlIGV4Y2hhbmdlIGZvcm1hdCB5b3UgYXJlbuKAmXQgc2F2aW5nIGFueSBieXRlcyBmb3IgdHJh bnNtaXNzaW9uLiBJIGd1ZXNzIHlvdSBtaWdodCBzYXZlIGEgZmV3IGJ5dGVzIGluIG1lbW9yeS4g SeKAmW0NCiBub3Qgc3VyZSBob3cgaW1wb3J0YW50IHRoYXQgaXMuIElmIGl0IGlzLCB0aG9zZSBj YXNlcyBkb27igJl0IGhhdmUgdG8gdXNlIGNvZGUtZ2VuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JbmNsdWRlIGludDgsIGlu dDE2LCAmYW1wOyBpbnQzMiBhbmQgcGVvcGxlIHdpbGwgd2FudCBpbnQ2NCAob3IgZXh0cmFwb2xh dGUgc29tZSBpbXBsZW1lbnRhdGlvbnMgdG8gaW50NjQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SW5jbHVkZSBpbnQ1MyBhbmQgdGhleeKAmWxsIGtub3cgdGhhdOKAmXMgYWxsIHRoZXkg Z2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SY2PR01MB2764AD4523625006B1F3DFEBE5DC0SY2PR01MB2764ausp_-- From nobody Tue Jul 30 03:24:47 2019 Return-Path: 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 C0A3A1203DE for ; Tue, 30 Jul 2019 03:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7LbeGKyQBlgh for ; Tue, 30 Jul 2019 03:24:43 -0700 (PDT) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266F21203D5 for ; Tue, 30 Jul 2019 03:24:43 -0700 (PDT) Received: (qmail 5933 invoked from network); 30 Jul 2019 11:22:17 +0100 Received: from host109-149-217-70.range109-149.btcentralplus.com (HELO ?192.168.1.72?) (109.149.217.70) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 30 Jul 2019 11:22:16 +0100 To: "Manger, James" , Ulysse Carion Cc: JSON WG References: From: Pete Cordell Message-ID: <3812d923-61ea-3a2a-54a3-f3dcf9adeaad@codalogic.com> Date: Tue, 30 Jul 2019 11:24:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 10:24:46 -0000 On 30/07/2019 05:34, Manger, James wrote: >> Perhaps int53 is a footgun for reasons similar to int64? Folks in > practice might pretend int53 is int64 for all intents and purposes, > incurring the same problems. > > You have to be fairly wilful to ignore that “int53” isn’t designed for > all 64-bit integers. > > And if 1 party ignored that, it is immediately obvious who is “at fault” > when interop fails. > > How crucial is it that code-gen can create uint8, int32 fields etc? As > JSON is the exchange format you aren’t saving any bytes for > transmission. I guess you might save a few bytes in memory. I’m not sure > how important that is. If it is, those cases don’t have to use code-gen. int8 etc let's you know that 8 bits is sufficient. It doesn't mean it has to be stored in an 8 bit integer. But it can be if that helps your system. > Include int8, int16, & int32 and people will want int64 (or extrapolate > some implementations to int64). > > Include int53 and they’ll know that’s all they get. IoT is supposedly still on the increase. Some smaller systems do not have float types so the one true int53 type doesn't work there. Allow the specification to capture the information the designers need to build their system and let them work out how to meet the requirements. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Tue Jul 30 22:02:57 2019 Return-Path: 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 721CF120075 for ; Tue, 30 Jul 2019 22:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 B0xFnQrdTvsC for ; Tue, 30 Jul 2019 22:02:53 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 7AD82120019 for ; Tue, 30 Jul 2019 22:02:53 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id 31so68135229wrm.1 for ; Tue, 30 Jul 2019 22:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=v62x5DUVZiBATuhARsur5NuG8Pr5s8gW4nZPoqFFh6I=; b=O0vAUW/pl8KQFKItix7xOli8giq+YnRwp5qtbkyYQso8glrNrwUzi1C4UB/Py+WfBT 1KTikKQ7Nto0mheC0WxgVbxjp/58ndQCKzViTJL3ycwG1xkfyYzGFkRzZ4iAvhJtP8mi L7Fx/Sc416PkJsvdAmstKJXWiCS6LOMxAZxqeD/WgC475+/y5uZVxuUz61qKFp+rLqUi aQ1jd5wNSa1uXmgdq5yuFqKZdEGlu94N5abXuA3Uec+RUsSYnmb6fBnVCm/2ZGNENExM 4MBg5w9t7rUjzpyamUJzufp9yi4Nfb1P/KdvEuegl4NF8QMXU3Lkp4RZqnCwjbaPImdV aphA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v62x5DUVZiBATuhARsur5NuG8Pr5s8gW4nZPoqFFh6I=; b=YFIegG+G7bjQwxIqIaspIXernap6I9As2iwrie6lw4Uhna9iUs74NDBhvP1fcueaQR gy0QwQCDmE/qaqgGgIbaVlg6KdHxC6UFigfRE1f2xu/9emmcKTHaKFYlT62u4DrjMlXV syHAlgLeles2c+TjEmSE4lB4kpC9iTmM19QhI2UR/jdD4fEjHyFp5i19rdHMHJ05MksK DU5ws5anVKXCYQWeGfL5cZ5IFGAOoSoVMuWZQb/Rbc117R9zIH2OQbVSfxfP1EnhNs04 Zy9idGMFCG2/pRSW4Bu+UrxADvKmMB7QzuJe/jHpG+ZJMOop02FU8a3MJ70nIcsP4okL euUA== X-Gm-Message-State: APjAAAWe9I2DzgHpADmHtR1M7C0yUj0+qBt5ZVaGH/6DhYkcqgLQjy09 gYOur6tEviWBsdH0X6m38J4buXmm X-Google-Smtp-Source: APXvYqyG9lqr7g+HVTEKIs28gPqZJBZtD9ogVV3nfLsK+mUGBi18obggW0pJ9npapZCnNlm5WCFkWA== X-Received: by 2002:a5d:6182:: with SMTP id j2mr83405510wru.275.1564549371388; Tue, 30 Jul 2019 22:02:51 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id g12sm98004644wrv.9.2019.07.30.22.02.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jul 2019 22:02:50 -0700 (PDT) To: JSON WG References: From: Anders Rundgren Message-ID: Date: Wed, 31 Jul 2019 07:02:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 05:02:56 -0000 Dropping int64 is hardly an option, neither is BigInteger. int53 is a special that for example fits UNIX "epoch". The purpose of fixed sized integers in data formats is not to save bytes, it is about valid ranges and compatibility with languages like Java and C++. Arbitrarily sized integers are used by tons of applications based on JSON messaging and is available for most platforms including JS. The monetary type is an item of its own. That there are multiple ways of formatting integers in JSON is unfortunately a reality all JSON tool maker must (in some way) address. I would reverse the integer syntax and claim that integers SHOULD conform to standard integer (not JSON) syntax since a standard should not break the multitude of JSON tools that already implement this. A scheme author who thinks this is "wrong" should use "number" giving them the whole JSON number syntax. Anders From nobody Tue Jul 30 23:56:25 2019 Return-Path: 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 C2AAB12004E for ; Tue, 30 Jul 2019 23:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.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 T3KBSh_bc5X7 for ; Tue, 30 Jul 2019 23:56:20 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE38C12001B for ; Tue, 30 Jul 2019 23:56:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,329,1559484000"; d="scan'208";a="318003444" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 31 Jul 2019 16:56:16 +1000 Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbvi.tcif.telstra.com.au with ESMTP; 31 Jul 2019 16:56:16 +1000 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsmsg3756.srv.dir.telstra.com (172.49.40.84) with Microsoft SMTP Server (TLS) id 8.3.485.1; Wed, 31 Jul 2019 16:56:16 +1000 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 31 Jul 2019 16:56:14 +1000 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.229.126) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 31 Jul 2019 16:56:14 +1000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Okb7uXrOGoQEu9IYVpOHe9OGzFBvSlR5HIoO5YX+Ifcg+cNWmCjl4LKCPK1T2qgAhv3dBmz1SdrBenR9dZ410O491KlcVe7CaoWdjUFsOTMp61pTr+cjGw3beKpq8nRiVXlsmTYA2DyvG4aXTEAv3Rsjg4k3U2Zxp8/x+w9ZIHg+rb5lDIcS4NQWLFPWnP2+L2FG574lEbb0XCNNULJrd838k3gNRUm4105Ud9tH2ZsnfCqPrb/Zkx4US8P+iErhULRs+fCoILUUZRsCPMLAwYWKWJqyKRZA5ymUSDi16Zq1tkb3D64N7XwtBFzOxxJzL6KNW17udSUdpODnmzcJCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xodUCwWREBrnWXnat/mWdNt2z0EQMPzoTyAb9KlTBBE=; b=lwWj04HxCVqYZPb3NwNrq8k0ofXqKzL0YOkKzwk6D+QfEP9T8cy7GMa4pNzHWSAWZn2t3OwGVFjFTUjLXP1w7tLSoGbR9UfrzVECMmWZGDBRq57uAz0ybSioXFbMJjVZ6wN5qBEbJJ2Nr5f+Gff18SQEIidvQd47xEp5LRsp9wu4pdKYdCecIS2jv/XHdvcXW4C8ieVVcCheHYRCVtR0I3H6JJmYWtcuNqyHhr88iH0y6Lx3sjsRdaRvoVoDYPnTSVqLhzNV4oRGs3c9DSlgA+zqnyV+h2taAz8WHutidCB2MpLD4ifmEdQkZJArLwEPMa5cxCKcviOJgUcBfO4rnw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=team.telstra.com;dmarc=pass action=none header.from=team.telstra.com;dkim=pass header.d=team.telstra.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xodUCwWREBrnWXnat/mWdNt2z0EQMPzoTyAb9KlTBBE=; b=mH1mJ9ExWTHrJh2KSPmc13bIrVJL2NcYwPiapcDuSmG4pbq5i8qPgtev48dOEmrjmTB/CPXHnHD/DyUuvsmikpjDtYbSjQXKcgVLgFiXf51yTojGQwfYusFF/g2QxlHBzLgHXDsS5grTuFWDBVqSVhy5iynDZ6XabWxMzUyOv1M= Received: from SY2PR01MB2764.ausprd01.prod.outlook.com (52.134.190.138) by SY2PR01MB2825.ausprd01.prod.outlook.com (52.134.187.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.15; Wed, 31 Jul 2019 06:56:13 +0000 Received: from SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::a080:9084:3e2f:68ab]) by SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::a080:9084:3e2f:68ab%4]) with mapi id 15.20.2115.005; Wed, 31 Jul 2019 06:56:13 +0000 From: "Manger, James" To: Anders Rundgren , JSON WG Thread-Topic: [Json] JSON Schema Language is nearly done: int53 Thread-Index: AdVFqS7zAUo6y82iShaTcwTHe50WbAA41YoAAAAx+iAAM/kxgAABR4mQ Date: Wed, 31 Jul 2019 06:56:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.41.142.253] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa441f87-54d7-4299-9547-08d715842d40 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SY2PR01MB2825; x-ms-traffictypediagnostic: SY2PR01MB2825: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(346002)(376002)(366004)(396003)(136003)(189003)(199004)(102836004)(52536014)(66556008)(86362001)(66476007)(6116002)(71190400001)(5660300002)(6506007)(76116006)(25786009)(7696005)(64756008)(66066001)(486006)(55016002)(99286004)(305945005)(66446008)(71200400001)(9686003)(186003)(76176011)(110136005)(3846002)(6246003)(66946007)(229853002)(74316002)(11346002)(81166006)(6436002)(68736007)(14454004)(2906002)(8676002)(26005)(316002)(33656002)(256004)(53936002)(8936002)(446003)(81156014)(478600001)(7736002)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:SY2PR01MB2825; H:SY2PR01MB2764.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: l541G7GVKjeZ4s57Ifd1fFHtBKKxDg0Q99Xhtu6TXJnZvLotXTiRMD0DHOu44eoUkZK3EZlPlIL/BZNZLZKdAkTMv5i8W+9sd+vxOiH+CI0yg9W2TwOPeUr/A4JvyNL2ukEP2X6edxhR4nofgZUjnhca6o15pSrVc9KnHNrinz/lIVcKzAvzRTxMIgZ2nkt+5iVnnxPAImwQRwkCEf8obS17obkD3y0MEXrS05O72+1VA/oqPIF2+3Zd04qH3sJEp7JRPFUzhfAjyPw4UzLm3efKzuS204IumtaT9/5y9EEdQIbarT7y9Lx8vRKNJxnC19r6/TqJMDs5RYpyqXt40mKPcINrlQSZB8C+m83BVlVQ+HnY84JiqT4xVbJCmEfFWtB2nOkYWn6fsvnzdLv7Zw/q2+LuWkybnP8nXP5lcoU= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aa441f87-54d7-4299-9547-08d715842d40 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 06:56:13.2299 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: James.H.Manger@team.telstra.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY2PR01MB2825 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 06:56:24 -0000 PiBEcm9wcGluZyBpbnQ2NCBpcyBoYXJkbHkgYW4gb3B0aW9uLCBuZWl0aGVyIGlzIEJpZ0ludGVn ZXIuICAgaW50NTMgaXMgYSBzcGVjaWFsIHRoYXQgZm9yIGV4YW1wbGUgZml0cyBVTklYICJlcG9j aCIuDQoNCkRyb3BwaW5nIGludDY0IG9yIEJpZ0ludGVnZXIgZnJvbSAqcHJvZ3JhbW1pbmcgbGFu Z3VhZ2VzKiBpcyBub3QgYW4gb3B0aW9uLiBCdXQgZHJvcHBpbmcgdGhlIGFiaWxpdHkgZm9yIGEg SlNPTiBzY2hlbWEgdG8gc3VnZ2VzdCB0aGF0IGFyYml0cmFyeSB2YWx1ZXMgb2YgdGhvc2UgdHlw ZXMgc2hvdWxkIGJlIHNlcmlhbGl6ZWQgdG8gSlNPTiBudW1iZXJzIHdvdWxkIGJlIHNlbnNpYmxl Lg0KDQo+IEFyYml0cmFyaWx5IHNpemVkIGludGVnZXJzIGFyZSB1c2VkIGJ5IHRvbnMgb2YgYXBw bGljYXRpb25zIGJhc2VkIG9uIEpTT04gbWVzc2FnaW5nIGFuZCBpcyBhdmFpbGFibGUgZm9yIG1v c3QgcGxhdGZvcm1zIGluY2x1ZGluZyBKUy4NCg0KU3VyZSwgYnV0IHRoZXkgYXJlIG5vdCBzZXJp YWxpemVkIHRvIGEgSlNPTiBudW1iZXIuIFRoZXkgYXJlIHNlcmlhbGl6ZWQgdG8gYSBKU09OIHN0 cmluZyBvZiBzb21lIGZvcm0gKGVnICI2NTUzNy4wMCIgb3IgIkFRQUIiKS4NCg0KPiBUaGF0IHRo ZXJlIGFyZSBtdWx0aXBsZSB3YXlzIG9mIGZvcm1hdHRpbmcgaW50ZWdlcnMgaW4gSlNPTiBpcyB1 bmZvcnR1bmF0ZWx5IGEgcmVhbGl0eSBhbGwgSlNPTiB0b29sIG1ha2VyIG11c3QgKGluIHNvbWUg d2F5KSBhZGRyZXNzLg0KDQpBcmUgeW91IHJlZmVycmluZyB0byAxMjMsIDEyMy4wLCAxMi4zRSsx IGFuZCAxLjIzZTIgYXMgdGhlIG11bHRpcGxlIHdheXM/IE9yIDEyMywgIjEyMyIsICIxMjMuMDAi LCBhbmQgImV3PT0iIGFzIHRoZSBtdWx0aXBsZSB3YXlzPw0KDQo+IEkgd291bGQgcmV2ZXJzZSB0 aGUgaW50ZWdlciBzeW50YXggYW5kIGNsYWltIHRoYXQgaW50ZWdlcnMgU0hPVUxEIGNvbmZvcm0g dG8gc3RhbmRhcmQgaW50ZWdlciAobm90IEpTT04pIHN5bnRheCBzaW5jZSBhIHN0YW5kYXJkIHNo b3VsZCBub3QgYnJlYWsgdGhlIG11bHRpdHVkZSBvZiBKU09OIHRvb2xzIHRoYXQgYWxyZWFkeSBp bXBsZW1lbnQgdGhpcy4NCg0KSXQgc291bmRzIGxpa2UgeW91IHdhbnQgSlNPTiBzZXJpYWxpemVy cyB0byBuZXZlciB1c2UgdGhlIGZyYWN0aW9uIG9yIGV4cG9uZW50IG5vdGF0aW9ucyB3aGVuIGEg c2NoZW1hIHNheXMgYSBmaWVsZCBpcyBhbiBpbnRlZ2VyLiBUaGF0J3MgYWRkaW5nIGEgZGlzdGlu Y3Rpb24gdGhhdCBkb2Vzbid0IGV4aXN0IGluIEpTT04gc28gaXQgd2lsbCBicmVhayB0aGluZ3Mu IEEgdG9vbCBwYXJzaW5nIEpTT04gKndpdGhvdXQga25vd2luZyB0aGUgc2NoZW1hKiBtYXkgd2Vs bCB1c2UgYSBkb3VibGUgZm9yIGEgbnVtYmVyLCB3aGljaCBpdCBtYXkgdGhlbiBzZXJpYWxpemUg aW4gZXhwb25lbnQgbm90YXRpb24gZXZlbiBpZiBpdCBpcyBhbiBpbnRlZ2VyLiBGb3IgaW5zdGFu Y2UsIGluIEphdmEgRG91YmxlLnRvU3RyaW5nKDEyMzAwMDAwMCkgcmV0dXJucyAiMS4yM0U4Ii4N Ck1pbmQgeW91LCBJIHN1c3BlY3QgMS4yM0U4IHdpbGwgYnJlYWsgbWFueSBpbXBsZW1lbnRhdGlv bnMgdGhhdCBleHBlY3QgYW4gaW50ZWdlciBzbyBwZXJoYXBzIHdlIHNob3VsZCByZXF1aXJlIHRo ZSBuby1mcmFjdGlvbi1uby1leHBvbmVudCBmb3JtLg0KDQpUaGlzIGlzIGEgc2VwYXJhdGUgaXNz dWUgdG8gdGhpcyB0aHJlYWQsIGhvd2V2ZXIsIHdoaWNoIHdhcyB3aGV0aGVyIGEgSlNPTiBzY2hl bWEgc2hvdWxkIG9mZmVyICJpbnQ1MyIgYXMgYSB0eXBlLCBhbmQgaWYgaXQgc2hvdWxkIG9mZmVy ICJ7dX1pbnR7OHwxNnwzMn0iIGFzIHR5cGVzLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From nobody Wed Jul 31 00:14:30 2019 Return-Path: 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 3DB4A12008F for ; Wed, 31 Jul 2019 00:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8ujVJKMJ-ziE for ; Wed, 31 Jul 2019 00:14:27 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 A2A9A120088 for ; Wed, 31 Jul 2019 00:14:26 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id n9so43336379wrr.4 for ; Wed, 31 Jul 2019 00:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=VAH/R1/0nymgvQGjVGldIu+EKc1Z6zgFGH3ggm6MWXs=; b=Hk+uj90D+iwHDBh70Cxp4NOIfUO8F6eRYkVIbRql1qZMSTVd1cpQimgXHFCbBfsvMe RUcLeSUe4XmwWpjiDdHcS7BH/SZSStoAeLFhmn8JfuNdvNkgMAaOSPXaotYKBTa+Q/EQ jWWepfFQ0k1PYJxIoG/bmnylpeCIu3rc9NrxNlYbc2cs0v/tTqY6Qg3Dy56wHLonlGDg v3eD7W1HGeRhSldRqYmZKCYP/cUJmKWFdtQQ+7pBpX5y7FTC/0gEOGq+ySbsq/UDkb5C zJQA0mDKPxn/ExFKnDbVKz3kMMF5YUs4q7VThLGlawJtC4dkjrGvVbMAfidpgJCltbcI QvFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VAH/R1/0nymgvQGjVGldIu+EKc1Z6zgFGH3ggm6MWXs=; b=qCgD33UtldQchG1hFvaLZ/HS71s+1xk5C0OXhYNMOowFMwgMwucF+LHUu7CYNjWf+L Z+CmQAzlR+6bBpDroBRfOX2+3mD43+vzWqHI8+TkxpT+EMKD0LFJ6DKX5uCtU9fHqqL6 mY4X9ehoZa21aL97F8bWj0fTiSKiZhgO2sLQt4QDPOYcmTzkgCWa0ssvwOoMuxEVUsJf hNzFLVFmdrx09BS+ae8tc6rHhqozb3+ySZANFD01DcPNM7lttgfm6jSIORmgmKviPvWC WJXWvNJd5+/SUGDB/WbdmhmT9HRn+YuzR2fvp3TPpQKv8fV3wpkL3IZZZv7gzOwyKfXl Ga9w== X-Gm-Message-State: APjAAAXLMU0gKDeyr4ii6rfkR9dv8TRpcnUS2Uw1ZhdqGbUtjQFUsvi+ G3cEL2kVuRMfv/lSVT2uFdu8dthf X-Google-Smtp-Source: APXvYqyivpjULIoZDMQtv0najDKxJsgTkc9PLrTzFjBDN6oxuu1xB3AermHLvVU9qWBy/5zTak9U0A== X-Received: by 2002:a5d:4941:: with SMTP id r1mr127273589wrs.225.1564557264597; Wed, 31 Jul 2019 00:14:24 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id o20sm170612961wrh.8.2019.07.31.00.14.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jul 2019 00:14:23 -0700 (PDT) To: "Manger, James" , JSON WG References: From: Anders Rundgren Message-ID: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com> Date: Wed, 31 Jul 2019 09:14:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 07:14:29 -0000 On 2019-07-31 08:56, Manger, James wrote: >> Dropping int64 is hardly an option, neither is BigInteger. int53 is a special that for example fits UNIX "epoch". > > Dropping int64 or BigInteger from *programming languages* is not an option. But dropping the ability for a JSON schema to suggest that arbitrary values of those types should be serialized to JSON numbers would be sensible. > >> Arbitrarily sized integers are used by tons of applications based on JSON messaging and is available for most platforms including JS. > > Sure, but they are not serialized to a JSON number. They are serialized to a JSON string of some form (eg "65537.00" or "AQAB"). This is where we (as a community of users) have a problem. Jackson (now adopted by MSFT) indeed serializes BigInteger as JSON Number. Other parties like Oracle have taken another (presumable unique) approach by using JSON number for int53-compliant BigIntegers and string notation for BigIntegers that doesn't fits int53. I believe Oracle are considering a redesign though. The following lines in Chrome shows this division in clear: var big = 5n; JSON.stringify(big) > VM887:1 Uncaught TypeError: Do not know how to serialize a BigInt at Object.stringify () at :1:6 Anders > >> That there are multiple ways of formatting integers in JSON is unfortunately a reality all JSON tool maker must (in some way) address. > > Are you referring to 123, 123.0, 12.3E+1 and 1.23e2 as the multiple ways? Or 123, "123", "123.00", and "ew==" as the multiple ways? > >> I would reverse the integer syntax and claim that integers SHOULD conform to standard integer (not JSON) syntax since a standard should not break the multitude of JSON tools that already implement this. > > It sounds like you want JSON serializers to never use the fraction or exponent notations when a schema says a field is an integer. That's adding a distinction that doesn't exist in JSON so it will break things. A tool parsing JSON *without knowing the schema* may well use a double for a number, which it may then serialize in exponent notation even if it is an integer. For instance, in Java Double.toString(123000000) returns "1.23E8". > Mind you, I suspect 1.23E8 will break many implementations that expect an integer so perhaps we should require the no-fraction-no-exponent form. > > This is a separate issue to this thread, however, which was whether a JSON schema should offer "int53" as a type, and if it should offer "{u}int{8|16|32}" as types. > > -- > James Manger > From nobody Wed Jul 31 20:55:45 2019 Return-Path: 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 6CF3B12013B for ; Wed, 31 Jul 2019 20:55:42 -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 iFz_IuyCmVMh for ; Wed, 31 Jul 2019 20:55:38 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 A75BB120136 for ; Wed, 31 Jul 2019 20:55:38 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id q22so21456261iog.4 for ; Wed, 31 Jul 2019 20:55:38 -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=Q4p8yTGHfiXikjl7w+qq6gihCxoUI1zqCay5cK8rxI4=; b=r6JUuSI1YPL+uVJz3orjp9lNmz3d06lBIoqTQad5MJgXsChVWxrlFVL71hSQIrwyiS uMXNxbbxOQIJ45d9cf55nyEy2dyWaTNh2LooRObF9BIgkyBP5wrplvNezH16tA60sasU 0vuOEiXocJZZvekAZMxCF3PUjcFJeNk4h/7PU= 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=Q4p8yTGHfiXikjl7w+qq6gihCxoUI1zqCay5cK8rxI4=; b=a1H31d1N9rJKBJnsx5rnWRypOAy+OELHg0GrQKQh9iL49/EClVvARaF77zHUJppGAq qwFkB+TZTLNDQsWyIbomNzx6w6r4E2mRIrPpRZQ36HSXMyEFco1E23i9QmqwvKXZjxDd j9BGY11Tcbya+UjFbnNXjvqWPqZsb+GsbtPNeOjeiGnrlfZSazbS7daWu2kxODF1Bv7W 7OlecCz3WmsExyGqIvBUKD2ZfWIW/2lcvy//xJIDH6iEY/p6dTs3ph2y8tUh0smMd1fd 0QmLQFUNApPg8BvVckQe1iP2f5WDrBNsIuR+NCrzEXvazf2LjOZ4IOVoizHr6WDF1A7F /qjQ== X-Gm-Message-State: APjAAAWcUfytCwjsRsjRNVu9xZ1Hihwn42+pPvX0zOe9+zS86fqnrIsi reexWAcBijHg2O9orNLHv/QY89Bimx+RdQVM98CRIQ== X-Google-Smtp-Source: APXvYqyB8L6XFtGbs3t51wXlKauqMBZjDLvatrgPaiJb2YKBaOTC96nnR6hQkCA4+FLn+Rhf4Lar0eNWAeJtwG9v4kg= X-Received: by 2002:a02:bb08:: with SMTP id y8mr84851029jan.51.1564631737464; Wed, 31 Jul 2019 20:55:37 -0700 (PDT) MIME-Version: 1.0 References: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com> In-Reply-To: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com> From: Ulysse Carion Date: Wed, 31 Jul 2019 20:55:26 -0700 Message-ID: To: Anders Rundgren Cc: "Manger, James" , JSON WG Content-Type: multipart/alternative; boundary="000000000000eaa078058f063679" Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 03:55:42 -0000 --000000000000eaa078058f063679 Content-Type: text/plain; charset="UTF-8" Replying to Anders and James at once: > The purpose of fixed sized integers in data formats is not to save bytes, it is about valid ranges and compatibility with languages like Java and C++. Agreed. The numerical types are about writing correct software more easily in modern programming languages, not about optimizing bytes. > Dropping int64 or BigInteger from *programming languages* is not an option. But dropping the ability for a JSON schema to suggest that arbitrary values of those types should be serialized to JSON numbers would be sensible. This is my view as well. > This is where we (as a community of users) have a problem. Jackson (now adopted by MSFT) indeed serializes BigInteger as JSON Number. Other parties like Oracle have taken another (presumable unique) approach by using JSON number for int53-compliant BigIntegers and string notation for BigIntegers that doesn't fits int53. I believe Oracle are considering a redesign though. It's precisely this sort of complication that motivates dropping numbers above int32/uint32 from the JSL spec. The spec remains useful without them. The same goes for monetary data types. There are too many options, and it's better for the spec to stick to relatively uncontroversial things. > Mind you, I suspect 1.23E8 will break many implementations that expect an integer so perhaps we should require the no-fraction-no-exponent form. This has been discussed in this thread before. Rough consensus suggests that it's better to simply require a zero fractional part in the number value, rather than impose constraints at the JSON parser level. On Wed, Jul 31, 2019 at 12:14 AM Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > On 2019-07-31 08:56, Manger, James wrote: > >> Dropping int64 is hardly an option, neither is BigInteger. int53 is a > special that for example fits UNIX "epoch". > > > > Dropping int64 or BigInteger from *programming languages* is not an > option. But dropping the ability for a JSON schema to suggest that > arbitrary values of those types should be serialized to JSON numbers would > be sensible. > > > >> Arbitrarily sized integers are used by tons of applications based on > JSON messaging and is available for most platforms including JS. > > > > Sure, but they are not serialized to a JSON number. They are serialized > to a JSON string of some form (eg "65537.00" or "AQAB"). > > This is where we (as a community of users) have a problem. Jackson (now > adopted by MSFT) indeed serializes BigInteger as JSON Number. Other > parties like Oracle have taken another (presumable unique) approach by > using JSON number for int53-compliant BigIntegers and string notation for > BigIntegers that doesn't fits int53. I believe Oracle are considering a > redesign though. > > The following lines in Chrome shows this division in clear: > > var big = 5n; > JSON.stringify(big) > > > VM887:1 Uncaught TypeError: Do not know how to serialize a BigInt > at Object.stringify () > at :1:6 > > Anders > > > > >> That there are multiple ways of formatting integers in JSON is > unfortunately a reality all JSON tool maker must (in some way) address. > > > > Are you referring to 123, 123.0, 12.3E+1 and 1.23e2 as the multiple > ways? Or 123, "123", "123.00", and "ew==" as the multiple ways? > > > >> I would reverse the integer syntax and claim that integers SHOULD > conform to standard integer (not JSON) syntax since a standard should not > break the multitude of JSON tools that already implement this. > > > > It sounds like you want JSON serializers to never use the fraction or > exponent notations when a schema says a field is an integer. That's adding > a distinction that doesn't exist in JSON so it will break things. A tool > parsing JSON *without knowing the schema* may well use a double for a > number, which it may then serialize in exponent notation even if it is an > integer. For instance, in Java Double.toString(123000000) returns "1.23E8". > > Mind you, I suspect 1.23E8 will break many implementations that expect > an integer so perhaps we should require the no-fraction-no-exponent form. > > > > This is a separate issue to this thread, however, which was whether a > JSON schema should offer "int53" as a type, and if it should offer > "{u}int{8|16|32}" as types. > > > > -- > > James Manger > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --000000000000eaa078058f063679 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Replying to Anders and James at once:
<= br>
>=20 The purpose of fixed sized integers in data formats is not to save=20 bytes, it is about valid ranges and compatibility with languages like=20 Java and C++.

Agreed. The numerical types are abou= t writing correct software more easily in modern programming languages, not= about optimizing bytes.

> Dropping int64 o= r BigInteger from *programming languages* is not an=20 option. But dropping the ability for a JSON schema to suggest that=20 arbitrary values of those types should be serialized to JSON numbers=20 would be sensible.

This is my view as well.
> This is where we (as a community of users) have a problem.= =C2=A0 Jackson (now adopted by MSFT) indeed serializes BigInteger as JSON Number.=C2=A0 Other= =20 parties like Oracle have taken another (presumable unique) approach by=20 using JSON number for int53-compliant BigIntegers and string notation=20 for BigIntegers that doesn't fits int53.=C2=A0 I believe Oracle are=20 considering a redesign though.

It's precisely = this sort of complication that motivates dropping numbers above int32/uint3= 2 from the JSL spec. The spec remains useful without them.

The same goes for monetary data types. There are too many options,= and it's better for the spec to stick to relatively uncontroversial th= ings.

> Mind you, I suspect 1.23E8 will break m= any implementations that expect=20 an integer so perhaps we should require the no-fraction-no-exponent=20 form.

This has been discussed in this thread befor= e. Rough consensus suggests that it's better to simply require a zero f= ractional part in the number value, rather than impose constraints at the J= SON parser level.

On Wed, Jul 31, 2019 at 12:14 AM Anders Rundgren <anders.rundgren.net@gmail.com> wrot= e:
On 2019-07-31= 08:56, Manger, James wrote:
>> Dropping int64 is hardly an option, neither is BigInteger.=C2=A0 = =C2=A0int53 is a special that for example fits UNIX "epoch".
>
> Dropping int64 or BigInteger from *programming languages* is not an op= tion. But dropping the ability for a JSON schema to suggest that arbitrary = values of those types should be serialized to JSON numbers would be sensibl= e.
>
>> Arbitrarily sized integers are used by tons of applications based = on JSON messaging and is available for most platforms including JS.
>
> Sure, but they are not serialized to a JSON number. They are serialize= d to a JSON string of some form (eg "65537.00" or "AQAB"= ;).

This is where we (as a community of users) have a problem.=C2=A0 Jackson (n= ow adopted by MSFT) indeed serializes BigInteger as JSON Number.=C2=A0 Othe= r parties like Oracle have taken another (presumable unique) approach by us= ing JSON number for int53-compliant BigIntegers and string notation for Big= Integers that doesn't fits int53.=C2=A0 I believe Oracle are considerin= g a redesign though.

The following lines in Chrome shows this division in clear:

var big =3D 5n;
JSON.stringify(big)

=C2=A0> VM887:1 Uncaught TypeError: Do not know how to serialize a BigIn= t
=C2=A0 =C2=A0 =C2=A0at Object.stringify (<anonymous>)
=C2=A0 =C2=A0 =C2=A0at <anonymous>:1:6

Anders

>
>> That there are multiple ways of formatting integers in JSON is unf= ortunately a reality all JSON tool maker must (in some way) address.
>
> Are you referring to 123, 123.0, 12.3E+1 and 1.23e2 as the multiple wa= ys? Or 123, "123", "123.00", and "ew=3D=3D" a= s the multiple ways?
>
>> I would reverse the integer syntax and claim that integers SHOULD = conform to standard integer (not JSON) syntax since a standard should not b= reak the multitude of JSON tools that already implement this.
>
> It sounds like you want JSON serializers to never use the fraction or = exponent notations when a schema says a field is an integer. That's add= ing a distinction that doesn't exist in JSON so it will break things. A= tool parsing JSON *without knowing the schema* may well use a double for a= number, which it may then serialize in exponent notation even if it is an = integer. For instance, in Java Double.toString(123000000) returns "1.2= 3E8".
> Mind you, I suspect 1.23E8 will break many implementations that expect= an integer so perhaps we should require the no-fraction-no-exponent form.<= br> >
> This is a separate issue to this thread, however, which was whether a = JSON schema should offer "int53" as a type, and if it should offe= r "{u}int{8|16|32}" as types.
>
> --
> James Manger
>

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--000000000000eaa078058f063679-- From nobody Wed Jul 31 22:11:46 2019 Return-Path: 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 B60F7120026 for ; Wed, 31 Jul 2019 22:11:44 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.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 rU-CI0dTWpTn for ; Wed, 31 Jul 2019 22:11:42 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 9F93512000F for ; Wed, 31 Jul 2019 22:11:41 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id s15so40533795wmj.3 for ; Wed, 31 Jul 2019 22:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Ah6QY63rkUFRj1fHrRh+Stko1hCnxAgHstI5EL3NrSg=; b=TPpflBjyHUtuXcla9Tr++ZCDfOWi15YrZmEKvKnooK91dZre0TAfQWw7C+9qaHJbci /2P6VD+HxPFZ4nFTyMqOjnbLG6xbBXWYujhpa6s9Z0j4a5obqm0GQprv5G8+PJOcG+1u eD6PKuGDxpr1pUMl4tIdLlkRzgWpGoEVyCkp51RHCUj0oZCCjcdmPeNqh8YdnE35JeIW cFYNyExmaUlp3UE3m38m2QaCE4SXDqFnNGo1HedrBrawj7W44UCKC4Sqbs+ZYWOJ11q0 Lei+6V0hNhNxLRS+VtU2wHSvzrhUvlW4svbWEhONWy8nEY9+5lNQvEcwBZqY+F/vX8Tz HEBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ah6QY63rkUFRj1fHrRh+Stko1hCnxAgHstI5EL3NrSg=; b=PygkevrPtXnOrdy8bJqZcJUHwtKKZS6JVAAHTkGP1sIwK7OPdvA2TQODLsOf+1WPTD 84vL/qrxq5W9MOn2zZtfTxFoloCRlPFy8+xErfZMoRl/WuGB8YUZKXxThKAwYMu4ZpHk DzhY3OYVyM1272TLioZLyGNdNqsWcuTwiMSeblC5ZNold6gg7mNz1k1T+Ox35GwvD7n3 n7lj6SZbWU6sUv9ZoESlaiHoll71ViEQROZdm8V96j0mFheAwUIz7ri/JGEITmkAw53F suUnhqaFTUx/MgBRUU85R4L2zemN3Iq2XjBlRuMI7bNgoHr7zzXkr4+Fr/BqEPb6JPpJ DYzA== X-Gm-Message-State: APjAAAW1qHbCJ2I9T9kOl7nX/fyJE9NWmxo9w6FCNInx4aJLlL9nAFOm bT2sEPH85DlNSx3swAFnfRcUdH75 X-Google-Smtp-Source: APXvYqwGdgvwH2ZQYAiodotWgADfQ5HKvB5A1Ilz3aBJ+gSPHlTmwAqFWALvVUBBYiBwDcIBTlFeDg== X-Received: by 2002:a1c:1bd7:: with SMTP id b206mr110291315wmb.85.1564636299313; Wed, 31 Jul 2019 22:11:39 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id r5sm74944287wmh.35.2019.07.31.22.11.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jul 2019 22:11:38 -0700 (PDT) To: Ulysse Carion Cc: "Manger, James" , JSON WG References: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com> From: Anders Rundgren Message-ID: <7004bfd3-ad9d-20c0-fd45-4d03049edbb9@gmail.com> Date: Thu, 1 Aug 2019 07:11:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 05:11:45 -0000 On 2019-08-01 05:55, Ulysse Carion wrote: > Replying to Anders and James at once: > > > The purpose of fixed sized integers in data formats is not to save bytes, it is about valid ranges and compatibility with languages like Java and C++. > > Agreed. The numerical types are about writing correct software more easily in modern programming languages, not about optimizing bytes. > > > Dropping int64 or BigInteger from *programming languages* is not an option. But dropping the ability for a JSON schema to suggest that arbitrary values of those types should be serialized to JSON numbers would be sensible. > > This is my view as well. I don't understand what exactly would be dropped here... > > > This is where we (as a community of users) have a problem.  Jackson (now adopted by MSFT) indeed serializes BigInteger as JSON Number.  Other parties like Oracle have taken another (presumable unique) approach by using JSON number for int53-compliant BigIntegers and string notation for BigIntegers that doesn't fits int53.  I believe Oracle are considering a redesign though. > > It's precisely this sort of complication that motivates dropping numbers above int32/uint32 from the JSL spec. The spec remains useful without them. > > The same goes for monetary data types. There are too many options, and it's better for the spec to stick to relatively uncontroversial things. I have only found two open standards using monetary types and they used the same notion. There is always a possibility creating a unique solution using JSON Number or JSON String. > > > Mind you, I suspect 1.23E8 will break many implementations that expect an integer so perhaps we should require the no-fraction-no-exponent form. > > This has been discussed in this thread before. Rough consensus suggests that it's better to simply require a zero fractional part in the number value, > rather than impose constraints at the JSON parser level. Right, JSL *seems* to presume that you build it on top of a standard JSON parser. By doing that you inherit platform specific quirks that do not have a natural place in a universal JSON schema processor. For documentation and code-gen purposes this idea should work just fine, but for run-time data validation it does not and that is the only case where the integer syntax issue would show up. AFAICT you cannot even do range checking in a reliable manner using "any" JSON parser. Chrome: JSON.parse('{"g":2e400}') > {g: Infinity} I don't think mathematicians in general consider 2e400 as infinity :) Before I became a JSON convert, I used XSD (XML Schema Definitions) extensively. XSD didn't have the limitations of JSL (with respect to numbers), although it was designed 20 years ago. Unfortunately numbers in JSON are more difficult than in XML since there are two entirely different ways to textually represent numbers. -- Anders > > On Wed, Jul 31, 2019 at 12:14 AM Anders Rundgren > wrote: > > On 2019-07-31 08:56, Manger, James wrote: > >> Dropping int64 is hardly an option, neither is BigInteger.   int53 is a special that for example fits UNIX "epoch". > > > > Dropping int64 or BigInteger from *programming languages* is not an option. But dropping the ability for a JSON schema to suggest that arbitrary values of those types should be serialized to JSON numbers would be sensible. > > > >> Arbitrarily sized integers are used by tons of applications based on JSON messaging and is available for most platforms including JS. > > > > Sure, but they are not serialized to a JSON number. They are serialized to a JSON string of some form (eg "65537.00" or "AQAB"). > > This is where we (as a community of users) have a problem.  Jackson (now adopted by MSFT) indeed serializes BigInteger as JSON Number.  Other parties like Oracle have taken another (presumable unique) approach by using JSON number for int53-compliant BigIntegers and string notation for BigIntegers that doesn't fits int53.  I believe Oracle are considering a redesign though. > > The following lines in Chrome shows this division in clear: > > var big = 5n; > JSON.stringify(big) > >  > VM887:1 Uncaught TypeError: Do not know how to serialize a BigInt >      at Object.stringify () >      at :1:6 > > Anders > > > > >> That there are multiple ways of formatting integers in JSON is unfortunately a reality all JSON tool maker must (in some way) address. > > > > Are you referring to 123, 123.0, 12.3E+1 and 1.23e2 as the multiple ways? Or 123, "123", "123.00", and "ew==" as the multiple ways? > > > >> I would reverse the integer syntax and claim that integers SHOULD conform to standard integer (not JSON) syntax since a standard should not break the multitude of JSON tools that already implement this. > > > > It sounds like you want JSON serializers to never use the fraction or exponent notations when a schema says a field is an integer. That's adding a distinction that doesn't exist in JSON so it will break things. A tool parsing JSON *without knowing the schema* may well use a double for a number, which it may then serialize in exponent notation even if it is an integer. For instance, in Java Double.toString(123000000) returns "1.23E8". > > Mind you, I suspect 1.23E8 will break many implementations that expect an integer so perhaps we should require the no-fraction-no-exponent form. > > > > This is a separate issue to this thread, however, which was whether a JSON schema should offer "int53" as a type, and if it should offer "{u}int{8|16|32}" as types. > > > > -- > > James Manger > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >