From nobody Fri May 3 16:59:27 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 6077C120133 for ; Fri, 3 May 2019 16:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 NHrR1J2u00kO for ; Fri, 3 May 2019 16:59:24 -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 52CF112010F for ; Fri, 3 May 2019 16:59:24 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id m7so4340881ioa.6 for ; Fri, 03 May 2019 16:59:24 -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=hpBANsPuGbU/MeGL14+mdh4ay7VoUFgea352tb/67MM=; b=BOumt5wFrnCbjWCw+crrtqU73OfYkdDdo3MutUGU0odr9/Agw/DYEZpLwGDikVmBYE /FCSlll+r2aGGFKPZTnVfix90tW/2WCxRcdi6LdPz6vHF16ONoeE9Uf2Ge1pBhEnXf8K 6NLkKINfAXyxS8k8NnoDvyBucDKTvXQaMgpkI= 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=hpBANsPuGbU/MeGL14+mdh4ay7VoUFgea352tb/67MM=; b=spdRKqqvL5+YHhJYKPQle5WwQZaL0vlMr61KElDt2FHFnrj45QOXVr1oBAXPuimvuQ IkzbHYPslA/rtf54vqHkSbkOaf2ZpfO4nH3vIa4kWrk6DZGztGMvb3ht3Ya2mOZNRpXd 89iwKVII0O3BTltuF7V0InzWhv7p4PnCHGH/VJ/cDTyeHLQ7amImMl2rmnAVNWy71bwB CUSwjlY/BenKUwiPvcvphIQy303ci7JMp8fA4dJhqS+FTRc04FNvm1F8EdVit75/+Zoz G3QqA/JICDkz+CrCTbksCoJLw98djuXFqQtKqNLLJf3dGSTtHMVEciE4Eutv1zF/GdUI TfPw== X-Gm-Message-State: APjAAAX8Y9csD98akSnBOl65W3OsN1WHng4Iis+J0+WY6gabQXsy2YJO DiwYF9Ry15PggkNZbNmRHf/PgNtTDy6x+Cu5QITxwU1HhrE= X-Google-Smtp-Source: APXvYqxVFsqi03OP4r4I2mzBFc5BoUSSEZ6zdsfI5eiM9DFe9dAr3GrN8Cr60q3xXfYe/z4G/aFxS3q0y7/T+6P5qDo= X-Received: by 2002:a5d:9b90:: with SMTP id r16mr8942895iom.217.1556927963178; Fri, 03 May 2019 16:59:23 -0700 (PDT) MIME-Version: 1.0 From: Ulysse Carion Date: Fri, 3 May 2019 16:59:12 -0700 Message-ID: To: json@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 23:59:26 -0000 Hello all, I have recently published an I-D for what I'm calling JSON Schema Language, a way to validate JSON data's shape, and generate code (i.e., types, classes, docs, etc.) from that shape: https://tools.ietf.org/html/draft-json-schema-language-00 In previous correspondence with this list, Carsten Bormann has noted that this WG has hesitated to prematurely adopt any given proposal, preferring to let them develop until their distinct applications become clear. It is my belief that JSON Schema Language does have a clear use-case, one which Tim Bray has articulated clearly here: https://www.tbray.org/ongoing/When/201x/2018/09/22/JSON-scheming I believe JSON Schema Language solves precisely what Tim describes, while eschewing his concerns with the json-schema.org project. For those inclined toward the concrete, the bottom of this page contains a live demo of JSON Schema Language using the TypeScript implementation: https://json-schema-language.github.io/ The project's GitHub organization also contains the source for a Rust and TypeScript implementation, as well as a full test suite: https://github.com/json-schema-language With Carsten's note in mind, does there nevertheless exist a path for JSON Schema Language, or something like it, to become an RFC? I appreciate the desire to avoid premature adoption by this WG. I assume this partially stems from caution around throwing the weight of json@ietf.org behind any given specification. Perhaps some other path to specification exists? With kind regards, Ulysse Carion From nobody Fri May 3 21:47: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 0BF0A1203A4 for ; Fri, 3 May 2019 21:47:44 -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_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 pQxR-07mC5K3 for ; Fri, 3 May 2019 21:47:41 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 668A01203A2 for ; Fri, 3 May 2019 21:47:41 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id q10so1525943wrj.10 for ; Fri, 03 May 2019 21:47:41 -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=vIqhvWi1znJ9NPg/y2aurhIOZIx0mOZ6JPn8PpONVOE=; b=rUuFJsPZo+WX8/mZi2/OY0wv5ehhMJB7EiT0Y39PIQVYz9D6x4J4sVs2iCLe+a4ABf FnaaqHQi9nLdaOFkS8CcrC1vaSrvWr1s6mnV+duDpbrzcL67v5q9wlKNU0BpvCB64yyK sLPabapcQ2ug/63IpSZci+rsXX3nZQPkA7YycWbdbNPOv/pzQd/5ztNVZhIiavcUtJkc fJitrz/xSjuoppfFDe9UZp4EWIUIMpFnRJ69P1CcebF5jWtuymz1XIVBZk6MOyQWQZdq fD4hEsXUV08L/fo0r+NtYaywYxI9uDstdF4Vq0a3YCPvqs6GU/dIVZuW+ULUNMRVuhJk gXWA== 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=vIqhvWi1znJ9NPg/y2aurhIOZIx0mOZ6JPn8PpONVOE=; b=HP6KDnT7UVD47/3vi16YpchlI5DzzxZqo1t4X/E6WTOeoNAFn2Kxu6aNMm9p2pQU7c crhz/VATTjEHTnqJY9P1QUIG0d70P7xNNJ4WK4uvgKIjzkAKQFjvaQWJVUv7CurVqX8q zXTcj+9MttP9nTY1oiXIaP82fF5dfkfoIfKcPQlQkwNCWH/KoasP3W6nPZMeiPy7q0i1 Exi2WXLWRTFoeQvsFXIWm2HlcwnlVXM66+UHxanB9MPhC4zDjgDZoF7nS/mY62BeAbqb F5Tt6shp9Qxy7RJkSSiQeNgg2bV4eoNPgm+5Y4Z2UxZes36Tu4FqV+SPEPfD63NBtOct vFjQ== X-Gm-Message-State: APjAAAUveg/jKcJmJh57bA7umtYcKc2gJnNDH4u8YWQEEvXYG7+xKJML ij3MInnfOjhE++PKOzXOMTG4K+VcSx4= X-Google-Smtp-Source: APXvYqwCSObuG7C9Oi3KVStdt0MGyT6U5CkGw8nZOeq44PEVyUn/vMuuXwumEsM2QgxuNwXgYR9fhg== X-Received: by 2002:a5d:4dc1:: with SMTP id f1mr9819681wru.300.1556945259518; Fri, 03 May 2019 21:47: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 l127sm4587045wml.40.2019.05.03.21.47.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 May 2019 21:47:38 -0700 (PDT) To: Ulysse Carion , json@ietf.org References: From: Anders Rundgren Message-ID: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> Date: Sat, 4 May 2019 06:47:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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 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, 04 May 2019 04:47:44 -0000 On 2019-05-04 01:59, Ulysse Carion wrote: > Hello all, Hello Ulysse, I'm a former user of XML Schema. I was therefore looking for similarities like data types and facets but didn't find them. Example: although 10.0 is a valid JSON Number, in system where you expect an integer, this should be flagged as a syntax error. thanx, Anders > > I have recently published an I-D for what I'm calling JSON Schema > Language, a way to validate JSON data's shape, and generate code > (i.e., types, classes, docs, etc.) from that shape: > > https://tools.ietf.org/html/draft-json-schema-language-00 > > In previous correspondence with this list, Carsten Bormann has noted > that this WG has hesitated to prematurely adopt any given proposal, > preferring to let them develop until their distinct applications > become clear. > > It is my belief that JSON Schema Language does have a clear use-case, > one which Tim Bray has articulated clearly here: > > https://www.tbray.org/ongoing/When/201x/2018/09/22/JSON-scheming > > I believe JSON Schema Language solves precisely what Tim describes, > while eschewing his concerns with the json-schema.org project. > > For those inclined toward the concrete, the bottom of this page > contains a live demo of JSON Schema Language using the TypeScript > implementation: > > https://json-schema-language.github.io/ > > The project's GitHub organization also contains the source for a Rust > and TypeScript implementation, as well as a full test suite: > > https://github.com/json-schema-language > > With Carsten's note in mind, does there nevertheless exist a path for > JSON Schema Language, or something like it, to become an RFC? I > appreciate the desire to avoid premature adoption by this WG. I assume > this partially stems from caution around throwing the weight of > json@ietf.org behind any given specification. Perhaps some other path > to specification exists? > > With kind regards, > Ulysse Carion > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Sat May 4 00:58:40 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 1FBF912004C for ; Sat, 4 May 2019 00:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 HdKentULcg_J for ; Sat, 4 May 2019 00:58:36 -0700 (PDT) Received: from smtp.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 F2B56120019 for ; Sat, 4 May 2019 00:58:35 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44x1bD5F7QzyV4; Sat, 4 May 2019 09:58:32 +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: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> Date: Sat, 4 May 2019 09:58:32 +0200 Cc: Ulysse Carion , json@ietf.org X-Mao-Original-Outgoing-Id: 578649510.37251-2ebd5673e8c1504cdc54fe4254fcd83c Content-Transfer-Encoding: quoted-printable Message-Id: <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> To: Anders Rundgren X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2019 07:58:38 -0000 On May 4, 2019, at 06:47, Anders Rundgren = wrote: >=20 > Example: although 10.0 is a valid JSON Number, in system where you = expect > an integer, this should be flagged as a syntax error. 10.0 is an integer number. =E2=80=9CSchema Languages=E2=80=9D operate at the data model level. In = the JSON data model, there is only one kind of number. =20 Of course, the JSON data model is not actually defined in a standard, = which is one of the major shortcomings of JSON. See appendix E of draft-ietf-cbor-cddl-08.txt for the way that is = handled in CDDL. In an alternate JSON universe(*), you would start by applying ISO 6093 = (ECMA-63 [1]). NR1 becomes an integer, NR2 and NR3 become floating point values. =20 You then still have to decide what the JSON constructions not covered by = ISO 6093 become, e.g., what 1e5 is; in C that would be a float while in = Ada that is an integer, IIRC. If you define that int/float distinction properly, and make it available = at the data model level, you can have the =E2=80=9Cschema language=E2=80=9D= act on that. Gr=C3=BC=C3=9Fe, Carsten (*) which is indeed well-supported by implementations outside = JavaScript, just not by specifications. [1] = https://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/EC= MA-63,%201st%20Edition,%20September%201980.pdf From nobody Sat May 4 02:37:13 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 91EFE120269 for ; Sat, 4 May 2019 02:37:11 -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_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=bzfx.net 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 z1ZznJgXDuCV for ; Sat, 4 May 2019 02:37:09 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 2223A120273 for ; Sat, 4 May 2019 02:37:08 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id 10so4152805pfo.5 for ; Sat, 04 May 2019 02:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HXcD7goiW5AqXVKrZ/fB141MMjjcSgitGR5Xvdqu5l4=; b=E419CFMgJOjdcGieh3Miq2k+l6g5QIArdzN4RhwsTIq6igAyHeyPjFRP0Ulyjg8toV mMo/CwsA9Tl8GF6B835F0zVRibyYStBGQsLBus9m4ZREecTGE8r53Rx8S/OpJyxsnpIs oMeYyvoOa1IztGrJm4EWB9x6qVtg+nSDf4ycI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HXcD7goiW5AqXVKrZ/fB141MMjjcSgitGR5Xvdqu5l4=; b=mz2uSA9v5f1q/hpv8aTb6lM7U6CTmF2llVgMWV/esAbIr1mZKKEZ6HeFm7iliFp9ms MP/CoJwCWVqoF9Kvi5GmhP7X8lOJsgXmL5+ka/cP/gXxBNjKxNLRkp5Xdq3ML8RTaAok MO5ph/3OtGV4KI3EJU2iF5+F/w2VLoMtPKVXToPNmqyf+mDqw2JFW9NPjwmHHLvfrgLF JTbYOj+/dn2o2zJ2MuGs77Gr/lm4zHDuLl3AsmqAHXp0MFdvAt+c6lnafAAWInh+diwy 7GWcdpmy3+1xcLfq3tJ4ONFymwtltO7Olf8i1a4Qja2YEBPWqltOzxw9i67OED/xl1cl d6VQ== X-Gm-Message-State: APjAAAU7HupRSbYskKWSZN96dro5VgK9ydzWhg/Wedz+n5qLHxq7IUXZ OTtQXXv3npfdMMRLe2OTUoYhzg== X-Google-Smtp-Source: APXvYqyEHQBPchF31ge/ESNQmuaVEfhQFq6QTtukFdluRRw/H1SDg+fKtT1YtU3BxmXbZwwcmgjcpA== X-Received: by 2002:aa7:80c6:: with SMTP id a6mr18239553pfn.114.1556962628451; Sat, 04 May 2019 02:37:08 -0700 (PDT) Received: from [192.168.0.116] ([184.101.46.90]) by smtp.gmail.com with ESMTPSA id y8sm4833332pgk.20.2019.05.04.02.37.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 May 2019 02:37:07 -0700 (PDT) From: Austin Wright Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8E5086D1-4A7F-4D22-B597-F0E23FEF6449" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Sat, 4 May 2019 02:36:46 -0700 In-Reply-To: <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> Cc: Anders Rundgren , json@ietf.org, Ulysse Carion To: Carsten Bormann References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2019 09:37:12 -0000 --Apple-Mail=_8E5086D1-4A7F-4D22-B597-F0E23FEF6449 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 4, 2019, at 00:58, Carsten Bormann wrote: >=20 > On May 4, 2019, at 06:47, Anders Rundgren = wrote: >>=20 >> Example: although 10.0 is a valid JSON Number, in system where you = expect >> an integer, this should be flagged as a syntax error. >=20 > 10.0 is an integer number. >=20 > =E2=80=9CSchema Languages=E2=80=9D operate at the data model level. = In the JSON data model, there is only one kind of number. =20 > Of course, the JSON data model is not actually defined in a standard, = which is one of the major shortcomings of JSON. >=20 JSON Schema handles this exactly the same way, defining a data model = [1]. The lexical representation is surjective onto the data model: as = you point out, 10.0 is the same as 10, which is an integer. The one case where this might fall apart is if significant digits are = important, such that 10.0 is different than 10.00 (i.e., 10.00 is more = precise by an order of magnitude). However, I=E2=80=99m not aware of any = JSON parsers that keep track of the precision of numbers, even ones that = support arbitrary precision. I imagine scientific applications would = want to store an explicit precision, since they=E2=80=99re not always = powers-of-10 (e.g. {value: 32.0, precision: 0.5}). [1] = http://json-schema.org/latest/json-schema-core.html#rfc.section.4.2.1 = = "4.2.1. Instance Data Model" Austin.= --Apple-Mail=_8E5086D1-4A7F-4D22-B597-F0E23FEF6449 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 4, 2019, at 00:58, Carsten Bormann <cabo@tzi.org> = wrote:

On May 4, 2019, at 06:47, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

Example: = although 10.0 is a valid JSON Number, in system where you expect
an integer, this should be flagged as a syntax error.

10.0 is an integer number.

=E2=80=9CSchema Languages=E2=80=9D operate at = the data model level.  In the JSON data model, there is only one = kind of number.  
Of course, the JSON data model is = not actually defined in a standard, which is one of the major = shortcomings of JSON.


JSON = Schema handles this exactly the same way, defining a data model [1]. The = lexical representation is surjective onto the data model: as you point = out, 10.0 is the same as 10, which is an integer.

The one case where this might fall apart is if = significant digits are important, such that 10.0 is different than 10.00 = (i.e., 10.00 is more precise by an order of magnitude). However, I=E2=80=99= m not aware of any JSON parsers that keep track of the precision of = numbers, even ones that support arbitrary precision. I imagine = scientific applications would want to store an explicit precision, since = they=E2=80=99re not always powers-of-10 (e.g. {value: 32.0, precision: = 0.5}).

[1] http://json-schema.org/latest/json-schema-core.html#rfc.section= .4.2.1 "4.2.1. Instance Data Model"
Austin.
= --Apple-Mail=_8E5086D1-4A7F-4D22-B597-F0E23FEF6449-- From nobody Sat May 4 02:42:34 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 0825B120273 for ; Sat, 4 May 2019 02:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TMVRwBhD1DNG for ; Sat, 4 May 2019 02:42:31 -0700 (PDT) Received: from smtp.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 F3CC3120279 for ; Sat, 4 May 2019 02:42:30 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44x3v907q1zyZ4; Sat, 4 May 2019 11:42:28 +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: Sat, 4 May 2019 11:42:28 +0200 Cc: Anders Rundgren , json@ietf.org, Ulysse Carion X-Mao-Original-Outgoing-Id: 578655745.34218-e5ed096af226d277a7d768899027ac67 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> To: Austin Wright X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2019 09:42:33 -0000 Curious: On that web page, it also says =E2=80=9CFor consistency, integer JSON = numbers SHOULD NOT be encoded with a fractional part.=E2=80=9D What does that mean? Gr=C3=BC=C3=9Fe, Carsten > On May 4, 2019, at 11:36, Austin Wright wrote: >=20 >=20 >=20 >> On May 4, 2019, at 00:58, Carsten Bormann wrote: >>=20 >> On May 4, 2019, at 06:47, Anders Rundgren = wrote: >>>=20 >>> Example: although 10.0 is a valid JSON Number, in system where you = expect >>> an integer, this should be flagged as a syntax error. >>=20 >> 10.0 is an integer number. >>=20 >> =E2=80=9CSchema Languages=E2=80=9D operate at the data model level. = In the JSON data model, there is only one kind of number. =20 >> Of course, the JSON data model is not actually defined in a standard, = which is one of the major shortcomings of JSON. >>=20 >=20 > JSON Schema handles this exactly the same way, defining a data model = [1]. The lexical representation is surjective onto the data model: as = you point out, 10.0 is the same as 10, which is an integer. >=20 > The one case where this might fall apart is if significant digits are = important, such that 10.0 is different than 10.00 (i.e., 10.00 is more = precise by an order of magnitude). However, I=E2=80=99m not aware of any = JSON parsers that keep track of the precision of numbers, even ones that = support arbitrary precision. I imagine scientific applications would = want to store an explicit precision, since they=E2=80=99re not always = powers-of-10 (e.g. {value: 32.0, precision: 0.5}). >=20 > [1] = http://json-schema.org/latest/json-schema-core.html#rfc.section.4.2.1 = "4.2.1. Instance Data Model" >=20 > Austin. From nobody Sat May 4 04: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 B8D341200B1 for ; Sat, 4 May 2019 04:44:13 -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, 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 2teBz_vAq-VJ for ; Sat, 4 May 2019 04:44:12 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 B766C120044 for ; Sat, 4 May 2019 04:44:11 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id h15so5368484wrb.2 for ; Sat, 04 May 2019 04:44:11 -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=wXO+ZtLDJP8xdrpsJHnUH3dG4Toa6h/bXte5vNhHYK0=; b=u/CCux+RemH6DYd+x6ACuIMiv4gKw4lnmhbI5arZMfOhi6zZNwJkG88d9BvIaMshbv D/J7VIlRZ4KR4uPZdVNp6vE+e9aekbJ5KNc5JL9hSiGHlF5XcczAUiTq1TNzC+N1HUfr mrnKD3rUFK9h52TWDXbGR6itEG9GZxHgApHhq2e8n5RuhUQvJ0RlDIVvvb9Uvtvc5v7q QsPAb/A6mJa3yqAqbTzhh2VJRxb+I1fFYDR9qkFVcOqDEmQKBLngrPxTrKZBL2RI4AAz oqo86/qsoEqaaNzVhkOaJLf+wTCTPBR0HJLB3eBdOdPBux2RxCl0EcWgIsVss3j+UXD5 BYtw== 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=wXO+ZtLDJP8xdrpsJHnUH3dG4Toa6h/bXte5vNhHYK0=; b=OxZZukohwOU5XnZLfXcO6jd4rCrzrDQbZPxScNGj8gsdh0lRMAEDqCC7Qs/LCtnynA r0cm49oCW8LIAWQQeZOhp4+BIyuoHjR3ejmNfNNCQysVn0cohz7NIlqAPATGA2EjEF3H ZPlMiMc7iL/G0H39jS09R96+NF6jl93228BSMJvtsLivSknGAmN+F+3xOONJGg9952fV dQIsp3rw6pC0Q/bin6SRJRIQVg4QgBdZ1KL9mt5ikQ27HhmMSFAeOV04s7tWgxUaJURg 22AfUwLboD3IHHAK3nZz7ZO9jswdWDatU7tk96/betzBN6tnvvsmGBuTovbFKt+hZCBr nwvQ== X-Gm-Message-State: APjAAAVM6UKvD1kupMBrFeXlWpRNfO3vKYHtNDVHb0oKB/27oAYsRzo0 EDRN2ZTSTXgIxLQknoMr6O1tM8LqxIg= X-Google-Smtp-Source: APXvYqwnpDuRBodPKBfjkf2QrDzh30OVDrV6yZq0oMd6O8Zp3KVACec/Vky7/H+rBiHX+ihhzx6PUQ== X-Received: by 2002:adf:83a7:: with SMTP id 36mr10496845wre.310.1556970250166; Sat, 04 May 2019 04:44:10 -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 a20sm9168966wrf.37.2019.05.04.04.44.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 May 2019 04:44:09 -0700 (PDT) To: Carsten Bormann , Austin Wright Cc: json@ietf.org, Ulysse Carion References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> From: Anders Rundgren Message-ID: Date: Sat, 4 May 2019 13:44:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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 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, 04 May 2019 11:44:14 -0000 Test run with a popular JSON Parser nowadays adopted by Microsoft as well: Newtonsoft.Json.JsonReaderException: 'Input string '7800000.0' is not a valid integer. Path 'counter', line 1, position 39.' However, in addition to supporting common data types, there should (IMO) also be a way to specify JSON serialization format. One camp headed by the Open API folks maintain that incompatibility with JavaScript is of uttermost importance and therefore mandate that "long" integers should be serialized as JSON Numbers. Another, and (if may say it) slightly more practical bunch of people, rather put "long" integers within quotes and thus maintain interoperability with essentially every platform. To make things yet a bit more fuzzy there exists at least 4 different takes on the latter: Decimal, Hexadecimal, Base64, and Base64Url. thanx, Anders From nobody Sat May 4 19:51:58 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 B1F8912034C for ; Sat, 4 May 2019 19:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net 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 H2vJqFuC1ED7 for ; Sat, 4 May 2019 19:51:53 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 8CD26120337 for ; Sat, 4 May 2019 19:51:53 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id e6so4693160pgc.4 for ; Sat, 04 May 2019 19:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gQNV4mlMqVKduXdXzpluCIS3jhpyZ4kkAYe/njDoWnI=; b=fJ8eBL92NqlN1PNxdevNtsMy3V0velcg0bxMwsZuf9FpflFvwurRxQ67tnztt5l2+H TgY3ujU+HEc/TNHPMIS93Qhl5BniBBNYyfYktVLUSfsgmr8KWX2bGCdXP6x5aQMXVnuu 0qxtJkT++rx+5bh/2hWzcsNw5W5dNOYKZNlKk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gQNV4mlMqVKduXdXzpluCIS3jhpyZ4kkAYe/njDoWnI=; b=OettjrAYBQojaXMu3oHh5HuvDW4dKIri5aWIqiXzJPaJ+BSRKUdgODG2XuAHFXAGT0 YwNQLys/YNtDCkrMUpZs3V2qI5HEq8I0HE0z4i6C2I/KpL82AQvbbYX6m6/vRNf5BuSW 7peg3eFV2ljMV1OnluM3O/tIJecNw/Z7qKoaT1r534RlGXJiL1pui2CzxMhfKza1DhK7 x1fif3JFmaK62Tw6WJ7uB/Ap1AKegUJNLqoGYe/HjQaWPcubtcaxsbyJTA44ayvMh2K0 2phLCqeBDf/qfjABjKa3ItRrXz2vDFDkvi/tt1Gu6XbBVcp7p7lB0t+DJPlL8EwHHVkY Bz8A== X-Gm-Message-State: APjAAAWDis2KJFWKTY7BKfYs7Ts5EumQp2LXMX8mawx7Dbor9N2nhDpD HRmPkDeJKTNl7ThIV6NK+nr1KA== X-Google-Smtp-Source: APXvYqwMZJOsSgEvMUhslxhIBDgqeCohtJuzMuoA8YX5mwFcGmGdMnG8bJ8Qp4mThExQ4XuBQYxrhg== X-Received: by 2002:a63:5947:: with SMTP id j7mr22488700pgm.62.1557024712853; Sat, 04 May 2019 19:51:52 -0700 (PDT) Received: from [192.168.0.13] ([184.101.46.90]) by smtp.gmail.com with ESMTPSA id d3sm7965146pfn.113.2019.05.04.19.51.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 May 2019 19:51:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Austin Wright In-Reply-To: Date: Sat, 4 May 2019 19:51:50 -0700 Cc: Anders Rundgren , json@ietf.org, Ulysse Carion Content-Transfer-Encoding: quoted-printable Message-Id: References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 02:51:57 -0000 > On May 4, 2019, at 02:42, Carsten Bormann wrote: >=20 > Curious: >=20 > On that web page, it also says =E2=80=9CFor consistency, integer JSON = numbers SHOULD NOT be encoded with a fractional part.=E2=80=9D >=20 > What does that mean? It=E2=80=99s a non-normative suggestion with the aim of enhancing = performance: Many programming languages distinguish between integers and = IEEE floats by the presence of a decimal point. While JSON makes no such = distinction (all numbers are arbitrary precision decimal), some parsers = do make that distinction, and it=E2=80=99s slightly easier to determine = if an int32_t is an integer than if a double is an integer. Cheers, Austin. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On May 4, 2019, at 11:36, Austin Wright wrote: >>=20 >>=20 >>=20 >>> On May 4, 2019, at 00:58, Carsten Bormann wrote: >>>=20 >>> On May 4, 2019, at 06:47, Anders Rundgren = wrote: >>>>=20 >>>> Example: although 10.0 is a valid JSON Number, in system where you = expect >>>> an integer, this should be flagged as a syntax error. >>>=20 >>> 10.0 is an integer number. >>>=20 >>> =E2=80=9CSchema Languages=E2=80=9D operate at the data model level. = In the JSON data model, there is only one kind of number. =20 >>> Of course, the JSON data model is not actually defined in a = standard, which is one of the major shortcomings of JSON. >>>=20 >>=20 >> JSON Schema handles this exactly the same way, defining a data model = [1]. The lexical representation is surjective onto the data model: as = you point out, 10.0 is the same as 10, which is an integer. >>=20 >> The one case where this might fall apart is if significant digits are = important, such that 10.0 is different than 10.00 (i.e., 10.00 is more = precise by an order of magnitude). However, I=E2=80=99m not aware of any = JSON parsers that keep track of the precision of numbers, even ones that = support arbitrary precision. I imagine scientific applications would = want to store an explicit precision, since they=E2=80=99re not always = powers-of-10 (e.g. {value: 32.0, precision: 0.5}). >>=20 >> [1] = http://json-schema.org/latest/json-schema-core.html#rfc.section.4.2.1 = "4.2.1. Instance Data Model" >>=20 >> Austin. >=20 From nobody Sat May 4 22:07:38 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 5E4E5120195 for ; Sat, 4 May 2019 22:07:36 -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, 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 Af6PTqkDv8fU for ; Sat, 4 May 2019 22:07:34 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 4B02512012B for ; Sat, 4 May 2019 22:07:34 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id a12so2742821wrn.4 for ; Sat, 04 May 2019 22:07:34 -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=KpeMQdK29ZWJn4LHQcYioDKfpam/r/Q3TDkqQTshKSU=; b=tcgXDmBgXFXu8fo3qwKay9m4TJnAyUx7AMOhj8VVWc/6F24XJEQ5RrngQSVO+fYKZh 5BfsXFAUCCtntnwJIrqgnhg7/0qrixaSE6V6D2zW+JF4a+cT5q7+VxuhNhqOS0y1PDY4 VNuR3dSgmMHYzZArVwM4bFrw9MlKLWpazu9GDEOZi9pd5BDueKIC7TmDjpoTeRdTqrxy /ZADPsoRzwBpserZAhHZrbUMhmppwerdIiyHjNeiKJdCLdsZnJwgs+Ewrhh2k42LsxIW jpwO9DEem76tCTYGp4+iMSbD+BZZefPn0bsuEEzqk+SQtf8WkUTLu+/uqw/LjQOeiuS9 Zoow== 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=KpeMQdK29ZWJn4LHQcYioDKfpam/r/Q3TDkqQTshKSU=; b=efO6jlfpNzwBo773NhtR/ePvKS4Fs2O3dLGhHZu5JEMMFoTe9MuI+9omwqpGF5uw+4 zThX46Ulxa6iRir2zlPHxffDBeqTxJZLL9tGcsJ2RmqyZ6df5av2AjX1UljwfHzm517P n0c30cBDe0NnEk/RcQL093cDXquw25XxJvv+oAzQ9KZAkaFdGkR8Z+0WdBdX3Zz1zhku Sg0WOmdA5cDHpk6erq3293ogfQY7ZZNrLNIDWlUHBFjpa55I6vkQKAfqWuJL+oLBn3t/ ClqfWlueGMmdRCM/pIhpnZ8emWerZ4eVVd+5RBQrYATo0sGEOSlz+CCuR8pzKkzM7wH4 SKNw== X-Gm-Message-State: APjAAAVjxxzu4n2VA9GQCEpJvRouj4Pm7N7UiWY9R0MaoGeOe6wquGgJ +qCHOvnOtvoj3oKTf5jR3vM0pykwuFU= X-Google-Smtp-Source: APXvYqzDis9sBXkqlzZxyt2RVHB0ysZRSn7Ny7DX7kmuVbFD8BlR/WwQTx6xAEjqcqxvT+j4w2iLug== X-Received: by 2002:adf:c748:: with SMTP id b8mr13085975wrh.292.1557032852779; Sat, 04 May 2019 22:07:32 -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 j13sm20392147wrd.88.2019.05.04.22.07.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 May 2019 22:07:30 -0700 (PDT) To: Austin Wright , Carsten Bormann Cc: json@ietf.org, Ulysse Carion References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> From: Anders Rundgren Message-ID: <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> Date: Sun, 5 May 2019 07:07:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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 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: Sun, 05 May 2019 05:07:36 -0000 On 2019-05-05 04:51, Austin Wright wrote: > > >> On May 4, 2019, at 02:42, Carsten Bormann wrote: >> >> Curious: >> >> On that web page, it also says “For consistency, integer JSON numbers SHOULD NOT be encoded with a fractional part.” >> >> What does that mean? > > It’s a non-normative suggestion with the aim of enhancing performance: Many programming languages distinguish between integers and IEEE floats by the presence of a decimal point. While JSON makes no such distinction (all numbers are arbitrary precision decimal), some parsers do make that distinction, and it’s slightly easier to determine if an int32_t is an integer than if a double is an integer. in the C# example I provided before this is (by default) not non-normative, since it threw an exception. Here is a little bit more detail: class MyObject { int Counter; . . } Deserializing JSON into this type (which BTW works as as "schema"), REQUIRES "Counter" data to adhere to normal integer notation, including value span. A scheme language should align with the actual use and interpretation of JSON. This involves alternative serialization formats as well. As an example monetary values are (probably without exceptions) expressed as JSON Strings since floating point is unsuited for decimal arithmetic. Based on the RFC, one might come to the conclusion that JSON is an inferior information transfer format, but aided by external mapping it actually works extremely well, albeit being slightly verbose :) Cheers, Anders > > Cheers, > > Austin. > >> >> Grüße, Carsten >> >> >>> On May 4, 2019, at 11:36, Austin Wright wrote: >>> >>> >>> >>>> On May 4, 2019, at 00:58, Carsten Bormann wrote: >>>> >>>> On May 4, 2019, at 06:47, Anders Rundgren wrote: >>>>> >>>>> Example: although 10.0 is a valid JSON Number, in system where you expect >>>>> an integer, this should be flagged as a syntax error. >>>> >>>> 10.0 is an integer number. >>>> >>>> “Schema Languages” operate at the data model level. In the JSON data model, there is only one kind of number. >>>> Of course, the JSON data model is not actually defined in a standard, which is one of the major shortcomings of JSON. >>>> >>> >>> JSON Schema handles this exactly the same way, defining a data model [1]. The lexical representation is surjective onto the data model: as you point out, 10.0 is the same as 10, which is an integer. >>> >>> The one case where this might fall apart is if significant digits are important, such that 10.0 is different than 10.00 (i.e., 10.00 is more precise by an order of magnitude). However, I’m not aware of any JSON parsers that keep track of the precision of numbers, even ones that support arbitrary precision. I imagine scientific applications would want to store an explicit precision, since they’re not always powers-of-10 (e.g. {value: 32.0, precision: 0.5}). >>> >>> [1] http://json-schema.org/latest/json-schema-core.html#rfc.section.4.2.1 "4.2.1. Instance Data Model" >>> >>> Austin. >> > From nobody Sat May 4 22:39:32 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 4F3CC12010C for ; Sat, 4 May 2019 22:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 R_VuEL6h7Gai for ; Sat, 4 May 2019 22:39:28 -0700 (PDT) Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) (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 3DEDE120105 for ; Sat, 4 May 2019 22:39:28 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8F8BB125050; Sun, 5 May 2019 05:39:26 +0000 (UTC) Received: from pdx1-sub0-mail-a48.g.dreamhost.com (unknown [100.96.20.60]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 442A8125235; Sun, 5 May 2019 05:39:26 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a48.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Sun, 05 May 2019 05:39:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Lettuce-Duck: 32f24d1a1b1a9d9a_1557034766394_3440012957 X-MC-Loop-Signature: 1557034766394:142655206 X-MC-Ingress-Time: 1557034766393 Received: from pdx1-sub0-mail-a48.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a48.g.dreamhost.com (Postfix) with ESMTP id EB92581ED4; Sat, 4 May 2019 22:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=RjouRevR6yKOO6 Pe70YzwDdkN34=; b=f7Vi4IOb8n8VXfmvN/Kkul+R/d+v1mGjBeNGYZmRep4mOW 3UIAGgeNtK4XrzcYGAk4meLv6H2Potjx8pLI0rpOqyuZZmy2ThWeSQohpzHn58q2 veOJ9xEQhDIjayS4drMy6aAhqT/2cUIt/uI/N13EcVYc19/JErs5/1PDRU84o= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a48.g.dreamhost.com (Postfix) with ESMTPSA id CCAC382ACF; Sat, 4 May 2019 22:39:24 -0700 (PDT) Date: Sun, 5 May 2019 00:39:22 -0500 X-DH-BACKEND: pdx1-sub0-mail-a48 From: Nico Williams To: Anders Rundgren Cc: Ulysse Carion , json@ietf.org Message-ID: <20190505053921.GA21049@localhost> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrjeeggdelkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 05:39:30 -0000 On Sat, May 04, 2019 at 06:47:35AM +0200, Anders Rundgren wrote: > On 2019-05-04 01:59, Ulysse Carion wrote: > > Hello all, > > Hello Ulysse, > > I'm a former user of XML Schema. I was therefore looking for similarities > like data types and facets but didn't find them. > > Example: although 10.0 is a valid JSON Number, in system where you expect > an integer, this should be flagged as a syntax error. As a maintainer of one popular implementation, this idea that having a zero fractional part makes a number non-integer annoys me a great deal. I would insist that any parser that distinguishes real and integer representations should parse numeric values with a zero fractional part (and non-negative exponent) as integers. 10.0 is an integer, even if a parser only supports, e.g., IEEE754 representations of numeric values. Nico -- From nobody Sat May 4 22:52:28 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 AEAB2120197 for ; Sat, 4 May 2019 22:52:26 -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, 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 1DLeiSvBYUJZ for ; Sat, 4 May 2019 22:52:25 -0700 (PDT) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 EBFD912012E for ; Sat, 4 May 2019 22:52:24 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id b10so11797804wmj.4 for ; Sat, 04 May 2019 22:52:24 -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=hP647i9f/T8cIOBAP6mlnLrhJMUWoCrFQQsy4ra0mcM=; b=EHcXWA/vhW7ehm/ehqT8xepdyFc1s/gQK0bhydEZRS06NmXhkXIlJBjrR5B0s+7H9q 8dpoSlxpdVs4egxCdRoP4k568f29ar5TfqdBgjwcHNveYDQBp5GsOYql1xUBCFM6NF9w RIFuDBkRPIqxRjLBf2y6ohtIIRaHR9Z0sy6J5eA4I4lk/4+F40aOwCVWBe7ETlmO8YtB 6xw2KzeAVnGUwZK0bu1koc54RHSfOVf5RRrdCKy1BfpRZrIwf/zJ70OO2VcYLXJhbckU NFdbzXPpnH6wyT8o0XmKBd3w/BCz3KOZRpesjmzkaKmVzCgKnlRh5XfmKnEkVEFCArrN 48EA== 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=hP647i9f/T8cIOBAP6mlnLrhJMUWoCrFQQsy4ra0mcM=; b=A8dfS6lfDZeTOBo47QFea3pMG14/zLNhazvxPyA+BuALWdImyFDOXE9BKldmpURjUH ebj4LKqY2aM+TURd2+HwhgyVxHHHyKkMNXFJQxyo3wL5trpQIYYuj7rd9qjQquiwHO/p ojAAXJtMYpP4/nA9hngXiR/WkgecjpXpJOadD0YzDQtqTJwPj8VJTFyT1slQo+KSV288 wjU/3MtBPYqX5mjOfPVjUyTMvsas84355UWwvP/jTALd4rJHUIADRLVQMownrqPfBGAG ju+OnNxQGILzvrlmXFcg55hGRmcekFVhDbmbvFEA3nWgjyY/i9HxKPyggXXvApHYQ7tp qLHw== X-Gm-Message-State: APjAAAU8Fv1pZ5JuFDRc5Da7h92Bmxo2e7mF/8RQ4X8OJkCZgsWV/BQ4 EpjqJOPi2vjCNgxtlVbt0jApMb7C/SI= X-Google-Smtp-Source: APXvYqyqzwZ/zW5Y33L8coSLiXq5ZnV2W3uY44AjrraWGiy3GxDSd81vBtauE5xrHtHPZAWfvFVJWw== X-Received: by 2002:a1c:c910:: with SMTP id f16mr11500943wmb.47.1557035543062; Sat, 04 May 2019 22:52:23 -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 v20sm4905854wmj.10.2019.05.04.22.52.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 May 2019 22:52:21 -0700 (PDT) To: Nico Williams Cc: Ulysse Carion , json@ietf.org References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <20190505053921.GA21049@localhost> From: Anders Rundgren Message-ID: Date: Sun, 5 May 2019 07:52:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190505053921.GA21049@localhost> 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 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: Sun, 05 May 2019 05:52:27 -0000 On 2019-05-05 07:39, Nico Williams wrote: > On Sat, May 04, 2019 at 06:47:35AM +0200, Anders Rundgren wrote: >> On 2019-05-04 01:59, Ulysse Carion wrote: >>> Hello all, >> >> Hello Ulysse, >> >> I'm a former user of XML Schema. I was therefore looking for similarities >> like data types and facets but didn't find them. >> >> Example: although 10.0 is a valid JSON Number, in system where you expect >> an integer, this should be flagged as a syntax error. > > As a maintainer of one popular implementation, this idea that having a > zero fractional part makes a number non-integer annoys me a great deal. As I described, this is incompatible with other popular implementations like Jackson for C#. A schema language should provide the flexibility you want but users should be aware of that certain combinations may not work so well in practice. A schema may for example specify an BigInteger "huge" and suggest serializing this as JSON Number which will give surprises when processed by ECMAScript's JSON.parse(). Anders > > I would insist that any parser that distinguishes real and integer > representations should parse numeric values with a zero fractional part > (and non-negative exponent) as integers. > > 10.0 is an integer, even if a parser only supports, e.g., IEEE754 > representations of numeric values. > > Nico > From nobody Sat May 4 22:56: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 64ECA12012E for ; Sat, 4 May 2019 22:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 6cMaIY7C95i0 for ; Sat, 4 May 2019 22:56:43 -0700 (PDT) Received: from smtp.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 6289812010C for ; Sat, 4 May 2019 22:56:43 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44xZr90tbzzyWW; Sun, 5 May 2019 07:56:41 +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: Sun, 5 May 2019 07:56:40 +0200 Cc: json@ietf.org, Ulysse Carion , Anders Rundgren X-Mao-Original-Outgoing-Id: 578728598.513872-4a49a11b1292c3928afdfbd4dabd5014 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> To: Austin Wright X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 05:56:45 -0000 On May 5, 2019, at 04:51, Austin Wright wrote: >=20 >> On that web page, it also says =E2=80=9CFor consistency, integer JSON = numbers SHOULD NOT be encoded with a fractional part.=E2=80=9D >>=20 >> What does that mean? >=20 > It=E2=80=99s a non-normative suggestion RFC 2119: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Very much normative. This is an RFC 2119 interoperability keyword = because it creates an expectation in peers that they can mostly rely on = this behavior, except for exceptional circumstances (which, by the way, = should be spelled out with the SHOULD NOT). I=E2=80=99m asking because we have a lot of experience with = specifications that purport to use a base standard but instead attempt = to create their own fork of that base standard by making mandates that = meddle with the functioning of that base standard. Not good. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat May 4 22:57:58 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 298261201A5 for ; Sat, 4 May 2019 22:57:57 -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, 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 c_ljJEAcEFFH for ; Sat, 4 May 2019 22:57:55 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 6064612019E for ; Sat, 4 May 2019 22:57:55 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id q15so11764823wmf.3 for ; Sat, 04 May 2019 22:57:55 -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=UxFuaKHtQ36hLZDgeN22L73prkAVdHoCKnCRFNeh7qk=; b=B9G7IaHVDUsqCx6FkQQOMkawXYCXuqfX60zBbCVJUSi11nFqUF0Bc4pnscXN5KEgnx m/VjU1kb2CjpDu3Toe0avZAE+nHhgdFO9l8Ouh9t3LlTmOkUKETDfd+WVpDyTQuKLd6u 2gFjkw9LfEy3cMWm1qtEXijUPgOapvZ1W4W90s2IlRnH0wUiGe8Fl7MsA6s5h0pA5Qh3 pDsYGyQr2nQdKaX2v0YCDvUlKXqJrY0oG60QgmTimYLXGPtwBAWDJIdCHYDu3NNSeBbd dXfMBaJnGHWd6HlLfPH4us2ML9xg1ki2K19uqCO1NadEv0nhc4gF0QCdyMbDJUrh/rQQ xTdg== 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=UxFuaKHtQ36hLZDgeN22L73prkAVdHoCKnCRFNeh7qk=; b=S4BFY/lBU0BVT6oKMmh/vOfS7pOUJMjheXGDy5mHmcu5GTAWCkm9hVhOJIBaQ7mpVh +k7o7Vz8IfZMCaZW9LTvfsOphL9MmBrcpeQw9lg7UOcNij2HGn3ydodHdKFrzsc7zsQE QxudxoAJeg7j+xDCOjH02nWNoDZy/oUpu/vN/MPRIxBXNVkw2yqLSDelItlZNhHvSFVq xlcd5rO1oMusFN7Ky1YHNKJ5emAp8fbTCMr2MIhZ56bT7siBpSs6tx5dEFyxEYGMorWr Hgt7gG6GUa/qLU/PqqT704n34/wwwXMYxmF3fg96I9/XOoYwsPVa/PdU/r6HxdolF3Sl 4nYQ== X-Gm-Message-State: APjAAAWuo08UvqPcsVFIy4MuChh43NTdB6azULoD3vHDICBgx9K6W52c 18K8OFigxC69xsRkp+Wu/Bg= X-Google-Smtp-Source: APXvYqyj9ihLLMbPXGqJi03jBfDCRv3Wlq211RilF7F4xXgVUEW3YKqWzB6QtaDHZWb2qRzF5h2KaQ== X-Received: by 2002:a1c:7404:: with SMTP id p4mr12599517wmc.104.1557035873821; Sat, 04 May 2019 22:57:53 -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 f3sm9461831wmb.1.2019.05.04.22.57.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 May 2019 22:57:52 -0700 (PDT) To: Carsten Bormann , Austin Wright Cc: json@ietf.org, Ulysse Carion References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> From: Anders Rundgren Message-ID: Date: Sun, 5 May 2019 07:57:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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 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: Sun, 05 May 2019 05:57:57 -0000 On 2019-05-05 07:56, Carsten Bormann wrote: > On May 5, 2019, at 04:51, Austin Wright wrote: >> >>> On that web page, it also says “For consistency, integer JSON numbers SHOULD NOT be encoded with a fractional part.” >>> >>> What does that mean? >> >> It’s a non-normative suggestion > > RFC 2119: > > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > > Very much normative. This is an RFC 2119 interoperability keyword because it creates an expectation in peers that they can mostly rely on this behavior, except for exceptional circumstances (which, by the way, should be spelled out with the SHOULD NOT). > > I’m asking because we have a lot of experience with specifications that purport to use a base standard but instead attempt to create their own fork of that base standard by making mandates that meddle with the functioning of that base standard. Not good. +100 > > Grüße, Carsten > From nobody Sat May 4 23:17:10 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 768CF12012E for ; Sat, 4 May 2019 23:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net 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 Kh8ax2UAly0B for ; Sat, 4 May 2019 23:17:06 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 C91DC120105 for ; Sat, 4 May 2019 23:17:06 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id cb4so818128plb.3 for ; Sat, 04 May 2019 23:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J7rNzC3UW6Zw5N3fknU7QQY4bm52us+G0OUopATZs74=; b=kV6b2pn/TVbsqw4v2AlOUrhebDUnwgzJY6/7HKCxAh0Z3d6ZCB7To2R+PSaYxtspcw Kffyv8zPxqDb9zl19EZ/DpeuDE57kkL+nf6uZ3wiETPeJEJ1RlMIaSSIbWILtEA2yRnK Y15e5+AmLPIy7QmLv+i3x8c4+UXYdAbBsgeGY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J7rNzC3UW6Zw5N3fknU7QQY4bm52us+G0OUopATZs74=; b=L5JCUOKDwMeDuNG9FENyrsefn+6PtKKtT4uCX0fJpxGtNt7tiUV1+mRrCHrDTXxXTc M0UjLSkGf61Sf45NDQOnbPtN/zZqERKPIOuBhh/C76Fk5PgPrmoFn7JVO/n8L5IN2d+P 0HsllwtNoODkA+5FCmdbQpGVQYK20X6oBaUNbONfETe4G7fezGNq2oke5ljPhzy32yjq t+9anP7itpCl/3rT1OBsCeX6/R5qBa9jovctD38TrvVu5yqyih77DoAsb1kkrWyGpDFN D8iuIopErTrncumu1lb1IoMiIdWaqAUX4Ca4kR2O/nrCNvUoTu0/oi7gpZO/MoFrsknj 15DQ== X-Gm-Message-State: APjAAAVvEL8pT05D/2LlWqLCIWy4j8Mg0j9q0cKAzL0iEaKkA50MFrcN 5DniAx7rScIxhTuAywqyuA4I8w== X-Google-Smtp-Source: APXvYqxYAvlyelVvWxzKLGjgoO/H7Dt7ddW1L5IhAJigY1AkeCDu7ML7IOlMmvPakmRBzQ3HEwVHOA== X-Received: by 2002:a17:902:108a:: with SMTP id c10mr16267714pla.48.1557037025989; Sat, 04 May 2019 23:17:05 -0700 (PDT) Received: from [192.168.0.116] ([184.101.46.90]) by smtp.gmail.com with ESMTPSA id k26sm8267662pfi.136.2019.05.04.23.17.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 May 2019 23:17:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Austin Wright In-Reply-To: <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> Date: Sat, 4 May 2019 23:16:42 -0700 Cc: Carsten Bormann , json@ietf.org, Ulysse Carion Content-Transfer-Encoding: quoted-printable Message-Id: <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> To: Anders Rundgren X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 06:17:09 -0000 > On May 4, 2019, at 22:07, Anders Rundgren = wrote: >=20 > On 2019-05-05 04:51, Austin Wright wrote: >>> On May 4, 2019, at 02:42, Carsten Bormann wrote: >>>=20 >>> Curious: >>>=20 >>> On that web page, it also says =E2=80=9CFor consistency, integer = JSON numbers SHOULD NOT be encoded with a fractional part.=E2=80=9D >>>=20 >>> What does that mean? >> It=E2=80=99s a non-normative suggestion with the aim of enhancing = performance: Many programming languages distinguish between integers and = IEEE floats by the presence of a decimal point. While JSON makes no such = distinction (all numbers are arbitrary precision decimal), some parsers = do make that distinction, and it=E2=80=99s slightly easier to determine = if an int32_t is an integer than if a double is an integer. >=20 > in the C# example I provided before this is (by default) not = non-normative, since it threw an exception. Here is a little bit more = detail: >=20 > class MyObject { > int Counter; > . > . > } >=20 > Deserializing JSON into this type (which BTW works as as "schema"), = REQUIRES "Counter" data to adhere to normal integer notation, including = value span. >=20 > A scheme language should align with the actual use and interpretation = of JSON. This involves alternative serialization formats as well. As = an example monetary values are (probably without exceptions) expressed = as JSON Strings since floating point is unsuited for decimal arithmetic. >=20 > Based on the RFC, one might come to the conclusion that JSON is an = inferior information transfer format, but aided by external mapping it = actually works extremely well, albeit being slightly verbose :) The Newtonsoft.Json parser behavior would be incompatible with JSON = Schema, according to what you provided. But I can=E2=80=99t imagine = it=E2=80=99s much of an issue: If the encoder knows the value will = always be an integer, why add a fractional part? That behavior still seems arbitrary to me, though. Instead of erroring = on the first period, all you have to do is error on the first nonzero = after the period. Scientific notation is another matter, but presumably = it allows 1.9e4 as a valid integer? (I=E2=80=99m not sure, off-hand.) Probably a better way to approach JSON parsers is to raise an error if = it can=E2=80=99t preserve all the information in the source. For = example, you can preserve 1e10, 0.5, and even 0.1 (if you permit a small = error, such that if you converted the float back to decimal, 0.1 would = still be the closest decimal representation). But you can=E2=80=99t = preserve 9007199254740993.5 as a double: it=E2=80=99s too many = significant figures, and above that value, the precision is below 1. In = this case, you would throw. Parsers that ensure the preservation of the encoded data like this might = encourage better use of the JSON types, like for monetary values, even = if you are reading into an IEEE floating point. Still, now that we bring it up, that SHOULD NOT seems suspicious. It=E2=80= =99s stating the obvious. Austin. >=20 > Cheers, > Anders >=20 >> Cheers, >> Austin. >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>>> On May 4, 2019, at 11:36, Austin Wright wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On May 4, 2019, at 00:58, Carsten Bormann wrote: >>>>>=20 >>>>> On May 4, 2019, at 06:47, Anders Rundgren = wrote: >>>>>>=20 >>>>>> Example: although 10.0 is a valid JSON Number, in system where = you expect >>>>>> an integer, this should be flagged as a syntax error. >>>>>=20 >>>>> 10.0 is an integer number. >>>>>=20 >>>>> =E2=80=9CSchema Languages=E2=80=9D operate at the data model = level. In the JSON data model, there is only one kind of number. >>>>> Of course, the JSON data model is not actually defined in a = standard, which is one of the major shortcomings of JSON. >>>>>=20 >>>>=20 >>>> JSON Schema handles this exactly the same way, defining a data = model [1]. The lexical representation is surjective onto the data model: = as you point out, 10.0 is the same as 10, which is an integer. >>>>=20 >>>> The one case where this might fall apart is if significant digits = are important, such that 10.0 is different than 10.00 (i.e., 10.00 is = more precise by an order of magnitude). However, I=E2=80=99m not aware = of any JSON parsers that keep track of the precision of numbers, even = ones that support arbitrary precision. I imagine scientific applications = would want to store an explicit precision, since they=E2=80=99re not = always powers-of-10 (e.g. {value: 32.0, precision: 0.5}). >>>>=20 >>>> [1] = http://json-schema.org/latest/json-schema-core.html#rfc.section.4.2.1 = "4.2.1. Instance Data Model" >>>>=20 >>>> Austin. >>>=20 >=20 From nobody Sat May 4 23:36: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 10DF0120049 for ; Sat, 4 May 2019 23:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 xwG7WK12oJ27 for ; Sat, 4 May 2019 23:36:44 -0700 (PDT) Received: from smtp.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 3C59212000E for ; Sat, 4 May 2019 23:36:44 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44xbkL35JFzySR; Sun, 5 May 2019 08:36:42 +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: <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> Date: Sun, 5 May 2019 08:36:41 +0200 Cc: Anders Rundgren , Ulysse Carion , json@ietf.org X-Mao-Original-Outgoing-Id: 578731000.013554-d7a4afd0e9e5d2e67b9351cfce1febf0 Content-Transfer-Encoding: quoted-printable Message-Id: <876194AE-E1A5-438D-A2A0-58568ED10FE5@tzi.org> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> To: Austin Wright X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 06:36:46 -0000 On May 5, 2019, at 08:16, Austin Wright wrote: >=20 > If the encoder knows the value will always be an integer, why add a = fractional part? (1) The encoder may not be privy to that information (it is a generic = encoder). (2) The encoder may try to fulfill a conflicting set of rules, set up by = a different fork of the base standard, e.g.: If the data comes as a floating point typed value, encode it as NR2 or = NR3. If the data comes as an integer typed value, encode it as NR1. (This rule set is intended to preserve the distinction in implementation = types, which may be important to some other application. It is common in programming language notation, and since JSON was also = derived from a programming language notation [albeit one without this = rule set!], it is a common mistake to assume that this rule set can be = applied to JSON without cost or damage.) These conflicting sets of rules are exactly why it's so detrimental to = fork a base standard with your own set of rules. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat May 4 23:49: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 7A951120049 for ; Sat, 4 May 2019 23:49:53 -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, 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 9K1wplbizVLa for ; Sat, 4 May 2019 23:49:50 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 4303912000E for ; Sat, 4 May 2019 23:49:50 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id l2so13033255wrb.9 for ; Sat, 04 May 2019 23:49:50 -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=B2U0gGP3MSVnIm92Zl8T9PiBgYZZkJNDDCIEsu/+DSo=; b=IDiFaLd+UwlEbN9B26WNZXX9E9rHgO+7huUZmpd7guPc3lG++ay8XF/A25N2atIa2Q H8hGewgfn7ilkUeNI9meQZprq4VHgMc+w+YvCAhczc2W7LOh2WIo+7nJahOG8BcPmBXb 3bWW44VTZRK2gGXZc+vTbaiqe4WJwDuyU4RpBI/guBGFTVoauGGC1mYoxZqlLtbjlZzY 5uC+cUjDQV50aPqudrAhDOLn4e27h1POQyY8tjhRoBP/7O1UFVp/qRsNW/QJZ1iq2I81 OzmYFFGZIvr48ebHM/SsVp/KvOLmEr62aKP7YrVrSSJR3QalgevpVVciHYfkk1UdwGpd O3Aw== 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=B2U0gGP3MSVnIm92Zl8T9PiBgYZZkJNDDCIEsu/+DSo=; b=CgyxO8d7Bd+tqxI5+tCOLCAjLY1eVDWn4wOyZ5U+be85XaF0RGLR5JatH85lkGA4ZG 1nStdycjnIZPv3wtjTGtA0Sm46xytI5aJgMxIEnVowSkYhv0Mh4UhHBV0P9bbffrML5T ae4C8QxijUorRJefLvxW7th5s1cVnuHLn6crMOjZdHryX1QxlsWGYFMh6i48Bm8wH7Gw UdpA2/8/ObHeij9Hz54VzlWbuN24a4zAJcLgw78XDz0+ytffRS2wUHKhcfChRHWUI7uN pLxCSIzNRImBcqASTTdAM9HehCBg9KJqNgbf4ugjajHjza9xrxzTibfWQiB8n+Q6FiHd oNFg== X-Gm-Message-State: APjAAAVzr8nSc9Ly58ppD0sSn0wXyczHSQkf+pYTcmFhW9Hpz3quS8K2 HtMNjQDqHUh8tfCd9ClraQg= X-Google-Smtp-Source: APXvYqx6OkPWlW2gCZ0vk+1CeNjOIWs+g0uOgdggVzhB38ZQ263YCb2obIyUPhE8/NuNydbgFb9+IQ== X-Received: by 2002:adf:8122:: with SMTP id 31mr2445989wrm.112.1557038988569; Sat, 04 May 2019 23:49:48 -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 j10sm20730128wrb.0.2019.05.04.23.49.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 May 2019 23:49:46 -0700 (PDT) To: Austin Wright Cc: Carsten Bormann , json@ietf.org, Ulysse Carion References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> From: Anders Rundgren Message-ID: <6260354b-aca2-e001-7145-148b32658416@gmail.com> Date: Sun, 5 May 2019 08:49:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> 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 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: Sun, 05 May 2019 06:49:53 -0000 On 2019-05-05 08:16, Austin Wright wrote: > > >> On May 4, 2019, at 22:07, Anders Rundgren wrote: >> >> On 2019-05-05 04:51, Austin Wright wrote: >>>> On May 4, 2019, at 02:42, Carsten Bormann wrote: >>>> >>>> Curious: >>>> >>>> On that web page, it also says “For consistency, integer JSON numbers SHOULD NOT be encoded with a fractional part.” >>>> >>>> What does that mean? >>> It’s a non-normative suggestion with the aim of enhancing performance: Many programming languages distinguish between integers and IEEE floats by the presence of a decimal point. While JSON makes no such distinction (all numbers are arbitrary precision decimal), some parsers do make that distinction, and it’s slightly easier to determine if an int32_t is an integer than if a double is an integer. >> >> in the C# example I provided before this is (by default) not non-normative, since it threw an exception. Here is a little bit more detail: >> >> class MyObject { >> int Counter; >> . >> . >> } >> >> Deserializing JSON into this type (which BTW works as as "schema"), REQUIRES "Counter" data to adhere to normal integer notation, including value span. >> >> A scheme language should align with the actual use and interpretation of JSON. This involves alternative serialization formats as well. As an example monetary values are (probably without exceptions) expressed as JSON Strings since floating point is unsuited for decimal arithmetic. >> >> Based on the RFC, one might come to the conclusion that JSON is an inferior information transfer format, but aided by external mapping it actually works extremely well, albeit being slightly verbose :) > > The Newtonsoft.Json parser behavior would be incompatible with JSON Schema, according to what you provided. But I can’t imagine it’s much of an issue: If the encoder knows the value will always be an integer, why add a fractional part? Right, my guess is that not a single mainstream serializer adds a fractional part to a number that can be exactly represented as an integer regardless if they underlying number type is an integer or not. > That behavior still seems arbitrary to me, though. Instead of erroring on the first period, all you have to do is error on the first nonzero after the period. Scientific notation is another matter, but presumably it allows 1.9e4 as a valid integer? (I’m not sure, off-hand.) To me the whole idea of having a scheme is to create a *clean* description of an object. Predecessors like XML Schema supported this in (IMO) a pretty good way. However, this was straightforward since XML doesn't come with a built-in data model. JSON was derived from JavaScript (anno 2003 or so) which didn't have an explicit integer type, only an unconstrained Number type. This obviously creates certain issues when communicating with platforms having a completely different handling of numeric data. The new proposal doesn't take this is consideration. > Probably a better way to approach JSON parsers is to raise an error if it can’t preserve all the information in the source. For example, you can preserve 1e10, 0.5, and even 0.1 (if you permit a small error, such that if you converted the float back to decimal, 0.1 would still be the closest decimal representation). But you can’t preserve 9007199254740993.5 as a double: it’s too many significant figures, and above that value, the precision is below 1. In this case, you would throw. A schema should not try to change how parsers work. > > Parsers that ensure the preservation of the encoded data like this might encourage better use of the JSON types, like for monetary values, even if you are reading into an IEEE floating point. See previous point. > Still, now that we bring it up, that SHOULD NOT seems suspicious. It’s stating the obvious. > > Austin. > >> >> Cheers, >> Anders >> >>> Cheers, >>> Austin. >>>> >>>> Grüße, Carsten >>>> >>>> >>>>> On May 4, 2019, at 11:36, Austin Wright wrote: >>>>> >>>>> >>>>> >>>>>> On May 4, 2019, at 00:58, Carsten Bormann wrote: >>>>>> >>>>>> On May 4, 2019, at 06:47, Anders Rundgren wrote: >>>>>>> >>>>>>> Example: although 10.0 is a valid JSON Number, in system where you expect >>>>>>> an integer, this should be flagged as a syntax error. >>>>>> >>>>>> 10.0 is an integer number. >>>>>> >>>>>> “Schema Languages” operate at the data model level. In the JSON data model, there is only one kind of number. >>>>>> Of course, the JSON data model is not actually defined in a standard, which is one of the major shortcomings of JSON. >>>>>> >>>>> >>>>> JSON Schema handles this exactly the same way, defining a data model [1]. The lexical representation is surjective onto the data model: as you point out, 10.0 is the same as 10, which is an integer. >>>>> >>>>> The one case where this might fall apart is if significant digits are important, such that 10.0 is different than 10.00 (i.e., 10.00 is more precise by an order of magnitude). However, I’m not aware of any JSON parsers that keep track of the precision of numbers, even ones that support arbitrary precision. I imagine scientific applications would want to store an explicit precision, since they’re not always powers-of-10 (e.g. {value: 32.0, precision: 0.5}). >>>>> >>>>> [1] http://json-schema.org/latest/json-schema-core.html#rfc.section.4.2.1 "4.2.1. Instance Data Model" >>>>> >>>>> Austin. >>>> >> > From nobody Sun May 5 00:00:34 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 29DA512006F for ; Sun, 5 May 2019 00:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 zey_5SbTDikA for ; Sun, 5 May 2019 00:00:31 -0700 (PDT) Received: from ostrich.birch.relay.mailchannels.net (ostrich.birch.relay.mailchannels.net [23.83.209.138]) (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 3554412000E for ; Sun, 5 May 2019 00:00:30 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C1C49125823; Sun, 5 May 2019 07:00:29 +0000 (UTC) Received: from pdx1-sub0-mail-a31.g.dreamhost.com (unknown [100.96.28.64]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 26CDE1257FA; Sun, 5 May 2019 07:00:29 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a31.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Sun, 05 May 2019 07:00:29 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Hook-Broad: 410bce3e553415c6_1557039629411_3404758889 X-MC-Loop-Signature: 1557039629411:3537442704 X-MC-Ingress-Time: 1557039629410 Received: from pdx1-sub0-mail-a31.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTP id 47F897F0F0; Sun, 5 May 2019 00:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=B4Wn3QM/VtNn0V ttAUWsTn8snTE=; b=dchiz9uLcqoFngOGLCy5lV+Nxn9GkwdGKECPX4J0Bm4p1y 18md2UkY/5hJHqWhd6mampoX2Z7YNH5ke5P1Alg9cH8O1WKZAlIZu8H/SSDMRiwq 4ckmBn/2Y0u0MO1gbwEJEH2Ye48Kh1Q7uT5x46rKz5RcIs++fmgOZGKZTvzxU= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 10B577F0F1; Sun, 5 May 2019 00:00:26 -0700 (PDT) Date: Sun, 5 May 2019 02:00:24 -0500 X-DH-BACKEND: pdx1-sub0-mail-a31 From: Nico Williams To: Anders Rundgren Cc: Ulysse Carion , json@ietf.org Message-ID: <20190505070023.GB21049@localhost> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <20190505053921.GA21049@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrjeeggdduudeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 07:00:33 -0000 On Sun, May 05, 2019 at 07:52:18AM +0200, Anders Rundgren wrote: > On 2019-05-05 07:39, Nico Williams wrote: > > On Sat, May 04, 2019 at 06:47:35AM +0200, Anders Rundgren wrote: > > > On 2019-05-04 01:59, Ulysse Carion wrote: > > > > Hello all, > > > > > > Hello Ulysse, > > > > > > I'm a former user of XML Schema. I was therefore looking for similarities > > > like data types and facets but didn't find them. > > > > > > Example: although 10.0 is a valid JSON Number, in system where you expect > > > an integer, this should be flagged as a syntax error. > > > > As a maintainer of one popular implementation, this idea that having a > > zero fractional part makes a number non-integer annoys me a great deal. > > As I described, this is incompatible with other popular > implementations like Jackson for C#. That sounds like a bug in Jackson. Nico -- From nobody Sun May 5 00:12: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 36884120021 for ; Sun, 5 May 2019 00:12: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, 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 vWEFUgiuOQZf for ; Sun, 5 May 2019 00:12:12 -0700 (PDT) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 7F88612000E for ; Sun, 5 May 2019 00:12:12 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id o25so769597wmf.2 for ; Sun, 05 May 2019 00:12:12 -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=mcGes44c5EWzx9Uxix995RKS8k3KbES8aWhiVAUeRfU=; b=LJZsrPjvEoVQlGrEPigEVo68BwrfnuzOXArYlj8/GFuzVnBUIiglVZqSK/douMcJ3i jrTF7ZzmA4VY8ePotfnPbphUZ5OSZ0ePOuY5+TEp4ZerlD9HP0/dTPjbdN5sRI3YMJPY CdJEO8CeJbszh0PAFTgbBMQP/9oD+ikfX5kvYC8NivpDr8ZYgIGfwARYWKHw38m60cM4 LVbhbgan2baIN1qV4OycOX7QB+amqVRKux+eouIA09trNXBTaYcfXs2TMq3AsVrOi/b5 bm7K+y+faDvMo998ddNxMdOiHg0CIrIR0QutAQvwLj1Z7Ph7Lel0D4yH1U7zU/zC1Xzz geCA== 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=mcGes44c5EWzx9Uxix995RKS8k3KbES8aWhiVAUeRfU=; b=nNOM9CknSeMD6Mpd3P3I1OCxrMFjyLOIPrVxeEsA7Q0XLczZw9JAoW0NYHqNeoqojO juxrU7l+LIoOdKbbShp7LNbnzWYaP+4o1e4U68klQO4aJcvAlKjkyMJmy27V7YLm770P 2rSAk38tdbTg3SaHqkDqUja9OpGE+VwhlKlqqA8q1wsGV52KB6t8p54p9ND3/M7fPykW xbR705yzj6nL/wzCozrJpV8qEY4iZhQtxVGeKmN1INyaCV0GmfoMHZdJJ+HbpxsxYoU/ dMQYOLw4WXiI2XYX7neZdTzd9PL9yKVwid6DHxxKUx0mc2gQNkNbrMImgIH0+V47P0FO +O2w== X-Gm-Message-State: APjAAAVJACC2NyWFxO/NoOPcpD0iVHY1pn6q/porM76lU3ITKtUajQN7 NmDjUZ7yGLSzd8i23MBdojVtRvvZWuI= X-Google-Smtp-Source: APXvYqyaP2s07ciHk98tFeJwcZkrIxQpWWqcSc0AIlVjU3wJxDDIssFS3XZE09McBj9RhenHCS/Lfg== X-Received: by 2002:a1c:c910:: with SMTP id f16mr11688667wmb.47.1557040330667; Sun, 05 May 2019 00:12:10 -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 c139sm11353981wmd.26.2019.05.05.00.12.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 May 2019 00:12:09 -0700 (PDT) To: Nico Williams Cc: Ulysse Carion , json@ietf.org References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <20190505053921.GA21049@localhost> <20190505070023.GB21049@localhost> From: Anders Rundgren Message-ID: <56070772-de6f-2553-94c0-df75c08b4c80@gmail.com> Date: Sun, 5 May 2019 09:12:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190505070023.GB21049@localhost> 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 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: Sun, 05 May 2019 07:12:14 -0000 On 2019-05-05 09:00, Nico Williams wrote: > On Sun, May 05, 2019 at 07:52:18AM +0200, Anders Rundgren wrote: >> On 2019-05-05 07:39, Nico Williams wrote: >>> On Sat, May 04, 2019 at 06:47:35AM +0200, Anders Rundgren wrote: >>>> On 2019-05-04 01:59, Ulysse Carion wrote: >>>>> Hello all, >>>> >>>> Hello Ulysse, >>>> >>>> I'm a former user of XML Schema. I was therefore looking for similarities >>>> like data types and facets but didn't find them. >>>> >>>> Example: although 10.0 is a valid JSON Number, in system where you expect >>>> an integer, this should be flagged as a syntax error. >>> >>> As a maintainer of one popular implementation, this idea that having a >>> zero fractional part makes a number non-integer annoys me a great deal. >> >> As I described, this is incompatible with other popular >> implementations like Jackson for C#. > > That sounds like a bug in Jackson. It also flags numbers that doesn't fit into the declared type. Anders > > Nico > From nobody Sun May 5 09:36:36 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 0DE33120148 for ; Sun, 5 May 2019 09:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 7lgQ_9DrzZMO for ; Sun, 5 May 2019 09:36:33 -0700 (PDT) Received: from orchid.birch.relay.mailchannels.net (orchid.birch.relay.mailchannels.net [23.83.209.137]) (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 13A9112002E for ; Sun, 5 May 2019 09:36:32 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id DC2FA125A07; Sun, 5 May 2019 16:36:31 +0000 (UTC) Received: from pdx1-sub0-mail-a12.g.dreamhost.com (unknown [100.96.11.48]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8119B1259B4; Sun, 5 May 2019 16:36:31 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a12.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Sun, 05 May 2019 16:36:31 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Keen-Thoughtful: 1d9c8264793964b8_1557074191698_2305547773 X-MC-Loop-Signature: 1557074191698:3826866540 X-MC-Ingress-Time: 1557074191698 Received: from pdx1-sub0-mail-a12.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a12.g.dreamhost.com (Postfix) with ESMTP id 42D318019F; Sun, 5 May 2019 09:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=uQ1PWyeOeLAVlg ueG16GxkaqTic=; b=OoxsOobp0/jTbdREBi/0q972oHTO1OjOQhkao0rX4wjNua ZorzhpfF/I9hdQSEB5L7JoZjuxf4zS7KuCvuWEJZYnZckzFymSnNluEfFOnFtKFk /pu/kRBkJQN43iuuCn+XW2C12i7tFseJPxg+z8S0RS02Zhhv1DbC4cis30zA0= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 163CB801B3; Sun, 5 May 2019 09:36:29 -0700 (PDT) Date: Sun, 5 May 2019 11:36:27 -0500 X-DH-BACKEND: pdx1-sub0-mail-a12 From: Nico Williams To: Anders Rundgren Cc: Ulysse Carion , json@ietf.org Message-ID: <20190505163626.GC21049@localhost> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <20190505053921.GA21049@localhost> <20190505070023.GB21049@localhost> <56070772-de6f-2553-94c0-df75c08b4c80@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56070772-de6f-2553-94c0-df75c08b4c80@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrjeehgdduuddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 16:36:35 -0000 On Sun, May 05, 2019 at 09:12:05AM +0200, Anders Rundgren wrote: > On 2019-05-05 09:00, Nico Williams wrote: > > On Sun, May 05, 2019 at 07:52:18AM +0200, Anders Rundgren wrote: > > > On 2019-05-05 07:39, Nico Williams wrote: > > > > On Sat, May 04, 2019 at 06:47:35AM +0200, Anders Rundgren wrote: > > > > > Example: although 10.0 is a valid JSON Number, in system where you expect > > > > > an integer, this should be flagged as a syntax error. > > > > > > > > As a maintainer of one popular implementation, this idea that having a > > > > zero fractional part makes a number non-integer annoys me a great deal. > > > > > > As I described, this is incompatible with other popular > > > implementations like Jackson for C#. > > > > That sounds like a bug in Jackson. > > It also flags numbers that doesn't fit into the declared type. That's a different story. An application may not have control over what its encoder does here, but it will have control over the semantic values. So if a value is expected to be an integer between 0 and 9, inclusive, then 10.0 is not valid. But 9.0 must be because there can be and almost certainly are encoders that will output integers with a zero fractional part. Nico -- From nobody Sun May 5 10:05: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 6D115120159 for ; Sun, 5 May 2019 10:05:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-org.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 P1x1f69L60m9 for ; Sun, 5 May 2019 10:05:44 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 DC1F1120148 for ; Sun, 5 May 2019 10:05:43 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id l2so14231756wrb.9 for ; Sun, 05 May 2019 10:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zh6qpcr44WkRwBzd3/UMsdfqH7YSAKFwvT0sFGP1iAs=; b=fukOuxKKLBcOMtInHeN2na0J+diUgsNHkSmx3osNVC2nopxuAHgJmDsbEYZYR5AGEu TZCOemIG7OadE41Bk1N/1dWGmOz6Wyc7lq5k7xLOud/q9OiIchOWAnk/TjzXTXcwCGOF 7eYzjLcWsEb20PYeXLz5GNJsapIoHbnNbOWBUYbpZnmzL68wY/uCSrngzlVN5uZn5AV1 C8W7KjT39K9UEZC8Z/7WJ+e7cHSqMdlQgwm4PiIjjAS6nYbjm+bkIqsXOCAj2QDHZxTT zhBn+85glLPCRP3uK9PUaojx/k7fNQ1XpxhTpEQMVr6j8HOzGLk9TqKMWPICpFoOAfE0 7J+Q== 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=Zh6qpcr44WkRwBzd3/UMsdfqH7YSAKFwvT0sFGP1iAs=; b=gLI0zTue2Zp3ueoeMnO2VYg4WTBKj5yJGQCpkROH35bISaqDHTMsOxuvF0ZVYyc6Dt 76DsO/70NwbRXXf9fK8MM2WbBjv5wNF31r18HF8y7pU9wTK3/PTQFQwiGADAjKNc/UTC pyJU8ID+addnGomzZgQdZRXYevi/7l6vQFgo/oV7Y4q1io98avdftLWOgaylqNnfwmMg RMCAjrIUuENNzdGvzKuns0uw++cSh4LBycE+bnlUjevEQmsQC9yf5z5lOZuMhLwLUVrI 6jf54CjxsT/nRcYMtLZCvJftt/NFFwGwpZM7QUSlc/iBZbCJcw1xN/uLLhBOhMxRY9cL ABgg== X-Gm-Message-State: APjAAAXFI+PXXFSHrPAWEQNgVqaHXc7uBkH04sUfUPP2PhaH5HadYXzr sEtsUN7TExpXLWyoRtj0E4i6LTPr9nMwsKQdCS4FjQ== X-Google-Smtp-Source: APXvYqz2SrKdAX8ol88e/XuRHigoNrlMi0s8XXVjjx5MqHDgF/cdw0glrC6bUGOpWzZs67Ck9Txk1TF6JuPTiS61vFE= X-Received: by 2002:a05:6000:c2:: with SMTP id q2mr4289834wrx.324.1557075942304; Sun, 05 May 2019 10:05:42 -0700 (PDT) MIME-Version: 1.0 References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <20190505053921.GA21049@localhost> <20190505070023.GB21049@localhost> <56070772-de6f-2553-94c0-df75c08b4c80@gmail.com> <20190505163626.GC21049@localhost> In-Reply-To: <20190505163626.GC21049@localhost> From: John Cowan Date: Sun, 5 May 2019 13:05:30 -0400 Message-ID: To: Nico Williams Cc: Anders Rundgren , json@ietf.org, Ulysse Carion Content-Type: multipart/alternative; boundary="0000000000006e04c6058826fe12" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 17:05:46 -0000 --0000000000006e04c6058826fe12 Content-Type: text/plain; charset="UTF-8" The Scheme language makes very clear distinctions here. Integers are a subset of rational numbers, which are a subset of real numbers, which are a subset of complex numbers, and there are predicates for detecting any of them (normally `complex?` is the same as `number?`, but if you want to add quaternions you can). Orthogonal to this, there are exact and inexact numbers: a numeric literal can be explicitly marked as either one, but the default is that a number with a decimal point or exponent is inexact, and without either it is exact. Mixed exactness operations produce inexact results unless the implementation can prove that the inexactness can't matter: the product of 5.0 (inexact) and 0 (exact) can be either exact or inexact. On Sun, May 5, 2019 at 12:36 PM Nico Williams wrote: > On Sun, May 05, 2019 at 09:12:05AM +0200, Anders Rundgren wrote: > > On 2019-05-05 09:00, Nico Williams wrote: > > > On Sun, May 05, 2019 at 07:52:18AM +0200, Anders Rundgren wrote: > > > > On 2019-05-05 07:39, Nico Williams wrote: > > > > > On Sat, May 04, 2019 at 06:47:35AM +0200, Anders Rundgren wrote: > > > > > > Example: although 10.0 is a valid JSON Number, in system where > you expect > > > > > > an integer, this should be flagged as a syntax error. > > > > > > > > > > As a maintainer of one popular implementation, this idea that > having a > > > > > zero fractional part makes a number non-integer annoys me a great > deal. > > > > > > > > As I described, this is incompatible with other popular > > > > implementations like Jackson for C#. > > > > > > That sounds like a bug in Jackson. > > > > It also flags numbers that doesn't fit into the declared type. > > That's a different story. > > An application may not have control over what its encoder does here, but > it will have control over the semantic values. So if a value is > expected to be an integer between 0 and 9, inclusive, then 10.0 is not > valid. But 9.0 must be because there can be and almost certainly are > encoders that will output integers with a zero fractional part. > > Nico > -- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --0000000000006e04c6058826fe12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The Scheme language makes very clear distinctions here.=C2= =A0 Integers are a subset of rational numbers, which are a subset of real n= umbers, which are a subset of complex numbers, and there are predicates for= detecting any of them (normally `complex?` is the same as `number?`, but i= f you want to add quaternions you can).=C2=A0

Orthogonal= to this, there are exact and inexact numbers: a numeric literal can be exp= licitly marked as either one, but the default is that a number with a decim= al point or exponent is inexact, and without either it is exact.=C2=A0 Mixe= d exactness operations produce inexact results unless the implementation ca= n prove that the inexactness can't matter: the product of 5.0 (inexact)= and 0 (exact) can be either exact or inexact.

On Sun, May 5, 2019 at = 12:36 PM Nico Williams <nico@cr= yptonector.com> wrote:
On Sun, May 05, 2019 at 09:12:05AM +0200, Anders Rundgren wro= te:
> On 2019-05-05 09:00, Nico Williams wrote:
> > On Sun, May 05, 2019 at 07:52:18AM +0200, Anders Rundgren wrote:<= br> > > > On 2019-05-05 07:39, Nico Williams wrote:
> > > > On Sat, May 04, 2019 at 06:47:35AM +0200, Anders Rundgr= en wrote:
> > > > > Example: although 10.0 is a valid JSON Number, in = system where you expect
> > > > > an integer, this should be flagged as a syntax err= or.
> > > >
> > > > As a maintainer of one popular implementation, this ide= a that having a
> > > > zero fractional part makes a number non-integer annoys = me a great deal.
> > >
> > > As I described, this is incompatible with other popular
> > > implementations like Jackson for C#.
> >
> > That sounds like a bug in Jackson.
>
> It also flags numbers that doesn't fit into the declared type.

That's a different story.

An application may not have control over what its encoder does here, but it will have control over the semantic values.=C2=A0 So if a value is
expected to be an integer between 0 and 9, inclusive, then 10.0 is not
valid.=C2=A0 But 9.0 must be because there can be and almost certainly are<= br> encoders that will output integers with a zero fractional part.

Nico
--

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--0000000000006e04c6058826fe12-- From nobody Sun May 5 14:11:27 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 86F83120077 for ; Sun, 5 May 2019 14:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 e7KmkU44J2jD for ; Sun, 5 May 2019 14:11:25 -0700 (PDT) Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) (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 E2F4A120006 for ; Sun, 5 May 2019 14:11:24 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2C0545E1DF5; Sun, 5 May 2019 21:11:24 +0000 (UTC) Received: from pdx1-sub0-mail-a88.g.dreamhost.com (100-96-78-10.trex.outbound.svc.cluster.local [100.96.78.10]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A3AEE5E1C7E; Sun, 5 May 2019 21:11:23 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a88.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Sun, 05 May 2019 21:11:24 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Fumbling-Spill: 5520ed114bae9bd9_1557090684009_1459079199 X-MC-Loop-Signature: 1557090684009:4074013240 X-MC-Ingress-Time: 1557090684009 Received: from pdx1-sub0-mail-a88.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a88.g.dreamhost.com (Postfix) with ESMTP id 60384808F5; Sun, 5 May 2019 14:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=J/rMxBTvzhZTDp n/BRkBqx/C2Qc=; b=GnbXu4XQYHFW69a2jtkZ6v1gj9t+M52C7b1pPFTOMCMJuU QBC89mfy6lywkESzEMd1G9X/vN5Vm9Fu6CP58AAjY/Q6FmzaP9By+8LriWm5Wwc0 bvG/OdB9Fcz8D2w6UOcT/5kXcoVAYUwWAQG6nXmIA7REntExZRTtUXjxWgG1M= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a88.g.dreamhost.com (Postfix) with ESMTPSA id EF998808FB; Sun, 5 May 2019 14:11:16 -0700 (PDT) Date: Sun, 5 May 2019 16:11:14 -0500 X-DH-BACKEND: pdx1-sub0-mail-a88 From: Nico Williams To: John Cowan Cc: Anders Rundgren , json@ietf.org, Ulysse Carion Message-ID: <20190505211113.GD21049@localhost> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <20190505053921.GA21049@localhost> <20190505070023.GB21049@localhost> <56070772-de6f-2553-94c0-df75c08b4c80@gmail.com> <20190505163626.GC21049@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrjeehgdduieeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2019 21:11:26 -0000 On Sun, May 05, 2019 at 01:05:30PM -0400, John Cowan wrote: > The Scheme language makes very clear distinctions here. Integers are a > subset of rational numbers, which are a subset of real numbers, which are a > subset of complex numbers, and there are predicates for detecting any of > them (normally `complex?` is the same as `number?`, but if you want to add > quaternions you can). We're not talking about Scheme. We're talking about JSON. JSON allows encoders to output 10.0, therefore parsers should handle it. If a schema indicates that some value should be an integer, and the parser sees 10.0, then the parser should accept that as the integer value 10. Nico -- From nobody Sun May 5 23:33: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 9F1C51200C3 for ; Sun, 5 May 2019 23:33:14 -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_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 yZS9PI-ucEKl for ; Sun, 5 May 2019 23:33:12 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 8B47012008D for ; Sun, 5 May 2019 23:33:12 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id w12so2215475wrp.2 for ; Sun, 05 May 2019 23:33:12 -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=IzUUI9iCtrldELUQXGq+i8oW5btYR02XjhPh0wrbZbY=; b=QXpLYU1Dp7Po0q9Es7XkxTEvJekYkTHI0MSDmFAQLcpnopZY1lzk0C6VwikXXBK5L1 p96691R1sf4+yHU4xCOvl3s4yt+ulmyS7dZUaHB0itBfQEcK2mSWqeSUz+2hnxFK724w WWq4mhzamZTu8s3oLlwsVdOYke5OchqXL7KeQ/InSEx452skM3ZF9/it6zyeOjF4UILv IcWgVwiA7SSWXkl8bBY+Lp0DCkLG5gsUj0uP0TV+LkheEIrFdB2nrG/w5T63hDEtI0OP AMDIveD7qJU04xWgmCRKgJrmkqjlovWtlZJEssE1LlXeiLoN7ZUm9c25M/AdZQLZXBGL bPWg== 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=IzUUI9iCtrldELUQXGq+i8oW5btYR02XjhPh0wrbZbY=; b=lmckuN6C5n6eIqCNugZqtIRJkVi/yf22+RsGGG1DQolOfWR43UweVwvt2o1moACwbD ny7RVaOg0FOARRKi72D9P/hnK2O+4ERM4iuKuaV0nbnv3NxNtzPNAClZ1MaMAGuyd8mW r05vHFJIzXV9jEv9UVToLv/Z5akrr1Hg2453DZ/kQRAP18c+z3HPScebKIAxavoAKUPS ZSWO+ErqZ7OpgGbCci2g7o3tthsBp9VRWcf7rIhQS/kzZuYcyHR74of8HMgFFgBVArPG 8ec+jog7tEmgek3wWQDmWzXvoH92YQ7XLoLuP8m6ABL1XNnzoXv/mWrcCe/IzSA2sph/ R8RQ== X-Gm-Message-State: APjAAAUphZz2/2o86OSEQIzcxg6wnWfKMrhTWZWUbRVVXnRJ2H356ECJ 7yhhvngEBs77I/5jN9qxtR4= X-Google-Smtp-Source: APXvYqyi0mZQrVxe0WCl1ALRUWIoCnwS3uNaiItjvLsQXyrLucoZxC5H97UCTPm8UpzWxfgR916JpA== X-Received: by 2002:a5d:4f88:: with SMTP id d8mr1169948wru.34.1557124390987; Sun, 05 May 2019 23:33:10 -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 z14sm1013021wrr.34.2019.05.05.23.33.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 May 2019 23:33:09 -0700 (PDT) To: John Cowan , Henry Andrews Cc: json@ietf.org, Austin Wright References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <20190505053921.GA21049@localhost> <20190505070023.GB21049@localhost> <56070772-de6f-2553-94c0-df75c08b4c80@gmail.com> <20190505163626.GC21049@localhost> From: Anders Rundgren Message-ID: <11a605da-0181-a3db-d6f0-e71eb1c1db61@gmail.com> Date: Mon, 6 May 2019 08:33:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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 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, 06 May 2019 06:33:14 -0000 On 2019-05-05 19:05, John Cowan wrote: > The Scheme language makes very clear distinctions here.  Integers are a subset of rational numbers, which are a subset of real numbers, which are a subset of complex numbers, and there are predicates for detecting any of them (normally `complex?` is the same as `number?`, but if you want to add quaternions you can). > > Orthogonal to this, there are exact and inexact numbers: a numeric literal can be explicitly marked as either one, but the default is that a number with a decimal point or exponent is inexact, and without either it is exact.  Mixed exactness operations produce inexact results unless the implementation can prove that the inexactness can't matter: the product of 5.0 (inexact) and 0 (exact) can be either exact or inexact. > That's the theory. In practice, using the most widely deployed JSON parser there is (ECMAScript's JSON.parse()), an exact JSON Number like 555555555555555555555555555555 is truncated to 5.555555555555555e+29. To cope with this, lots of JSON users (as well as IETF standards like RFC7515) have since years back rather turned to a JSON subset sometimes referred to as I-JSON (RFC 7493). Using I-JSON, numbers that cannot be reliably represented by IEEE-754 double precision are serialized as JSON Strings [1]. This permits hassle-free, cross-platform JSON messaging. https://tools.ietf.org/html/draft-handrews-json-schema-01 and "its partner in crime" the Open API does not take this in consideration. Thanx, Anders 1] There's actually quite a bunch of established String-serialized formats for BigIntegers out there including Decimal, Base64, Base64Url, and Hexadecimal. From nobody Sun May 5 23:57:23 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 68C0F12003E for ; Sun, 5 May 2019 23:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net 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 gfWM1HDVFXdb for ; Sun, 5 May 2019 23:57:19 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 9E30A1200B8 for ; Sun, 5 May 2019 23:57:19 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id ck18so5891715plb.1 for ; Sun, 05 May 2019 23:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/Jof7VsSDbE/i+I8F3RWjzNzm1d0j9JcEYkPPfAnQrc=; b=ArM6PjfQGDCQKGl2H7bQGYwoxT74GvJsBmsHjlBW/Z8OO4brLU8d9ih5WGJ/l24PT9 0QE6O0G/2qIwTg2TsPYDrax4Q0JCkuoTEfG6Qhga08YI+EV6b4+2R1HRDKEL/G44on1j 76FJrgAp7KkeG6zkUITs3QRQas3Cq21VDn/DA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/Jof7VsSDbE/i+I8F3RWjzNzm1d0j9JcEYkPPfAnQrc=; b=ZmS633z2O5ZXGAfQ8+5rJwUmCSlD8ECHHSSRvQumqrcqDgRlmND5iLkmUKrhTgU+LD bR5/8IV3xoFlwzyLLmvErxscrL6e3ZacF1eEYMHwJtG6x52L4XkjAQGDInHGp8Mjm44/ 1vxe8hdp4Jcko2NB8v9iiofswUM5lAiDX0WiIKAf0cNc3jEjXaI0MQaHRX5dyyopf6FR TUBqpCGGTMIGHzYPoicW8Q436sKvGmcKiv8I4FNKOMg8N28CxzV8NhUxW2jM97pGaYjV 4d18B32KsOU06BZmGrGzqBGcpX7CR9KzPtW5R9troBjLE0POTANknPsutXDalpx7VDrr lzlA== X-Gm-Message-State: APjAAAXXlnBqLas5dV64jgxshVl3KGWvDwh4V0N+HuFJQ/9xemkTblXp aVxGxnx4ONs4VbC4MBVBKZD72A== X-Google-Smtp-Source: APXvYqz/z0n5UKW37F35lT7ofn+lNXZb8wIZKMBmwd+9ij1+sT9To6SSZ2sSPXlg8pa5pYFUDSREPg== X-Received: by 2002:a17:902:b10c:: with SMTP id q12mr31068937plr.254.1557125838945; Sun, 05 May 2019 23:57:18 -0700 (PDT) Received: from [192.168.0.116] ([184.101.46.90]) by smtp.gmail.com with ESMTPSA id u5sm11473843pfm.121.2019.05.05.23.57.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 May 2019 23:57:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Austin Wright In-Reply-To: Date: Sun, 5 May 2019 23:56:56 -0700 Cc: json@ietf.org, Ulysse Carion , Anders Rundgren Content-Transfer-Encoding: quoted-printable Message-Id: <0AF01D27-E1A9-4D3B-8256-56859B998946@bzfx.net> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 06:57:21 -0000 > On May 4, 2019, at 22:56, Carsten Bormann wrote: >=20 > On May 5, 2019, at 04:51, Austin Wright wrote: >>=20 >>> On that web page, it also says =E2=80=9CFor consistency, integer = JSON numbers SHOULD NOT be encoded with a fractional part.=E2=80=9D >>>=20 >>> What does that mean? >>=20 >> It=E2=80=99s a non-normative suggestion >=20 > RFC 2119: >=20 > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. >=20 > Very much normative. This is an RFC 2119 interoperability keyword = because it creates an expectation in peers that they can mostly rely on = this behavior, except for exceptional circumstances (which, by the way, = should be spelled out with the SHOULD NOT). >=20 > I=E2=80=99m asking because we have a lot of experience with = specifications that purport to use a base standard but instead attempt = to create their own fork of that base standard by making mandates that = meddle with the functioning of that base standard. Not good. You=E2=80=99re right. I should add, it=E2=80=99s not _supposed_ to be = normative: it=E2=80=99s not our intention to modify how JSON works or = impose restrictions on encoders. I don=E2=80=99t think we can do that = even if we wanted to. Austin. From nobody Mon May 6 00:00:41 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 5811B120096 for ; Mon, 6 May 2019 00:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 2PNGmpeY1ns3 for ; Mon, 6 May 2019 00:00:37 -0700 (PDT) Received: from smtp.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 E4CB412003E for ; Mon, 6 May 2019 00:00:36 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44yDCP4F5qzyll; Mon, 6 May 2019 09:00:33 +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: <11a605da-0181-a3db-d6f0-e71eb1c1db61@gmail.com> Date: Mon, 6 May 2019 09:00:33 +0200 Cc: json@ietf.org X-Mao-Original-Outgoing-Id: 578818830.9411711-13f7834de2759515310c49036385b5d4 Content-Transfer-Encoding: quoted-printable Message-Id: <374C55B5-BDE6-41FD-AAD7-504FB18FDA8A@tzi.org> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <20190505053921.GA21049@localhost> <20190505070023.GB21049@localhost> <56070772-de6f-2553-94c0-df75c08b4c80@gmail.com> <20190505163626.GC21049@localhost> <11a605da-0181-a3db-d6f0-e71eb1c1db61@gmail.com> To: Anders Rundgren X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 07:00:39 -0000 On May 6, 2019, at 08:33, Anders Rundgren = wrote: >=20 > IETF standards like RFC7515) have since years back rather turned to a = JSON subset sometimes referred to as I-JSON (RFC 7493). I cannot find a reference to RFC 7493 in RFC 7515 (part of JOSE). JOSE does not care, because it signs representations (byte strings), not = data model level information. (JOSE does need ways to represent cryptographic information that may = contain numbers that might exceed implementation limits of JSON = decoders. So it represents them as text strings containing BASE64URL(*) = encoded byte strings representing big-endian unsigned integers. That = has nothing to do with I-JSON, or actually only with its = [incomplete(**)] suggestion to use base64url encoding for byte strings. = Section 2.2 of RFC 7493 does NOT say how to =E2=80=9Cencode [numbers] in = JSON string values=E2=80=9D.) Gr=C3=BC=C3=9Fe, Carsten (*) Where BASE64URL is defined as base64url without padding. (**) RFC 7493 fails to specify encoding without padding, which, when = read at face value, would mean WITH padding according to Section 5 of = RFC 4648. Of course, we know that this isn=E2=80=99t what is meant. From nobody Mon May 6 00:17:13 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 4A65C1200D5 for ; Mon, 6 May 2019 00:17:12 -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_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 nLaXmmIKVmIy for ; Mon, 6 May 2019 00:17:10 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 462D0120046 for ; Mon, 6 May 2019 00:17:10 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id c12so15821311wrt.8 for ; Mon, 06 May 2019 00:17:10 -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=RLJ7HQvnHrmjJL15019pgOmKOGdjsmu6pqaHkYyusTU=; b=KDjdnxahEnJB8MJi3/qURmf9BRd26ihYPc0tR56NUMGby3LqKwYL8xRZicsWdW3yPW 8xPwqH4wKGTIEAHhQMppdcg8l4an640AS7FBSPbQb6wx0jimMUD8YWlQt3Uz8aRZ2F5T S2tjJWArxqwycDAD2k/rXZCRMYqtPaYXXLLuBtK99Ta+dwnmvB094VOVQ14dHH7DiRnH DODogQaJrgXGkACAhjpI8qcQRQ0eNHzkTUHapZ8q2qluAKGi23TCteqW9Tf3SgnO7C8Q 3Qx2f6HHvbA+qAwkOJmVdyplYc77kz6MLmVAR0gVKU8HjtlIZjyLYeaMnWMIOnEEdxxw kXWg== 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=RLJ7HQvnHrmjJL15019pgOmKOGdjsmu6pqaHkYyusTU=; b=Mze/ZV8Mt2J0eHcOK0gW0OFYedQlNRa4tmPMb580iBASyjYrhhn5tINkEAHcqn2qKt jI3cddKmPSSQVBd+tAOPB+pI58whKedh31G8rJPOfPPIpdocZThUxcL6R6/eoG3UhctI aldQTbU3H4XCj3Lx4gFYKolMZUAmFM68+AKiyK8Ge375QQW0os5bNf2ui9Q8gUuukMY2 d9zC/ZSHaLMgxqMIz+PYoWfpEG0F3WEUDqisd0cyz8Ceo5IIAxMmkNu1WYy9KfK8dH41 vmlFz3NDAQKaJPjBcAygAkIW8kuT/gyiQK/CsuJZLDORzaxX+RwtcEf6oJeLoJEuunRm a70g== X-Gm-Message-State: APjAAAXwDihPpH6+XzIowwm0QsC3zhk6zvucn2EqMvSpPf3r2SXYezRb NNJWjnpdall4c99jVs7jBo0nsWkm9tE= X-Google-Smtp-Source: APXvYqzP6MM/e/Myv0Md8Jn0RFcHgWHBcxFJSKiGDkkP6yFIiO7PUmdgb5GN7/sq3fkijqSTCSlVNA== X-Received: by 2002:a5d:4712:: with SMTP id y18mr16098327wrq.23.1557127028745; Mon, 06 May 2019 00:17:08 -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 19sm2017966wmf.44.2019.05.06.00.17.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 May 2019 00:17:07 -0700 (PDT) To: Carsten Bormann Cc: json@ietf.org, Austin Wright References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <20190505053921.GA21049@localhost> <20190505070023.GB21049@localhost> <56070772-de6f-2553-94c0-df75c08b4c80@gmail.com> <20190505163626.GC21049@localhost> <11a605da-0181-a3db-d6f0-e71eb1c1db61@gmail.com> <374C55B5-BDE6-41FD-AAD7-504FB18FDA8A@tzi.org> From: Anders Rundgren Message-ID: Date: Mon, 6 May 2019 09:17:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <374C55B5-BDE6-41FD-AAD7-504FB18FDA8A@tzi.org> 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 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, 06 May 2019 07:17:12 -0000 All I'm saying is that https://tools.ietf.org/html/draft-handrews-json-schema-01 doesn't support alternative number serialization schemes like featured in: https://tools.ietf.org/html/rfc7518#section-6.3.1 It also doesn't deal with common numeric data types like ubyte, int32, uint64, float, double, BigInt etc. etc. XML Schema shows that there is no problem having such definitions in a schema. I leave it at there: https://github.com/json-schema-org/json-schema-spec/issues/736 Anders On 2019-05-06 09:00, Carsten Bormann wrote: > On May 6, 2019, at 08:33, Anders Rundgren wrote: >> >> IETF standards like RFC7515) have since years back rather turned to a JSON subset sometimes referred to as I-JSON (RFC 7493). > > I cannot find a reference to RFC 7493 in RFC 7515 (part of JOSE). > JOSE does not care, because it signs representations (byte strings), not data model level information. > > (JOSE does need ways to represent cryptographic information that may contain numbers that might exceed implementation limits of JSON decoders. So it represents them as text strings containing BASE64URL(*) encoded byte strings representing big-endian unsigned integers. That has nothing to do with I-JSON, or actually only with its [incomplete(**)] suggestion to use base64url encoding for byte strings. Section 2.2 of RFC 7493 does NOT say how to “encode [numbers] in JSON string values”.) > > Grüße, Carsten > > (*) Where BASE64URL is defined as base64url without padding. > (**) RFC 7493 fails to specify encoding without padding, which, when read at face value, would mean WITH padding according to Section 5 of RFC 4648. > Of course, we know that this isn’t what is meant. > From nobody Mon May 6 00:22: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 34C9A1200D5 for ; Mon, 6 May 2019 00:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xChEo99v1ToH for ; Mon, 6 May 2019 00:22:16 -0700 (PDT) Received: from smtp.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 5F080120046 for ; Mon, 6 May 2019 00:22:16 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44yDhQ1P5bz10DD; Mon, 6 May 2019 09:22:14 +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: <0AF01D27-E1A9-4D3B-8256-56859B998946@bzfx.net> Date: Mon, 6 May 2019 09:22:13 +0200 Cc: json@ietf.org X-Mao-Original-Outgoing-Id: 578820131.549468-4cbc2bf8f0f4cacedf613f78469c3532 Content-Transfer-Encoding: quoted-printable Message-Id: <011D66CC-C13C-45BF-A0D4-00F768252911@tzi.org> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> <0AF01D27-E1A9-4D3B-8256-56859B998946@bzfx.net> To: Austin Wright X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 07:22:18 -0000 On May 6, 2019, at 08:56, Austin Wright wrote: >=20 > You=E2=80=99re right. I should add, it=E2=80=99s not _supposed_ to be = normative: it=E2=80=99s not our intention to modify how JSON works or = impose restrictions on encoders.=20 Good. So consider my comment a comment on the specific language that is = on that website. > I don=E2=80=99t think we can do that even if we wanted to. Well, there are several definitions of =E2=80=9Ccan=E2=80=9D. By creating the expectation that 10.0 will be encoded as 10 in the = vicinity of your schema data objects, you =E2=80=9Care=E2=80=9D, even if = you =E2=80=9Cshould not be able to=E2=80=9D. If there is an = interoperability problem between an encoder that encodes as 10.0 and a = decoder that only can handle 10, the implementer of the latter might = point to your website and say =E2=80=9Cworks as intended, because you = are not supposed to=E2=80=9D. There is your fork. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 6 00:23:12 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 EAB01120046 for ; Mon, 6 May 2019 00:23:10 -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_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=bzfx.net 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 f9ZcUrjHaGvn for ; Mon, 6 May 2019 00:23:08 -0700 (PDT) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 4A3E21200D5 for ; Mon, 6 May 2019 00:23:08 -0700 (PDT) Received: by mail-pg1-x543.google.com with SMTP id i21so6008682pgi.12 for ; Mon, 06 May 2019 00:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9dS3LLaJt+UNQUcJQ4y+k+pbJN9rIYBVWFwXmWrzCbw=; b=NfZ8QORDJf8PV5KugOCG8mQGZoKgG5Pv5+3wG1TK2c7B0KgRjziv3Mii3GDfnZlb2c ld1kizg61dTxIO65zdQFFCDrMNsuAAmzxumqmchGPE7QKI9A37GfA9BYwIaXu9dsHXEg nG4LbG4sL8/+qnh1rA770IwNvD8X6twQfMWdI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9dS3LLaJt+UNQUcJQ4y+k+pbJN9rIYBVWFwXmWrzCbw=; b=Lts3yL2rpph/qGYg9EvzaMcfey7GMJU738PlH4njT3z99lJyVeC9ZQgO0UK6jnwiCD 3fDswYqZZDjLq+/kyBKXCFEvn22H7GqYPQsmHRJEfWKIFv2b8LIR59bKB0Kh5rF/pIiI eeSzvsLKakLy16bUIZGV6gBgvj6hdo0Rf+7pIx30aMX1EB1eEN058lw6OmAEjJU9nycg w2boUDMbbHpI22kbH6N9aigNLwpyEJ6kQYdOub1/fxGr4EyuU5myCa1i1VYP9oYybsq8 YryIK6Z2OgtZvQ8yJOR6AYpSot3jAqi2P0h9zBVRIGGHt3JE32iur8qpprixi+1z+bCl Rw9A== X-Gm-Message-State: APjAAAVc1BorQ1sBL4ES9roTOCxwZ0ynQ/XPeDrcf8hBnx+1NwbSHgZA zs2eQa8Km1t7BKP51M9E1V1nUw== X-Google-Smtp-Source: APXvYqyfd7MJaFzHLCJgTA+qSTTxXEpVk9bfO8J2/2qOJgL8c0sfQpYOei47HqclHOOi6DG+6osxiw== X-Received: by 2002:a63:161d:: with SMTP id w29mr30677700pgl.395.1557127387682; Mon, 06 May 2019 00:23:07 -0700 (PDT) Received: from [192.168.0.116] ([184.101.46.90]) by smtp.gmail.com with ESMTPSA id i15sm8772836pfj.167.2019.05.06.00.23.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 May 2019 00:23:07 -0700 (PDT) From: Austin Wright Message-Id: <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_5C673D6C-1380-4479-AA66-B3B312D5B2F5" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 6 May 2019 00:22:45 -0700 In-Reply-To: <6260354b-aca2-e001-7145-148b32658416@gmail.com> Cc: Carsten Bormann , json@ietf.org, Ulysse Carion To: Anders Rundgren References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> <6260354b-aca2-e001-7145-148b32658416@gmail.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 07:23:11 -0000 --Apple-Mail=_5C673D6C-1380-4479-AA66-B3B312D5B2F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 4, 2019, at 23:49, Anders Rundgren = wrote: >=20 > On 2019-05-05 08:16, Austin Wright wrote: >>> On May 4, 2019, at 22:07, Anders Rundgren = wrote: >>>=20 >>> On 2019-05-05 04:51, Austin Wright wrote: >>>>> On May 4, 2019, at 02:42, Carsten Bormann wrote: >>>>>=20 >>>>> Curious: >>>>>=20 >>>>> On that web page, it also says =E2=80=9CFor consistency, integer = JSON numbers SHOULD NOT be encoded with a fractional part.=E2=80=9D >>>>>=20 >>>>> What does that mean? >>>> It=E2=80=99s a non-normative suggestion with the aim of enhancing = performance: Many programming languages distinguish between integers and = IEEE floats by the presence of a decimal point. While JSON makes no such = distinction (all numbers are arbitrary precision decimal), some parsers = do make that distinction, and it=E2=80=99s slightly easier to determine = if an int32_t is an integer than if a double is an integer. >>>=20 >>> in the C# example I provided before this is (by default) not = non-normative, since it threw an exception. Here is a little bit more = detail: >>>=20 >>> class MyObject { >>> int Counter; >>> . >>> . >>> } >>>=20 >>> Deserializing JSON into this type (which BTW works as as "schema"), = REQUIRES "Counter" data to adhere to normal integer notation, including = value span. >>>=20 >>> A scheme language should align with the actual use and = interpretation of JSON. This involves alternative serialization formats = as well. As an example monetary values are (probably without = exceptions) expressed as JSON Strings since floating point is unsuited = for decimal arithmetic. >>>=20 >>> Based on the RFC, one might come to the conclusion that JSON is an = inferior information transfer format, but aided by external mapping it = actually works extremely well, albeit being slightly verbose :) >> The Newtonsoft.Json parser behavior would be incompatible with JSON = Schema, according to what you provided. But I can=E2=80=99t imagine = it=E2=80=99s much of an issue: If the encoder knows the value will = always be an integer, why add a fractional part? >=20 > Right, my guess is that not a single mainstream serializer adds a = fractional part to a number that can be exactly represented as an = integer regardless if they underlying number type is an integer or not. >=20 >=20 >> That behavior still seems arbitrary to me, though. Instead of = erroring on the first period, all you have to do is error on the first = nonzero after the period. Scientific notation is another matter, but = presumably it allows 1.9e4 as a valid integer? (I=E2=80=99m not sure, = off-hand.) >=20 > To me the whole idea of having a scheme is to create a *clean* = description of an object. Predecessors like XML Schema supported this = in (IMO) a pretty good way. However, this was straightforward since XML = doesn't come with a built-in data model. >=20 > JSON was derived from JavaScript (anno 2003 or so) which didn't have = an explicit integer type, only an unconstrained Number type. This = obviously creates certain issues when communicating with platforms = having a completely different handling of numeric data. The new = proposal doesn't take this is consideration. >=20 >=20 >> Probably a better way to approach JSON parsers is to raise an error = if it can=E2=80=99t preserve all the information in the source. For = example, you can preserve 1e10, 0.5, and even 0.1 (if you permit a small = error, such that if you converted the float back to decimal, 0.1 would = still be the closest decimal representation). But you can=E2=80=99t = preserve 9007199254740993.5 as a double: it=E2=80=99s too many = significant figures, and above that value, the precision is below 1. In = this case, you would throw. >=20 > A schema should not try to change how parsers work. >=20 >=20 >> Parsers that ensure the preservation of the encoded data like this = might encourage better use of the JSON types, like for monetary values, = even if you are reading into an IEEE floating point. >=20 > See previous point. Can you elaborate on this? My point is primarily concerned with JSON = parsers, not JSON the media type. Suppose a string were too large to store in memory, most ECMAScript = engines would bail with an uncatchable error. The suggestion is to = implement this more robustly, like throw an error if a string would be = too long, or if a number has too many significant figures; instead of = either crashing or silently approximating the number. But also, why not build a parser that uses a schema to influence how = values are parsed? Suppose you have a dynamically typed language, and = want to parse some value, e.g. sometimes as an int, sometimes as a = bignum, depending on the property. You might provide a JSON Schema to = specify this behavior. >> Still, now that we bring it up, that SHOULD NOT seems suspicious. = It=E2=80=99s stating the obvious. >> Austin. >>>=20 >>> Cheers, >>> Anders >>>=20 >>>> Cheers, >>>> Austin. >>>>>=20 >>>>> Gr=C3=BC=C3=9Fe, Carsten >>>>>=20 >>>>>=20 >>>>>> On May 4, 2019, at 11:36, Austin Wright wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On May 4, 2019, at 00:58, Carsten Bormann wrote: >>>>>>>=20 >>>>>>> On May 4, 2019, at 06:47, Anders Rundgren = wrote: >>>>>>>>=20 >>>>>>>> Example: although 10.0 is a valid JSON Number, in system where = you expect >>>>>>>> an integer, this should be flagged as a syntax error. >>>>>>>=20 >>>>>>> 10.0 is an integer number. >>>>>>>=20 >>>>>>> =E2=80=9CSchema Languages=E2=80=9D operate at the data model = level. In the JSON data model, there is only one kind of number. >>>>>>> Of course, the JSON data model is not actually defined in a = standard, which is one of the major shortcomings of JSON. >>>>>>>=20 >>>>>>=20 >>>>>> JSON Schema handles this exactly the same way, defining a data = model [1]. The lexical representation is surjective onto the data model: = as you point out, 10.0 is the same as 10, which is an integer. >>>>>>=20 >>>>>> The one case where this might fall apart is if significant digits = are important, such that 10.0 is different than 10.00 (i.e., 10.00 is = more precise by an order of magnitude). However, I=E2=80=99m not aware = of any JSON parsers that keep track of the precision of numbers, even = ones that support arbitrary precision. I imagine scientific applications = would want to store an explicit precision, since they=E2=80=99re not = always powers-of-10 (e.g. {value: 32.0, precision: 0.5}). >>>>>>=20 >>>>>> [1] = http://json-schema.org/latest/json-schema-core.html#rfc.section.4.2.1 = "4.2.1. Instance Data Model" >>>>>>=20 >>>>>> Austin. --Apple-Mail=_5C673D6C-1380-4479-AA66-B3B312D5B2F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 4, 2019, at 23:49, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

On 2019-05-05 08:16, Austin = Wright wrote:
On May 4, 2019, at = 22:07, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

On 2019-05-05 04:51, Austin Wright wrote:
On May 4, 2019, at 02:42, Carsten Bormann <cabo@tzi.org> wrote:

Curious:

On that = web page, it also says =E2=80=9CFor consistency, integer JSON numbers = SHOULD NOT be encoded with a fractional part.=E2=80=9D

What does that mean?
It=E2=80=99s = a non-normative suggestion with the aim of enhancing performance: Many = programming languages distinguish between integers and IEEE floats by = the presence of a decimal point. While JSON makes no such distinction = (all numbers are arbitrary precision decimal), some parsers do make that = distinction, and it=E2=80=99s slightly easier to determine if an int32_t = is an integer than if a double is an integer.

in the C# example I provided = before this is (by default) not non-normative, since it threw an = exception.   Here is a little bit more detail:
class MyObject {
 int Counter;
  .
  .
}

Deserializing JSON into this type (which BTW = works as as "schema"), REQUIRES "Counter" data to adhere to normal = integer notation, including value span.

A = scheme language should align with the actual use and interpretation of = JSON.  This involves alternative serialization formats as well. =  As an example monetary values are (probably without exceptions) = expressed as JSON Strings since floating point is unsuited for decimal = arithmetic.

Based on the RFC, one might = come to the conclusion that JSON is an inferior information transfer = format, but aided by external mapping it actually works extremely well, = albeit being slightly verbose :)
The = Newtonsoft.Json parser behavior would be incompatible with JSON Schema, = according to what you provided. But I can=E2=80=99t imagine it=E2=80=99s = much of an issue: If the encoder knows the value will always be an = integer, why add a fractional part?

Right, my guess is that not a = single mainstream serializer adds a fractional part to a number that can = be exactly represented as an integer regardless if they underlying = number type is an integer or not.


That behavior still seems arbitrary = to me, though. Instead of erroring on the first period, all you have to = do is error on the first nonzero after the period. Scientific notation = is another matter, but presumably it allows 1.9e4 as a valid integer? = (I=E2=80=99m not sure, off-hand.)

To me the whole idea of having a = scheme is to create a *clean* description of an object. =  Predecessors like XML Schema supported this in (IMO) a pretty good = way.  However, this was straightforward since XML doesn't come with = a built-in data model.

JSON was derived from JavaScript (anno 2003 or so) which = didn't have an explicit integer type, only an unconstrained Number type. =  This obviously creates certain issues when communicating with = platforms having a completely different handling of numeric data. =  The new proposal doesn't take this is consideration.


Probably a better way to approach JSON parsers is to raise an = error if it can=E2=80=99t preserve all the information in the source. = For example, you can preserve 1e10, 0.5, and even 0.1 (if you permit a = small error, such that if you converted the float back to decimal, 0.1 = would still be the closest decimal representation). But you can=E2=80=99t = preserve 9007199254740993.5 as a double: it=E2=80=99s too many = significant figures, and above that value, the precision is below 1. In = this case, you would throw.

A schema should not try to = change how parsers work.


Parsers that ensure the preservation = of the encoded data like this might encourage better use of the JSON = types, like for monetary values, even if you are reading into an IEEE = floating point.

See previous point.

Can you elaborate on this? My point is primarily = concerned with JSON parsers, not JSON the media type.

Suppose a string were too large to store in = memory, most ECMAScript engines would bail with an uncatchable error. = The suggestion is to implement this more robustly, like throw an error = if a string would be too long, or if a number has too many significant = figures; instead of either crashing or silently approximating the = number.

But also, why not build a = parser that uses a schema to influence how values are parsed? Suppose = you have a dynamically typed language, and want to parse some value, = e.g. sometimes as an int, sometimes as a bignum, depending on the = property. You might provide a JSON Schema to specify this = behavior.

Still, = now that we bring it up, that SHOULD NOT seems suspicious. It=E2=80=99s = stating the obvious.
Austin.

Cheers,
Anders

Cheers,
Austin.

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


On May 4, 2019, at = 11:36, Austin Wright <aaa@bzfx.net> wrote:



On May 4, = 2019, at 00:58, Carsten Bormann <cabo@tzi.org> wrote:

On = May 4, 2019, at 06:47, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

Example: = although 10.0 is a valid JSON Number, in system where you expect
an integer, this should be flagged as a syntax error.

10.0 is an integer number.

=E2=80=9CSchema Languages=E2=80=9D operate at = the data model level.  In the JSON data model, there is only one = kind of number.
Of course, the JSON data model is not = actually defined in a standard, which is one of the major shortcomings = of JSON.


JSON = Schema handles this exactly the same way, defining a data model [1]. The = lexical representation is surjective onto the data model: as you point = out, 10.0 is the same as 10, which is an integer.

The one case where this might fall apart is if significant = digits are important, such that 10.0 is different than 10.00 (i.e., = 10.00 is more precise by an order of magnitude). However, I=E2=80=99m = not aware of any JSON parsers that keep track of the precision of = numbers, even ones that support arbitrary precision. I imagine = scientific applications would want to store an explicit precision, since = they=E2=80=99re not always powers-of-10 (e.g. {value: 32.0, precision: = 0.5}).

[1] http://json-schema.org/latest/json-schema-core.html#rfc.section= .4.2.1 "4.2.1. Instance Data Model"

Austin.

= --Apple-Mail=_5C673D6C-1380-4479-AA66-B3B312D5B2F5-- From nobody Mon May 6 00:32: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 41B5C1200FA for ; Mon, 6 May 2019 00:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6SJqVBgQHq3W for ; Mon, 6 May 2019 00:32:16 -0700 (PDT) Received: from smtp.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 7DBE7120049 for ; Mon, 6 May 2019 00:32:16 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44yDvx5LGszyX8; Mon, 6 May 2019 09:32: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: <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> Date: Mon, 6 May 2019 09:32:13 +0200 Cc: json@ietf.org X-Mao-Original-Outgoing-Id: 578820731.222464-e39f262434e4c52938a0a0f6b7e99ac7 Content-Transfer-Encoding: quoted-printable Message-Id: <751DAC92-D70C-4C5E-9C61-954D6E300A1F@tzi.org> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> <6260354b-aca2-e001-7145-148b32658416@gmail.com> <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> To: Austin Wright X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 07:32:18 -0000 On May 6, 2019, at 09:22, Austin Wright wrote: >=20 > But also, why not build a parser that uses a schema to influence how = values are parsed? That is exactly what most of the members of this WG are afraid of when = the talk comes to =E2=80=9Cschemas=E2=80=9D. XML (and later JSON) learned one thing from the problems of SGML: = schema-oblivious decoders are more robust than schema-depending ones. (They are, in the first place, and protocol evolution only amplifies = this.) > Suppose you have a dynamically typed language, and want to parse some = value, e.g. sometimes as an int, sometimes as a bignum, depending on the = property. You might provide a JSON Schema to specify this behavior. There goes the generic decoder. (There is nothing wrong with using a =E2=80=9Cschema=E2=80=9D to specify = upconversion from the JSON data model to your application data model. = What I=E2=80=99m objecting to is getting rid of JSON and replacing it = with a gazillion dialects that happen to be syntactically compatible = with JSON but the semantics of which are controlled by a =E2=80=9Cschema=E2= =80=9D mechanism.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon May 6 01:56:06 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 15EAD12011D for ; Mon, 6 May 2019 01:56:05 -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, 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 oym1yh88ww4R for ; Mon, 6 May 2019 01:56:03 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 767D912006F for ; Mon, 6 May 2019 01:56:03 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id f2so9257378wmj.3 for ; Mon, 06 May 2019 01:56:03 -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=Ml12/he804s/4XTnFwZhua9u8V+tA6rCq0oViorCiMc=; b=TkjnuQFK/f242WH0isE3QYgBJD/rkvLRjjriGiueAwyLaEr8ekUP9vGtjc6mlv3umA 0ARkUiWt8h9pNmlPTp7jWL1eMQm+GBXOz+VqDbR1ZfqxpPxFluiFcaeVGq709BQTkljz 9EX4CcXR61NxjrMNmx8QC9hJ3pcRHfVREvEbKrjn3yWNxzqyrYNpk5T9JxDRCFq+iyUA C2hfjLKEM67L16icLOlBL4G9cY0QhoH4ISgl8+NWPlGqjui3rsNBbt4KY97igyWAOyMo AxpGd+VZH3aaNWgSKWbzZQx7b/NsVK17XPv2eypKgjKnBcfYr2nPbySue0CGv5WRCK5R u03A== 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=Ml12/he804s/4XTnFwZhua9u8V+tA6rCq0oViorCiMc=; b=YVwfGyS+afpcOCd1XX6gA4aCETDql9qCm6kbWJinRIxYk03PMZyzL5s5MevioOphNl oFOO9GpW9x4kPrDn9V0DMIjXaLzcnQqxVYnY8fsaBDWmyQinFKUTqc6XHvTXb+pJRsLD ES4nxPYn5C7fbwRGJjorSjho8lfXjjtMzS0quH/WBxhGIDyVjQ1ZqUFRTnvQpQ+avNNT ye4TMQhG8idhYpZq8zHags7m+ZP/BYzwlCyCUjmYuOFDlvk7IIkoQTbfplXB+6RfrkhV 7rbF2gXiJQ/mo3cdkOc/FrcEMRAuuCdL2vbkhsW3EqLwMWERU9qPcS70Tfn5ZILQlA+6 Dl5Q== X-Gm-Message-State: APjAAAUrLMZXCyzMZ473Q+CMj/rXW2LsProCS6a1gQl1JjUSw+nKhQ3Q GayEC4RvghVFq1M8ZaHDfuo= X-Google-Smtp-Source: APXvYqxPtMU/nuZAklZQ4FEuhwyEGSah2/IO0Xs2XqGebae3HneMkbg12cxn9WHegHuWAfnyzyguWA== X-Received: by 2002:a1c:c183:: with SMTP id r125mr14810058wmf.57.1557132961878; Mon, 06 May 2019 01:56:01 -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 b10sm20421444wme.25.2019.05.06.01.56.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 May 2019 01:56:00 -0700 (PDT) To: Austin Wright Cc: json@ietf.org, Ulysse Carion References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> <6260354b-aca2-e001-7145-148b32658416@gmail.com> <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> From: Anders Rundgren Message-ID: <3a438654-b1ef-ecbd-0fb2-937d8f40f0c9@gmail.com> Date: Mon, 6 May 2019 10:55:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> 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 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, 06 May 2019 08:56:05 -0000 On 2019-05-06 09:22, Austin Wright wrote: > > Can you elaborate on this? My point is primarily concerned with JSON parsers, not JSON the media type. > > Suppose a string were too large to store in memory, most ECMAScript engines would bail with an uncatchable error. The suggestion is to implement this more robustly, like throw an error if a string would be too long, or if a number has too many significant figures; instead of either crashing or silently approximating the number. I don't understand this. A JSON schema is a description of a JSON document. If the description is incompatible with implementations that are supposed to parse compliant documents all bets are off. > But also, why not build a parser that uses a schema to influence how values are parsed? Suppose you have a dynamically typed language, and want to parse some value, e.g. sometimes as an int, sometimes as a bignum, depending on the property. You might provide a JSON Schema to specify this behavior. This sounds like an edge-case but it could be supported by an "any" type (although don't particularly see how this could work in a cross-platform scenario). I would rather consider looking into more down-to-earth requirements such as supporting common numeric types and dealing with alternative already widely deployed serialization options for those. https://github.com/json-schema-org/json-schema-spec/issues/736 Anders From nobody Mon May 6 07:10:12 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 A0A63120052 for ; Mon, 6 May 2019 07:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 hzWdOjoTChQ3 for ; Mon, 6 May 2019 07:10:09 -0700 (PDT) Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) (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 A596F12011E for ; Mon, 6 May 2019 07:10:09 -0700 (PDT) Received: by mail-ot1-f67.google.com with SMTP id o39so11541748ota.6 for ; Mon, 06 May 2019 07:10:09 -0700 (PDT) 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=xVakA1Ylwcle9uSUq+voNWQ8PajMCQoNek+wYPkNnyM=; b=bkdyQJnnIFPkf9jPff8U1pyI++nai0ZK+8mhQ+Er2Snefod6CQWsfvldOjXTj4HHVY xX4I8gveAB7Ll2i9jnepH8B1sA2xAzSG40LP0HTbrmOkq8ITIT48K7z1MHANOJKENK9Y WmDo9UkOYToQ8LidIJaIWcrjDkdBQC89MudCUkwPTHIrTnO5MYh4jVR3+839cjVtyg28 n6WEIbJaXeMdG94uty97Bo1PJ5+mA6sGM5tZ5fuOBSKOoc7CTwu1XZXbffgyYqG+vQs3 2bjVZY3MR6TmgZ7P+f+oNwCzpdRSV5nWZl3kFyykp3IF0fkl6TkRpAHMK2NL57bmacKA 6m8A== X-Gm-Message-State: APjAAAV5j24VzUDvwVTghnCCqzFI8uEBEVLPFKvNIBlx9YOM9Qco1rWT dDhmYDHJMZcdDK70uRJBQ+zMxF0MVRU9orlnV0E= X-Google-Smtp-Source: APXvYqzTu7aN+wVJ1UnLpXJxVWoOEkMi8nM0bGlGFulTyUJeTFTppxaKddRI3IM3WT3zIyBlSkpw5K9ARXFjzSsh0n0= X-Received: by 2002:a9d:6d93:: with SMTP id x19mr6735898otp.157.1557151808769; Mon, 06 May 2019 07:10:08 -0700 (PDT) MIME-Version: 1.0 References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> <6260354b-aca2-e001-7145-148b32658416@gmail.com> <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> <3a438654-b1ef-ecbd-0fb2-937d8f40f0c9@gmail.com> In-Reply-To: <3a438654-b1ef-ecbd-0fb2-937d8f40f0c9@gmail.com> From: Phillip Hallam-Baker Date: Mon, 6 May 2019 10:09:58 -0400 Message-ID: To: Anders Rundgren Cc: Austin Wright , Ulysse Carion , JSON WG Content-Type: multipart/alternative; boundary="0000000000006c530b058838a8b3" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 14:10:12 -0000 --0000000000006c530b058838a8b3 Content-Type: text/plain; charset="UTF-8" Lets back up here a moment. JSON is actually more than one thing. It is: * A data model * A lexical token specification * A serialization For the Mesh I take the JSON data model and extend it to distinguish integers from floats and binary encoded blobs from strings via base64url encoding. I also extend the lexical token specification so that I do not have to base64 encode binary data blobs. Which is the chief barrier to use of JSON for crypto. I am writing my own serializer/deserializer and my own lexical token analyzer. But that part is really not well grounded in JSON tooling as it exists in the wild (yet). The aim of JSON-B/C is to be plug-compatible with JSON so that it is possible to take an existing encoding and just drop in a JSON-B handler. Looking at the JSON tools out there, I see that most of them simply take the input stream and turn it into a parse tree that supports search path type accessors. That is not the approach I like but it is what folk working in scripting languages usually want. >From an interop point of view, any application that relies on being able to round trip integers that exceed the IEEE float mantissa capacity is going to break. That is just a fact of life. Another fact is that I have never found a use for a float in any protocol specification. Serializations and encodings are important. But there is no point in making a fetish of finding the one true encoding. The Mesh uses JSON/JSON-B for all its native encodings. But the Mesh tools have handling for ASN.1, RFC821, RFC822, TLS and will soon have to add iCal/vCard because they are all needed in the wild. I think a JSON schema is a mistake at this point. We should look at writing a general schema language that is a good schema language and has the ability to specify ASN.1 or XML schemas or anything else that might need to be specified. The world is focusing on JSON for a reason but I think it is the JSON data model we are actually focusing on rather than the JSON serialization. And I don't think that insisting that nobody ever touch the original perfection of JSON encoding is helpful either. All that is doing is ensuring that instead of there being one JSON/2.0 there are dozens and more are being added all the time. --0000000000006c530b058838a8b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Let= s back up here a moment.

= JSON is actually more than one thing. It is:

* A data model
* A lexical token specification
* A serialization

For the Mesh I take the JSON data model and = extend it to distinguish integers from floats and binary encoded blobs from= strings via base64url encoding. I also extend the lexical token specificat= ion so that I do not have to base64 encode binary data blobs. Which is the = chief barrier to use of JSON for crypto.

I am writing my own serializer/deserializer and my own lexi= cal token analyzer. But that part is really not well grounded in JSON tooli= ng as it exists in the wild (yet). The aim of JSON-B/C is to be plug-compat= ible with JSON so that it is possible to take an existing encoding and just= drop in a JSON-B handler.

Looking at the JSON tools out there, I see that most of them simply take = the input stream and turn it into a parse tree that supports search path ty= pe accessors. That is not the approach I like but it is what folk working i= n scripting languages usually want.

From an interop point of view, any application that relies on be= ing able to round trip integers that exceed the IEEE float mantissa capacit= y is going to break. That is just a fact of life. Another fact is that I ha= ve never found a use for a float in any protocol specification.


Serializations and encodings are important. Bu= t there is no point in making a fetish of finding the one true encoding. Th= e Mesh uses JSON/JSON-B for all its native encodings. But the Mesh tools ha= ve handling for ASN.1, RFC821, RFC822, TLS and will soon have to add iCal/v= Card because they are all needed in the wild.

I think a JSON schema is a mistake at this point. We s= hould look at writing a general schema language that is a good schema langu= age and has the ability to specify ASN.1 or XML schemas or anything else th= at might need to be specified.

The world is focusing on JSON for a reason but I think it is the JSON= data model we are actually focusing on rather than the JSON serialization.= And I don't think that insisting that nobody ever touch the original p= erfection of JSON encoding is helpful either. All that is doing is ensuring= that instead of there being one JSON/2.0 there are dozens and more are bei= ng added all the time.
--0000000000006c530b058838a8b3-- From nobody Mon May 6 10:02:12 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 B3CBF120188 for ; Mon, 6 May 2019 10:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=cryptonector.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 upsf1PNMoq7Z for ; Mon, 6 May 2019 10:02:08 -0700 (PDT) Received: from cichlid.maple.relay.mailchannels.net (cichlid.maple.relay.mailchannels.net [23.83.214.36]) (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 86274120071 for ; Mon, 6 May 2019 10:02:08 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7621C142B26; Mon, 6 May 2019 17:02:07 +0000 (UTC) Received: from pdx1-sub0-mail-a48.g.dreamhost.com (100-96-79-6.trex.outbound.svc.cluster.local [100.96.79.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D3606142A85; Mon, 6 May 2019 17:02:06 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a48.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 06 May 2019 17:02:07 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Spicy-Snatch: 509e0e357d315fbb_1557162127323_236342131 X-MC-Loop-Signature: 1557162127323:2701885521 X-MC-Ingress-Time: 1557162127322 Received: from pdx1-sub0-mail-a48.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a48.g.dreamhost.com (Postfix) with ESMTP id 7A70781F4F; Mon, 6 May 2019 10:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=XBjqb7lyJ2z4Uo 1SYGogB7Gz+G4=; b=BEIahbBbCfVtmDzM+n4+FcWm3n3MpQt81CXRUZ4/iE1sAT EG6DV5sH7F+UGXBVhwKK37rnVAm+pQwLp+R63ZzVm/rryiwLBpnCSkrxglzFS7fQ aoIEPdoOtm3o1hqoaGzxaq3nKw+MpscLPLkotP9UTtOtuXrHqxOP0pVRDg4wI= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a48.g.dreamhost.com (Postfix) with ESMTPSA id DCEBB81F74; Mon, 6 May 2019 10:01:59 -0700 (PDT) Date: Mon, 6 May 2019 12:01:57 -0500 X-DH-BACKEND: pdx1-sub0-mail-a48 From: Nico Williams To: Anders Rundgren Cc: Austin Wright , Ulysse Carion , json@ietf.org Message-ID: <20190506170155.GH21049@localhost> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> <6260354b-aca2-e001-7145-148b32658416@gmail.com> <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> <3a438654-b1ef-ecbd-0fb2-937d8f40f0c9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a438654-b1ef-ecbd-0fb2-937d8f40f0c9@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrjeekgddutdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 17:02:11 -0000 On Mon, May 06, 2019 at 10:55:56AM +0200, Anders Rundgren wrote: > On 2019-05-06 09:22, Austin Wright wrote: > > > > > Can you elaborate on this? My point is primarily concerned with JSON > > parsers, not JSON the media type. > > > > Suppose a string were too large to store in memory, most ECMAScript > > engines would bail with an uncatchable error. The suggestion is to > > implement this more robustly, like throw an error if a string would > > be too long, or if a number has too many significant figures; > > instead of either crashing or silently approximating the number. What's that got to do with schemas? > I don't understand this. A JSON schema is a description of a JSON > document. If the description is incompatible with implementations > that are supposed to parse compliant documents all bets are off. A schema is not a description of a document but a description of a class of documents. I suspect that you think the point of a schema is to allow you to have a parser that parses straight into an internal representation specifically derived from the schema, but that is not the only possibility! It should absolutely be possible to first parse a JSON text with a *generic* JSON parser, *then* check if the parsed thing meets the requirements of the schema. This is a very reasonable thing to do, especially with general-purpose languages like ECMAScript, or jq that deal with JSON very naturally. I object strongly to any JSON schema that makes this approach not workable. > > But also, why not build a parser that uses a schema to influence how > > values are parsed? Suppose you have a dynamically typed language, > > and want to parse some value, e.g. sometimes as an int, sometimes as > > a bignum, depending on the property. You might provide a JSON Schema > > to specify this behavior. > > This sounds like an edge-case but it could be supported by an "any" > type (although don't particularly see how this could work in a > cross-platform scenario). Or a CHOICE. (Here, again, I have to say that ASN.1 already has all these things, so we should at least be informed by it before we go off and reinvent that wheel badly.) Nico -- From nobody Mon May 6 12:25:05 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 0364A1200E6 for ; Mon, 6 May 2019 12:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 3tNIHfcGP0UJ for ; Mon, 6 May 2019 12:25:01 -0700 (PDT) Received: from bonobo.maple.relay.mailchannels.net (bonobo.maple.relay.mailchannels.net [23.83.214.22]) (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 5B14F120126 for ; Mon, 6 May 2019 12:25:01 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1E7F6126929; Mon, 6 May 2019 19:25:00 +0000 (UTC) Received: from pdx1-sub0-mail-a85.g.dreamhost.com (unknown [100.96.20.60]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A55251266B1; Mon, 6 May 2019 19:24:59 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a85.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 06 May 2019 19:25:00 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Wide-Eyed-Duck: 23f077d82e0c4ce4_1557170699901_9774490 X-MC-Loop-Signature: 1557170699901:538270888 X-MC-Ingress-Time: 1557170699900 Received: from pdx1-sub0-mail-a85.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a85.g.dreamhost.com (Postfix) with ESMTP id 5BFCC8096E; Mon, 6 May 2019 12:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=ATpiwO5PH54LYRwj8DMAzmiUtZM=; b=tZZeq7pvakw ZxvyNd1okUrwx2he6tkCvYIx9Nm0p38oy5X8pA4COH3Eu1o6s3qycpkG38SX3xN3 CJanYmXn55InsjLgrbrGD3wd9uYLRQs/KOg6Aej3tYJD4rfP4iS6Aq5wlASk4BCl bD7OR+tFGYBXwb+Vt2aibc4sHb8/+gwU= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a85.g.dreamhost.com (Postfix) with ESMTPSA id E1B8680972; Mon, 6 May 2019 12:24:56 -0700 (PDT) Date: Mon, 6 May 2019 14:24:54 -0500 X-DH-BACKEND: pdx1-sub0-mail-a85 From: Nico Williams To: Carsten Bormann Cc: Austin Wright , json@ietf.org Message-ID: <20190506192453.GK21049@localhost> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> <6260354b-aca2-e001-7145-148b32658416@gmail.com> <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> <751DAC92-D70C-4C5E-9C61-954D6E300A1F@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <751DAC92-D70C-4C5E-9C61-954D6E300A1F@tzi.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -51 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrjeekgdeflecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucffohhmrghinhepghhithhhuhgsrdhiohenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 19:25:04 -0000 On Mon, May 06, 2019 at 09:32:13AM +0200, Carsten Bormann wrote: > On May 6, 2019, at 09:22, Austin Wright wrote: > > But also, why not build a parser that uses a schema to influence how > > values are parsed? Because some of us have generic parsers with associated DSLs and we don't want to be left out. Specifically, in my case, jq https://stedolan.github.io/jq -- something of an XSLT/XPath for JSON. It's perfectly reasonable to build a jq application that adheres to a JSON schema, but it's not reasonable to expect the jq encoder to know to do encoding in context-specific ways -- the jq encoder is too generic and divorced from the rest of the jq machinery to possibly be able to do that. By pursuing a schema design that requires context-specific parsing or encoding behaviors, though you could say that the result looks like JSON, it precludes use of existing JSON tooling such as jq. Substitute ECMAScript for jq if you like -- the result is the same. I strenuously object to this sort of schema. As a maintainer of jq, I wouldn't know what to say to users who then complain about non-interop with such a schema other than to point to this thread and blame the people who allowed it to happen. But the damage to jq would be real and unavoidable. To avoid that damage, if I cannot convince you, then I assure you that I would appeal any finding of consensus for such a schema design. I'm sorry, but 10.0 is perfectly acceptable as an integer, and MUST be accepted as an integer when you expect an integer even if the JSON RFC says encoders SHOULD NOT include zero fractional parts. I would suggest that if you have a schema that says "and this is an integer", the schema MUST accept zero fractional parts, and SHOULD let you specify what to do if a non-integer real number is parsed for that field (e.g., truncate the fractional part, floor, round). > That is exactly what most of the members of this WG are afraid of when > the talk comes to =E2=80=9Cschemas=E2=80=9D. +1 > XML (and later JSON) learned one thing from the problems of SGML: > schema-oblivious decoders are more robust than schema-depending ones. > (They are, in the first place, and protocol evolution only amplifies > this.) Not only that! Can you imagine using XSLT/XPath if some XML schema requires different parsing behavior for different elements?! It wouldn't be possible to do that *and* still be able to use XSLT/XPath because XSLT/XPath processors generally have a built-in generic XML parser. It would destroy the utility of XSLT/XPath! And that proves that an XML schema of that sort... would yield something that is NOT XML, but merely looks like XML. The same exact reasoning applies in the case of JSON. The only difference being that JSON doesn't [yet] have a standard equivalent to XSLT/XPath, but since generic parsers and encoders exist, and since node.jq, JavaScript, ECMAScript, jq, and such exist, the point stands. > > Suppose you have a dynamically typed language, and want to parse > > some value, e.g. sometimes as an int, sometimes as a bignum, > > depending on the property. You might provide a JSON Schema to > > specify this behavior. >=20 > There goes the generic decoder. >=20 > (There is nothing wrong with using a =E2=80=9Cschema=E2=80=9D to specif= y upconversion > from the JSON data model to your application data model. What I=E2=80=99= m > objecting to is getting rid of JSON and replacing it with a gazillion > dialects that happen to be syntactically compatible with JSON but the > semantics of which are controlled by a =E2=80=9Cschema=E2=80=9D mechani= sm.) +1. Nico --=20 From nobody Mon May 6 14:01:02 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 E8B78120155 for ; Mon, 6 May 2019 14:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net 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 BfVWSQB5XsoE for ; Mon, 6 May 2019 14:00:58 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 EDCB61200EA for ; Mon, 6 May 2019 14:00:57 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id 13so7090640pfw.9 for ; Mon, 06 May 2019 14:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zO7BZmx1F+JD+RO+4XUg+Dxco90g4LQLpverk/s3D2o=; b=4XG0SlOaPTtDyk+BFL7Qd9gLychDknPJeiU6om/Sq5QagcuzFAhsqKUCYJjV953C2x 6j7PPvje4RJXlzlF+vnaZSAu++UWsETExahMJdbhYY6bGgt04cjKbMshNR9kGuG+K7eS XS3pTRNb6Ctc37WvdAX/whVtbUMHW/c4oRMKI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zO7BZmx1F+JD+RO+4XUg+Dxco90g4LQLpverk/s3D2o=; b=bWzGLRpVXW7coO1Cm8U+ydeH6F3PwAUSp/fV9M5y1IJr5ae7zg9l/yrVInRDx6cp3U 4AKiFrCpHqT3+uDI8o60cklSc9wwLy/d9LlaXFYUR4lHV/PQNryGk64qm12FjAHEhzBP uE5gimCa3W4rXjNvcmZd4ZK22ZE2nIWBExXqoys8fMdrHTAWz3fWGZb7XXH2iLAGCAa+ +0BA71YbNXkxImWHfu21wqpe1tiuP6uIfNgXpHLt2a6rUBF8kkRDAayQ7COa/TuOyxus Gp5HIduDYLQSTyuKHx73XoY1ezeRe0IWFts0SxPOXoXO0noTyS+i8hfK5jxKOcik0fTX Gc0g== X-Gm-Message-State: APjAAAVExMULfZqquryoU7NEfjhBHVWlnQmX319QJ5exnCtoojaoHRAV VJmeYzhqMfAd2wrgRAZB5SXpRg== X-Google-Smtp-Source: APXvYqxWuc8TF/R0+cHNCGT2S5f3t6a2Q/2qHEdMfm37lR+rHfe1ANlvENRHugCPnnboKgkKEAEi8g== X-Received: by 2002:a62:864a:: with SMTP id x71mr37495601pfd.228.1557176457074; Mon, 06 May 2019 14:00:57 -0700 (PDT) Received: from [192.168.0.116] ([184.101.46.90]) by smtp.gmail.com with ESMTPSA id m123sm8726467pfm.39.2019.05.06.14.00.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 May 2019 14:00:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Austin Wright In-Reply-To: <20190506192453.GK21049@localhost> Date: Mon, 6 May 2019 14:00:54 -0700 Cc: Carsten Bormann , json@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <753A412B-299F-400F-9D19-A9688068D842@bzfx.net> References: <39682ec8-f993-a44c-d3e2-1638d2c1608f@gmail.com> <29CAE1CE-D6CB-4796-B2F2-2095BE921385@tzi.org> <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> <6260354b-aca2-e001-7145-148b32658416@gmail.com> <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> <751DAC92-D70C-4C5E-9C61-954D6E300A1F@tzi.org> <20190506192453.GK21049@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 21:01:01 -0000 > On May 6, 2019, at 12:24, Nico Williams wrote: >=20 > On Mon, May 06, 2019 at 09:32:13AM +0200, Carsten Bormann wrote: >> On May 6, 2019, at 09:22, Austin Wright wrote: >>> But also, why not build a parser that uses a schema to influence how >>> values are parsed? >=20 > Because some of us have generic parsers with associated DSLs and we > don't want to be left out. >=20 > Specifically, in my case, jq https://stedolan.github.io/jq -- = something > of an XSLT/XPath for JSON. >=20 > It's perfectly reasonable to build a jq application that adheres to a > JSON schema, but it's not reasonable to expect the jq encoder to know = to > do encoding in context-specific ways -- the jq encoder is too generic > and divorced from the rest of the jq machinery to possibly be able to = do > that. Left out of what, exactly? See below. >=20 > By pursuing a schema design that requires context-specific parsing or > encoding behaviors, though you could say that the result looks like > JSON, it precludes use of existing JSON tooling such as jq. >=20 > Substitute ECMAScript for jq if you like -- the result is the same. >=20 > I strenuously object to this sort of schema. >=20 > As a maintainer of jq, I wouldn't know what to say to users who then > complain about non-interop with such a schema other than to point to > this thread and blame the people who allowed it to happen. But the > damage to jq would be real and unavoidable. To avoid that damage, if = I > cannot convince you, then I assure you that I would appeal any finding > of consensus for such a schema design. >=20 > I'm sorry, but 10.0 is perfectly acceptable as an integer, and MUST be > accepted as an integer when you expect an integer even if the JSON RFC > says encoders SHOULD NOT include zero fractional parts. >=20 > I would suggest that if you have a schema that says "and this is an > integer", the schema MUST accept zero fractional parts, and SHOULD let > you specify what to do if a non-integer real number is parsed for that > field (e.g., truncate the fractional part, floor, round). I=E2=80=99m not suggesting a variance from the JSON semantics. My suggestion is an alternative to parsers that lose data when they = parse JSON documents, for example, ECMAScript's JSON.parse number = parsing. You can, of course, always parse a JSON document according to = the generic semantics. The issue here is how does a program parse a JSON document that with a = wider range of values than what the program has room for? Either a = string that=E2=80=99s too long, an array with too many items, or a = number with too many significant figures? Normally you would have to write your own parser, or use a tokenizer = that preserves the lexical values without casting them to native types. = Then you perform your own validation in code, and decide how to convert = a lexical JSON number into a native number, depending on context. Right now, programs usually do this in code. My suggestion is to write = these rules as a document. The idea of JSON Schema is you make = assertions about the document=E2=80=94=E2=80=9Cthis field must be an = RFC3339 date string=E2=80=9D=E2=80=94and let the parser or application = make additional optimizations (in this case, an RFC3339 string will = never be more than 25 characters). >=20 >> That is exactly what most of the members of this WG are afraid of = when >> the talk comes to =E2=80=9Cschemas=E2=80=9D. >=20 > +1 >=20 >> XML (and later JSON) learned one thing from the problems of SGML: >> schema-oblivious decoders are more robust than schema-depending ones. >> (They are, in the first place, and protocol evolution only amplifies >> this.) >=20 > Not only that! >=20 > Can you imagine using XSLT/XPath if some XML schema requires different > parsing behavior for different elements?! It wouldn't be possible to = do > that *and* still be able to use XSLT/XPath because XSLT/XPath = processors > generally have a built-in generic XML parser. It would destroy the > utility of XSLT/XPath! >=20 > And that proves that an XML schema of that sort... would yield = something > that is NOT XML, but merely looks like XML. >=20 > The same exact reasoning applies in the case of JSON. The only > difference being that JSON doesn't [yet] have a standard equivalent to > XSLT/XPath, but since generic parsers and encoders exist, and since > node.jq, JavaScript, ECMAScript, jq, and such exist, the point stands. >=20 >>> Suppose you have a dynamically typed language, and want to parse >>> some value, e.g. sometimes as an int, sometimes as a bignum, >>> depending on the property. You might provide a JSON Schema to >>> specify this behavior. >>=20 >> There goes the generic decoder. >>=20 >> (There is nothing wrong with using a =E2=80=9Cschema=E2=80=9D to = specify upconversion >> from the JSON data model to your application data model. What I=E2=80=99= m >> objecting to is getting rid of JSON and replacing it with a gazillion >> dialects that happen to be syntactically compatible with JSON but the >> semantics of which are controlled by a =E2=80=9Cschema=E2=80=9D = mechanism.) There=E2=80=99s scarcely a completely generic decoder in existence. They = should be, but they=E2=80=99ve typically decided it=E2=80=99s easier to = make assumptions of one sort or another, especially around numbers. >=20 > +1. >=20 > Nico > --=20 From nobody Mon May 6 14:15:23 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 C0AD31200EA for ; Mon, 6 May 2019 14:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 vENpUVtRtp6M for ; Mon, 6 May 2019 14:15:21 -0700 (PDT) Received: from ostrich.birch.relay.mailchannels.net (ostrich.birch.relay.mailchannels.net [23.83.209.138]) (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 25077120073 for ; Mon, 6 May 2019 14:15:21 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 15E6F5E3C35; Mon, 6 May 2019 21:15:20 +0000 (UTC) Received: from pdx1-sub0-mail-a100.g.dreamhost.com (100-96-79-5.trex.outbound.svc.cluster.local [100.96.79.5]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7F66E5E3B75; Mon, 6 May 2019 21:15:19 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a100.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 06 May 2019 21:15:20 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Robust-Imminent: 01adb2f816766a68_1557177319902_1926402974 X-MC-Loop-Signature: 1557177319902:3536525405 X-MC-Ingress-Time: 1557177319902 Received: from pdx1-sub0-mail-a100.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a100.g.dreamhost.com (Postfix) with ESMTP id 00A5E7FEBC; Mon, 6 May 2019 14:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=JRBNDVtGqZyGUEDHGklaYz6/+Wg=; b=AHNAaTb8+IY 5q+Fiy7nuHxRWVKxNiCOiqojsG/Sn245ImfDYvK4izeDqYDtwMSMTOraOaHm/SAf 9JtvURzRSK487AoC5ShvUKPCGcdtd7zpJfvrDVeWxPJk9IR/uFpnsxtsDWRpjRx3 g62N5nn6wlHNlmLXIgCEje6JOccPHhBQ= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a100.g.dreamhost.com (Postfix) with ESMTPSA id 9F2287FEBB; Mon, 6 May 2019 14:15:13 -0700 (PDT) Date: Mon, 6 May 2019 16:15:11 -0500 X-DH-BACKEND: pdx1-sub0-mail-a100 From: Nico Williams To: Austin Wright Cc: Carsten Bormann , json@ietf.org Message-ID: <20190506211509.GL21049@localhost> References: <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> <6260354b-aca2-e001-7145-148b32658416@gmail.com> <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> <751DAC92-D70C-4C5E-9C61-954D6E300A1F@tzi.org> <20190506192453.GK21049@localhost> <753A412B-299F-400F-9D19-A9688068D842@bzfx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <753A412B-299F-400F-9D19-A9688068D842@bzfx.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrjeekgdeiudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 21:15:23 -0000 On Mon, May 06, 2019 at 02:00:54PM -0700, Austin Wright wrote: > > On May 6, 2019, at 12:24, Nico Williams wrote= : > > Because some of us have generic parsers with associated DSLs and we > > don't want to be left out. >=20 > Left out of what, exactly? See below. Out of interoperating with other applications using this schema thing. > > [...] >=20 > I=E2=80=99m not suggesting a variance from the JSON semantics. If you would have your parser reject 10.0 because the schema says to expect an integer, then you are forking JSON as you are precluding interoperability with some JSON encoders. Especially too if you then also insisted on a fractional part when a schema element expects a real number so that you'd have the parser reject 10 -- then encoders would be damned if they do and damned if they don't. I explained how this would preclude use of jq or any other XSLT/XPath- alike for JSON from interoperating with applications using such a schema language. > My suggestion is an alternative to parsers that lose data when they > parse JSON documents, for example, ECMAScript's JSON.parse number > parsing. You can, of course, always parse a JSON document according to > the generic semantics. The key word there is "alternative". You're forking JSON. > The issue here is how does a program parse a JSON document that with a > wider range of values than what the program has room for? Either a > string that=E2=80=99s too long, an array with too many items, or a numb= er with > too many significant figures? I explained this earlier. First, as to fractional parts of numeric values, a) zero fractional parts MUST be tolerated, b) non-zero fractional parts can be truncated, rounded, or rejected according to the schema authors' choice. This is a case where being liberal in what you accept is a good thing. > Normally you would have to write your own parser, or use a tokenizer Why not use an off-the-shelf one? > that preserves the lexical values without casting them to native > types. Then you perform your own validation in code, and decide how to > convert a lexical JSON number into a native number, depending on > context. That's one way, and it has to be possible, because that's essentially what you'd do with jq or ECMAScript. You could also use a streaming parser (which jq also has) to immediately handle each value as it is parsed. You could also write a combined parser and validator. And, of course, you could generate a parser&validator from the schema. I'm not rejecting any of those choices. I'm insisting ONLY on the first choice (first parse, then validate) needing to remain valid and workable. If you make this choice no longer feasible, then you've forked JSON. Please don't. Nico --=20 From nobody Mon May 6 14:26:49 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 9DE0312002F for ; Mon, 6 May 2019 14:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net 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 phDZoxgxacMd for ; Mon, 6 May 2019 14:26:46 -0700 (PDT) Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (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 7D22E120020 for ; Mon, 6 May 2019 14:26:46 -0700 (PDT) Received: by mail-pl1-x642.google.com with SMTP id z8so7009525pln.4 for ; Mon, 06 May 2019 14:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zOx+r6jaY32yLzb1/zOW3WSCusz+Br4xg9F3MPIn3Rs=; b=qWCcjtLs4UVfhcTNEAshrRNUjohZRqNBgbT8wD65ZUyaRHHxKAHQad/hok9dM1nyZk R080Ky2Xi1dA3LYcVFSuw3VkSVLA8JQF13XfcHjAHwSWznk4RTTNw8TC8wAq9Z66Y2cn 4wzpuMTjytggLmmfLkWg4JtOCPLTLANP6AVe0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zOx+r6jaY32yLzb1/zOW3WSCusz+Br4xg9F3MPIn3Rs=; b=qv+T+MzXJf3t8kaiyyjLLVR/bq1a8zUf7fpRhMakUFwDczn29NiZx5sfEcUzg99erw xOhKhWvsUVI2ogcmuFscgr10ifFdEOPuOagNHSIdi0SjlnoLXgaI5ZPpzbI2zBpCjQEQ k3C71WicF7RpgsWJqMaqdUujQLMOMYJ9InqoPrIsjtjkvJI8IbvaQ+2JXCaa/LenWRk1 KHNaeAFra4fzqpcD7HGuGD5l3Ge/A1FL0zn+z+kjY7VkxBYPIB9ndShH8322IdNERJcV o0ejwD+3ultAu1AD8CGkiz/hVT5X7ZuzVLpaQsL7bgFxlKNSl4pmYtuIWEi8dL3P3a+t GWgA== X-Gm-Message-State: APjAAAXYIV3j9GsNs7BkjTqXZ4inT0VEaB+w+Gt6NmEf4tuXa8h6XS7b n6me9kthk0WFhX7kV6Rs2kmkQQ== X-Google-Smtp-Source: APXvYqyRNlx6WDhyVxtR+BbUYYojsGNKaCbvg4wmLaP3F6ughmVYzdh0jXVpx2IIvK1Pt7MN8Kcprg== X-Received: by 2002:a17:902:8609:: with SMTP id f9mr33898256plo.32.1557178005763; Mon, 06 May 2019 14:26:45 -0700 (PDT) Received: from [192.168.0.116] ([184.101.46.90]) by smtp.gmail.com with ESMTPSA id z10sm13801372pge.87.2019.05.06.14.26.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 May 2019 14:26:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Austin Wright In-Reply-To: <20190506211509.GL21049@localhost> Date: Mon, 6 May 2019 14:26:43 -0700 Cc: Carsten Bormann , json@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <32F23E7E-F3AA-4244-AAEC-4582AE7919B9@bzfx.net> References: <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> <6260354b-aca2-e001-7145-148b32658416@gmail.com> <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> <751DAC92-D70C-4C5E-9C61-954D6E300A1F@tzi.org> <20190506192453.GK21049@localhost> <753A412B-299F-400F-9D19-A9688068D842@bzfx.net> <20190506211509.GL21049@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 21:26:49 -0000 > On May 6, 2019, at 14:15, Nico Williams wrote: >=20 > On Mon, May 06, 2019 at 02:00:54PM -0700, Austin Wright wrote: >>> On May 6, 2019, at 12:24, Nico Williams = wrote: >>> Because some of us have generic parsers with associated DSLs and we >>> don't want to be left out. >>=20 >> Left out of what, exactly? See below. >=20 > Out of interoperating with other applications using this schema thing. You=E2=80=99ll need to provide a specific example, I think there=E2=80=99s= a misunderstanding. >=20 >>> [...] >>=20 >> I=E2=80=99m not suggesting a variance from the JSON semantics. >=20 > If you would have your parser reject 10.0 because the schema says to > expect an integer, then you are forking JSON as you are precluding > interoperability with some JSON encoders. Especially too if you then > also insisted on a fractional part when a schema element expects a = real > number so that you'd have the parser reject 10 -- then encoders would = be > damned if they do and damned if they don=E2=80=99t. >=20 > I explained how this would preclude use of jq or any other XSLT/XPath- > alike for JSON from interoperating with applications using such a = schema > language. I never suggested this. While JSON doesn=E2=80=99t specify what an = =E2=80=9Cinteger=E2=80=9D is (i.e. we could define it to be any subset = of number that we want), JSON Schema tries to be liberal and specifies = that excessive precision still qualifies as an integer. (I=E2=80=99m the = one who added that language.) >=20 >> My suggestion is an alternative to parsers that lose data when they >> parse JSON documents, for example, ECMAScript's JSON.parse number >> parsing. You can, of course, always parse a JSON document according = to >> the generic semantics. >=20 > The key word there is "alternative". You're forking JSON. >=20 >> The issue here is how does a program parse a JSON document that with = a >> wider range of values than what the program has room for? Either a >> string that=E2=80=99s too long, an array with too many items, or a = number with >> too many significant figures? >=20 > I explained this earlier. >=20 > First, as to fractional parts of numeric values, a) zero fractional > parts MUST be tolerated, b) non-zero fractional parts can be = truncated, > rounded, or rejected according to the schema authors' choice. >=20 > This is a case where being liberal in what you accept is a good thing. >=20 >> Normally you would have to write your own parser, or use a tokenizer >=20 > Why not use an off-the-shelf one? >=20 >> that preserves the lexical values without casting them to native >> types. Then you perform your own validation in code, and decide how = to >> convert a lexical JSON number into a native number, depending on >> context. >=20 > That's one way, and it has to be possible, because that's essentially > what you'd do with jq or ECMAScript. >=20 > You could also use a streaming parser (which jq also has) to = immediately > handle each value as it is parsed. >=20 > You could also write a combined parser and validator. >=20 > And, of course, you could generate a parser&validator from the schema. >=20 > I'm not rejecting any of those choices. >=20 > I'm insisting ONLY on the first choice (first parse, then validate) > needing to remain valid and workable. If you make this choice no = longer > feasible, then you've forked JSON. Please don't. >=20 > Nico > --=20 From nobody Mon May 6 14:32:40 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 73DAE1200EB for ; Mon, 6 May 2019 14:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 Cr1Bxn0ivPtG for ; Mon, 6 May 2019 14:32:37 -0700 (PDT) Received: from common.maple.relay.mailchannels.net (common.maple.relay.mailchannels.net [23.83.214.38]) (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 16E2812016A for ; Mon, 6 May 2019 14:32:33 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A78DA5C51BE; Mon, 6 May 2019 21:32:31 +0000 (UTC) Received: from pdx1-sub0-mail-a100.g.dreamhost.com (unknown [100.96.11.48]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5A4445C4E79; Mon, 6 May 2019 21:32:31 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a100.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 06 May 2019 21:32:31 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Harbor-Lonely: 337407c7002976e7_1557178351496_1026271256 X-MC-Loop-Signature: 1557178351496:13776086 X-MC-Ingress-Time: 1557178351496 Received: from pdx1-sub0-mail-a100.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a100.g.dreamhost.com (Postfix) with ESMTP id E6F1E7FEA1; Mon, 6 May 2019 14:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=yHSKzs9+Y584N/dunWSauQtspzk=; b=aaqM/echNH9 vRGq4Y+rehOn+Q6kdASMwfAc4LbgH+R9NmasBCSH8E82f17yFqnEY72FV92I/rM4 FT6YbDGysWDtpYUE3BHJY9vx79i0XjOBnCkt32BnWWvMT5efJaJd+XwGH4iar+FC o86+NWiu5zqYYIFRUiiLNwIbHVUiH7v4= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a100.g.dreamhost.com (Postfix) with ESMTPSA id E6E787FEB8; Mon, 6 May 2019 14:32:28 -0700 (PDT) Date: Mon, 6 May 2019 16:32:26 -0500 X-DH-BACKEND: pdx1-sub0-mail-a100 From: Nico Williams To: Austin Wright Cc: Carsten Bormann , json@ietf.org Message-ID: <20190506213224.GM21049@localhost> References: <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> <6260354b-aca2-e001-7145-148b32658416@gmail.com> <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> <751DAC92-D70C-4C5E-9C61-954D6E300A1F@tzi.org> <20190506192453.GK21049@localhost> <753A412B-299F-400F-9D19-A9688068D842@bzfx.net> <20190506211509.GL21049@localhost> <32F23E7E-F3AA-4244-AAEC-4582AE7919B9@bzfx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <32F23E7E-F3AA-4244-AAEC-4582AE7919B9@bzfx.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrjeekgdeihecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 21:32:39 -0000 On Mon, May 06, 2019 at 02:26:43PM -0700, Austin Wright wrote: > > On May 6, 2019, at 14:15, Nico Williams wrote= : > >>> On May 6, 2019, at 12:24, Nico Williams wro= te: > >>> Because some of us have generic parsers with associated DSLs and we > >>> don't want to be left out. > >>=20 > >> Left out of what, exactly? See below. > >=20 > > Out of interoperating with other applications using this schema thing= . >=20 > You=E2=80=99ll need to provide a specific example, I think there=E2=80=99= s a misunderstanding. I did. Any application that uses an off-the-shelf generic parser and encoder and does schema validation in a different step. > > I explained how this would preclude use of jq or any other XSLT/XPath= - > > alike for JSON from interoperating with applications using such a sch= ema > > language. >=20 > I never suggested this. While JSON doesn=E2=80=99t specify what an =E2=80= =9Cinteger=E2=80=9D > is (i.e. we could define it to be any subset of number that we want), > JSON Schema tries to be liberal and specifies that excessive precision > still qualifies as an integer. (I=E2=80=99m the one who added that lang= uage.) Then accept 10.0 as an integer. Nico --=20 From nobody Mon May 6 14:40: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 B4654120175 for ; Mon, 6 May 2019 14:40:14 -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_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=bzfx.net 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 e1LoBecUct6B for ; Mon, 6 May 2019 14:40:12 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 5A4501200A4 for ; Mon, 6 May 2019 14:40:12 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id h1so7125453pgs.2 for ; Mon, 06 May 2019 14:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=apfLm5AnMAH/2NanYWtBTMiQZsyR8RGkr2yh0Y0Z7os=; b=MKVZgUMdz5ttzFsRscnYchNQ1CFlbK3AIIVIfWP1KCwLvAcBgIXH1LSFhgTPPyVwNb AXQWWar+ZRoqgaNbR0Mck7nhrWs27Cic3lSbyzlEoKibylNcswys7uwlbhN1l1EXuAUl PIclXwIe6hBsQ+uv2JJMLdACMrKRCKul0sqPw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=apfLm5AnMAH/2NanYWtBTMiQZsyR8RGkr2yh0Y0Z7os=; b=I9dOxajm0371BKqq2ozqD0hm2ye7gwFV5whlFW5nQKTTMMF0yd3YmRyZgkHi8OZTQ1 068Ybd//6mepR5hkaaUb63ntxmlDVkdLOwh9Z633UZvHRoTOWa8Zae2A8YScbqnhO50D 58XPIiKALaTQoymxdjfydjELZB7acv0RaIUPsYoEdtsxOCct5mMc3NjIM0G9mcWPhwoy /FA8dWWttSKZFYY4TmZ29LX/mAVJ4fc5BijFs8oQLZFw1IF0o2i0la9dmuFFyBDyA8dl RfscM1dNP4IoltsWv/X0Jz0OGHIOfnZCvcEfeTOdC5lVRzoAT+V9NmaMF9hksrH5lDGQ bfLg== X-Gm-Message-State: APjAAAWQX4f9A19749OJ4XBUbJq5f9gEDqeeY/qTwxgnJeQOTm/vjaxl DnAOW9wUtDZALI9qs4OT3HJQhQ== X-Google-Smtp-Source: APXvYqy48EQzuskMiUVpBMriOHbVA4vhIB/jPO2P7dz3tCm68YsVJnFmliqb10Me+NbJ/kdBxatoVw== X-Received: by 2002:a63:6988:: with SMTP id e130mr35693444pgc.150.1557178811490; Mon, 06 May 2019 14:40:11 -0700 (PDT) Received: from [192.168.0.116] ([184.101.46.90]) by smtp.gmail.com with ESMTPSA id j22sm14331340pfn.129.2019.05.06.14.40.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 May 2019 14:40:10 -0700 (PDT) From: Austin Wright Message-Id: <957CDE65-2987-41A9-B5EB-D54D978B433A@bzfx.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_4FC556CE-4786-4ADE-B1E0-7162103B6FD0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 6 May 2019 14:40:08 -0700 In-Reply-To: <20190506213224.GM21049@localhost> Cc: Carsten Bormann , json@ietf.org To: Nico Williams References: <40f80ea0-d130-3f3b-39fa-2c84e802ed55@gmail.com> <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> <6260354b-aca2-e001-7145-148b32658416@gmail.com> <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> <751DAC92-D70C-4C5E-9C61-954D6E300A1F@tzi.org> <20190506192453.GK21049@localhost> <753A412B-299F-400F-9D19-A9688068D842@bzfx.net> <20190506211509.GL21049@localhost> <32F23E7E-F3AA-4244-AAEC-4582AE7919B9@bzfx.net> <20190506213224.GM21049@localhost> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 21:40:15 -0000 --Apple-Mail=_4FC556CE-4786-4ADE-B1E0-7162103B6FD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 6, 2019, at 14:32, Nico Williams wrote: >=20 > On Mon, May 06, 2019 at 02:26:43PM -0700, Austin Wright wrote: >>> On May 6, 2019, at 14:15, Nico Williams = wrote: >>>>> On May 6, 2019, at 12:24, Nico Williams = wrote: >>>>> Because some of us have generic parsers with associated DSLs and = we >>>>> don't want to be left out. >>>>=20 >>>> Left out of what, exactly? See below. >>>=20 >>> Out of interoperating with other applications using this schema = thing. >>=20 >> You=E2=80=99ll need to provide a specific example, I think there=E2=80=99= s a misunderstanding. >=20 > I did. Any application that uses an off-the-shelf generic parser and > encoder and does schema validation in a different step. >=20 >>> I explained how this would preclude use of jq or any other = XSLT/XPath- >>> alike for JSON from interoperating with applications using such a = schema >>> language. >>=20 >> I never suggested this. While JSON doesn=E2=80=99t specify what an = =E2=80=9Cinteger=E2=80=9D >> is (i.e. we could define it to be any subset of number that we want), >> JSON Schema tries to be liberal and specifies that excessive = precision >> still qualifies as an integer. (I=E2=80=99m the one who added that = language.) >=20 > Then accept 10.0 as an integer. The only JSON parsers/JSON Schema validators I maintain are in = ECMAScript, and both validate `10.0` as an integer. [1] [2] If you=E2=80=99re talking about the Newtonsoft JSON parser, or anything = else, you should ask them directly. By all means, feel free to copy me = on that email or GitHub issue. Thanks, Austin. [1] https://github.com/awwright/jsonschemaparse = [2] https://github.com/tdegrunt/jsonschema = --Apple-Mail=_4FC556CE-4786-4ADE-B1E0-7162103B6FD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 6, 2019, at 14:32, Nico Williams <nico@cryptonector.com> wrote:

On = Mon, May 06, 2019 at 02:26:43PM -0700, Austin Wright wrote:
On May 6, 2019, at 14:15, Nico Williams <nico@cryptonector.com> wrote:
On May 6, = 2019, at 12:24, Nico Williams <nico@cryptonector.com> wrote:
Because = some of us have generic parsers with associated DSLs and we
don't want to be left out.

Left out of what, exactly? See below.

Out of interoperating with other = applications using this schema thing.

You=E2=80=99ll need to provide a specific example, I think = there=E2=80=99s a misunderstanding.

I did.  Any application that uses an off-the-shelf = generic parser and
encoder and does schema validation in a = different step.

I explained how this = would preclude use of jq or any other XSLT/XPath-
alike = for JSON from interoperating with applications using such a schema
language.

I never = suggested this. While JSON doesn=E2=80=99t specify what an = =E2=80=9Cinteger=E2=80=9D
is (i.e. we could define it to = be any subset of number that we want),
JSON Schema tries = to be liberal and specifies that excessive precision
still = qualifies as an integer. (I=E2=80=99m the one who added that = language.)

Then accept 10.0 as = an integer.

The only JSON parsers/JSON Schema validators = I maintain are in ECMAScript, and both validate `10.0` as an integer. = [1] [2]

If = you=E2=80=99re talking about the Newtonsoft JSON parser, or anything = else, you should ask them directly. By all means, feel free to copy me = on that email or GitHub issue.

Thanks,

Austin.


[1] https://github.com/awwright/jsonschemaparse
[2] https://github.com/tdegrunt/jsonschema

= --Apple-Mail=_4FC556CE-4786-4ADE-B1E0-7162103B6FD0-- From nobody Mon May 6 14:46:21 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 0988312002F for ; Mon, 6 May 2019 14:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 dBoTiACzQF2q for ; Mon, 6 May 2019 14:46:17 -0700 (PDT) Received: from bonobo.maple.relay.mailchannels.net (bonobo.maple.relay.mailchannels.net [23.83.214.22]) (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 5E322120021 for ; Mon, 6 May 2019 14:46:17 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A42F45E1EBD; Mon, 6 May 2019 21:46:16 +0000 (UTC) Received: from pdx1-sub0-mail-a100.g.dreamhost.com (100-96-79-6.trex.outbound.svc.cluster.local [100.96.79.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EDDF05E2347; Mon, 6 May 2019 21:46:15 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a100.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 06 May 2019 21:46:16 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Daffy-Print: 48a6105f6800110f_1557179176379_798604708 X-MC-Loop-Signature: 1557179176379:4189520318 X-MC-Ingress-Time: 1557179176378 Received: from pdx1-sub0-mail-a100.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a100.g.dreamhost.com (Postfix) with ESMTP id DFBE47FEC2; Mon, 6 May 2019 14:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=iksIL1mEJi1yiKUlaKvUkPJ/O9c=; b=GAQr2+2agB5 qmayxoy5xvF9rwnsCF8UdsP6lPBQNIF2RrgMosnayo1jZXm8TYBoGI48KIjgw7Dd bcbgpICZo+jcVVAjFDxMAiPh6W+6W64mn6p3AQbjMEr2KWTs95w/bi+COfpehyEb 6y7/2CS94AznB+zY/9WvSqNmaMC0dlQg= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a100.g.dreamhost.com (Postfix) with ESMTPSA id E35317FEBE; Mon, 6 May 2019 14:46:10 -0700 (PDT) Date: Mon, 6 May 2019 16:46:08 -0500 X-DH-BACKEND: pdx1-sub0-mail-a100 From: Nico Williams To: Austin Wright Cc: Carsten Bormann , json@ietf.org Message-ID: <20190506214607.GN21049@localhost> References: <35E2623E-753D-4918-8AF4-BF0BC5DE4868@bzfx.net> <6260354b-aca2-e001-7145-148b32658416@gmail.com> <9D90C1F1-6747-4373-93B0-8D51C5B25F1C@bzfx.net> <751DAC92-D70C-4C5E-9C61-954D6E300A1F@tzi.org> <20190506192453.GK21049@localhost> <753A412B-299F-400F-9D19-A9688068D842@bzfx.net> <20190506211509.GL21049@localhost> <32F23E7E-F3AA-4244-AAEC-4582AE7919B9@bzfx.net> <20190506213224.GM21049@localhost> <957CDE65-2987-41A9-B5EB-D54D978B433A@bzfx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <957CDE65-2987-41A9-B5EB-D54D978B433A@bzfx.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrjeelgddtfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 21:46:19 -0000 On Mon, May 06, 2019 at 02:40:08PM -0700, Austin Wright wrote: > >> I never suggested this. While JSON doesn=E2=80=99t specify what an =E2= =80=9Cinteger=E2=80=9D > >> is (i.e. we could define it to be any subset of number that we want)= , > >> JSON Schema tries to be liberal and specifies that excessive precisi= on > >> still qualifies as an integer. (I=E2=80=99m the one who added that l= anguage.) > >=20 > > Then accept 10.0 as an integer. >=20 > The only JSON parsers/JSON Schema validators I maintain are in > ECMAScript, and both validate `10.0` as an integer. [1] [2] >=20 > If you=E2=80=99re talking about the Newtonsoft JSON parser, or anything= else, > you should ask them directly. By all means, feel free to copy me on > that email or GitHub issue. Oy, I think I confused who wanted 10.0 not to parse as an integer. Sorry about that. From nobody Mon May 6 15:38:35 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 7D7A91200CD for ; Mon, 6 May 2019 15:38:34 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 W7bI2y7rwCtN for ; Mon, 6 May 2019 15:38:31 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 BE3FC1200A4 for ; Mon, 6 May 2019 15:38:31 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id u2so9092935ioc.4 for ; Mon, 06 May 2019 15:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=77nQfj4rD82vjFTfd475NTK5G80S6fvhKOmzq+nW9m8=; b=jX0qtz1xIDzM/bBwfxmVI9LSteK87U2ytNKmW/LFFxWUECYDVlFSlrwuflJBTmzuIy oKP+EpY0etCprBhVgZEX9PkeiDatZ9hvRgyLQcVLetMth85lvWCNgHk9ZaYjSzej2Zcj ovf2YCaMcjhpfQiUc7WXjwBVryFl19d+uNp1QtuCiy2M3iDRaC3K5fau2mw5vWX/EN8Q ok5VFOKcigLV49tIwGQ8yJe+OF6HawCSv02VsidS8XiCcpMk8WV4ZeZlSKhZqCXWZObC dqpSBUV2faqgpkCfTDOX2n+8/U4BWWyprFhAzl185DEbxlNgIuv3NlzP/is+hXtvIrl7 szAQ== 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=77nQfj4rD82vjFTfd475NTK5G80S6fvhKOmzq+nW9m8=; b=Wt6LLs1F4sNgbsGP+1KI/9Ej0rKpdvJboQwvJN4o/9ayw1H3UsBNv9pLo2uizdZueR Owr9a7u1ZocngZh2XUd5Oqzgu0JyAqr5As3KFy+cnas8kpIIGjLLs7JuE4a9oU5HE0Af o7UiSk4PqT+6g9l06dNaYJIiGqG/zNstqohtb5gVoExE6AK+NACCqGuvKl9dMQSaQ52T OXJCT+1+GXhSBdPWqJnFMCMc24nWwJlYvK9aL5DPEOXbKKHUnatb4TfGxlXv5s/Ggkcm cyInhvSHMUmSayKmV3w5KvqyiezWcNl6+VwiDYzxOMh3HPvbJuoFjHp1dnZP0JUM5SjC xKpw== X-Gm-Message-State: APjAAAWmIA09t/pbiDoryQlu/3hne5nyv0QW2dBohnfN2KFVSG2umI9m DyEPyyv6oPxiFK04zg3NO810j0Dn2wX83v1HT9ML9A== X-Google-Smtp-Source: APXvYqzdc0NogItkYYIM2LDA9MXp+Snggu3/rkyDb34pMsWuQsX62ksStla8KrWEEKEkjRL8d1r2fUkO73+bSM8aBbU= X-Received: by 2002:a5d:9347:: with SMTP id i7mr561951ioo.84.1557182310952; Mon, 06 May 2019 15:38:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Mon, 6 May 2019 15:38:19 -0700 Message-ID: To: Ulysse Carion Cc: json@ietf.org Content-Type: multipart/alternative; boundary="0000000000007ed5eb05883fc22f" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 22:38:34 -0000 --0000000000007ed5eb05883fc22f Content-Type: text/plain; charset="UTF-8" Hi all. I haven't got around to reading the draft (but will soon). Prior to that, a few notes: 1. I'm pretty sure that we need something better than what we have in the area of JSON schemas. At least, I'm 100% sure that my job at Amazon Web Services would be easier, and our customer experiences would be more pleasant, if we had something. 2. One thing schemas are useful for is to syntax-check JSON texts that claim to conform to some language specification or another. Obviously no schema can ever completely satisfy this requirement - there are always things in specifications which are semantic and not addressable by schemas - but they can still be super useful. 3. Another thing they are useful for is for providing help to developers working in strongly typed programming languages. With a well-built schema it is reasonably straightforward to auto-generate nice idiomatic class declarations in modern programming languages, and also to build serializers/deserializers that will move data back and forth between JSON blobs and programming-language constructs, or fail in a clean deterministic way if the JSON fails to match the schema. I mostly fail to understand the debate about jq and integers and so on. Clearly, the following is a valid JSON text and will be parsed successfully by any JSON parser. { "foo": 3.0 } I imagine that most schema-driven software would first deserialize it into a tree, probably something like Jackson ObjectMapper's JsonNode, and then apply schema constructs to the tree. I would hope that a sane schema would accept this whether a top-level "foo" was required to be an integer or double or most other flavors of number, and reject it if "foo" was required to be a string or boolean. Put another way, no JSON schema spec can change the definition of what JSON is, or make the built-in type system anything but what it is. On Fri, May 3, 2019 at 4:59 PM Ulysse Carion wrote: > Hello all, > > I have recently published an I-D for what I'm calling JSON Schema > Language, a way to validate JSON data's shape, and generate code > (i.e., types, classes, docs, etc.) from that shape: > > https://tools.ietf.org/html/draft-json-schema-language-00 > > In previous correspondence with this list, Carsten Bormann has noted > that this WG has hesitated to prematurely adopt any given proposal, > preferring to let them develop until their distinct applications > become clear. > > It is my belief that JSON Schema Language does have a clear use-case, > one which Tim Bray has articulated clearly here: > > https://www.tbray.org/ongoing/When/201x/2018/09/22/JSON-scheming > > I believe JSON Schema Language solves precisely what Tim describes, > while eschewing his concerns with the json-schema.org project. > > For those inclined toward the concrete, the bottom of this page > contains a live demo of JSON Schema Language using the TypeScript > implementation: > > https://json-schema-language.github.io/ > > The project's GitHub organization also contains the source for a Rust > and TypeScript implementation, as well as a full test suite: > > https://github.com/json-schema-language > > With Carsten's note in mind, does there nevertheless exist a path for > JSON Schema Language, or something like it, to become an RFC? I > appreciate the desire to avoid premature adoption by this WG. I assume > this partially stems from caution around throwing the weight of > json@ietf.org behind any given specification. Perhaps some other path > to specification exists? > > With kind regards, > Ulysse Carion > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --0000000000007ed5eb05883fc22f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi = all.=C2=A0 I haven't got around to reading the draft (but will soon).= =C2=A0 Prior to that, a few notes:

1. I'm pretty sure that we need something better than what we= have in the area of JSON schemas.=C2=A0 At least, I'm 100% sure that m= y job at Amazon Web Services would be easier, and our customer experiences = would be more pleasant, if we had something.

2. One thing schemas are useful for is to syntax-check = JSON texts that claim to conform to some language specification or another.= Obviously no schema can ever completely satisfy this requirement - there a= re always things in specifications which are semantic and not addressable b= y schemas - but they can still be super useful.

3. Another thing they are useful for is for providin= g help to developers working in strongly typed programming languages. With = a well-built schema it is reasonably straightforward to auto-generate nice = idiomatic class declarations in modern programming languages, and also to b= uild serializers/deserializers that will move data back and forth between J= SON blobs and programming-language constructs, or fail in a clean determini= stic way if the JSON fails to match the schema.=C2=A0

I mostly fail to understand the debate a= bout jq and integers and so on.=C2=A0 Clearly, the following is a valid JSO= N text and will be parsed successfully by any JSON parser.

{
=C2=A0 "foo": 3.0
}

I imagine that most schema-driven softwa= re would first deserialize it into a tree, probably something like Jackson = ObjectMapper's JsonNode, and then apply schema constructs to the tree.= =C2=A0=C2=A0 I would hope that a sane schema would accept this whether a to= p-level "foo" was required to be an integer or double or most oth= er flavors of number, and reject it if "foo" was required to be a= string or boolean.

Put a= nother way, no JSON schema spec can change the definition of what JSON is, = or make the built-in type system anything but what it is.





On Fri, May 3, 2019 at 4:59 PM Ulysse Carion <<= a href=3D"mailto:ulysse@segment.com">ulysse@segment.com> wrote:
<= /div>
Hello all,

I have recently published an I-D for what I'm calling JSON Schema
Language, a way to validate JSON data's shape, and generate code
(i.e., types, classes, docs, etc.) from that shape:

https://tools.ietf.org/html/draft-json-sc= hema-language-00

In previous correspondence with this list, Carsten Bormann has noted
that this WG has hesitated to prematurely adopt any given proposal,
preferring to let them develop until their distinct applications
become clear.

It is my belief that JSON Schema Language does have a clear use-case,
one which Tim Bray has articulated clearly here:

https://www.tbray.org/ongoing/When/2= 01x/2018/09/22/JSON-scheming

I believe JSON Schema Language solves precisely what Tim describes,
while eschewing his concerns with the json-schema.org project.

For those inclined toward the concrete, the bottom of this page
contains a live demo of JSON Schema Language using the TypeScript
implementation:

https://json-schema-language.github.io/

The project's GitHub organization also contains the source for a Rust and TypeScript implementation, as well as a full test suite:

https://github.com/json-schema-language

With Carsten's note in mind, does there nevertheless exist a path for JSON Schema Language, or something like it, to become an RFC? I
appreciate the desire to avoid premature adoption by this WG. I assume
this partially stems from caution around throwing the weight of
json@ietf.org behind= any given specification. Perhaps some other path
to specification exists?

With kind regards,
Ulysse Carion

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--0000000000007ed5eb05883fc22f-- From nobody Mon May 6 21:40: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 A0C1912002F for ; Mon, 6 May 2019 21:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 PExKZQTJkSKe for ; Mon, 6 May 2019 21:40:21 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 99736120020 for ; Mon, 6 May 2019 21:40:21 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id q65so22791426itg.2 for ; Mon, 06 May 2019 21:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=CxnHHdFPKYw7oy/JeSo6A69fiqjuhB03mNzbogjOEW0=; b=2JhzSU/FNpRog/rT7dv34wu+sFM7bRWqbHoOtyF6Vs6FNyiKbeoDIgcWCBt2l4C5E9 XhIB5df4774DVV7H4hFSZnkUUXspwKOW1NY9oI2m2FQgVV0OHl8zKupVSFO4sY38K/NO 4kK3hS087oOFRU0byPxY5tQaC+UlryyaSO2d/3oH/+58HDJDx4zsWF1Akdz/RJcfQAmS 2yzeusxQHlNlUuMnck0OvG9aSXFeFIiodsDy/O5dewHC2+bLnYRX+AeWiUMiQF0MFq0R hMxg30XWP6pq4GSUnyefIvxh+sW3FVO0d4SwgC8eoUTuxQUB0RLcm9FYFdii3ZI6lVZX +Fxw== 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=CxnHHdFPKYw7oy/JeSo6A69fiqjuhB03mNzbogjOEW0=; b=ShbdUsoLleX6emaJ1sFFM58d/8+RarS7W7NpMCG/Ig8VXvsB1iF+2EbY4KKSNHFWDe /7ZCFtXdkOM9zb9uNwBd83Iwwyj4+UCfZ8G27qftrTBnK+hWNNl38ryPcTKEgmcBxpg0 OtReTYbMRMpgpvyPQfMdY/Hg4QpAXq4yvUpB0imikXJyRoUPKqrV4laUVbgo9XG6rAyl OZCI6Oi6OCOmR0G3ryBViGyxZZd+xVu3sMbM+BsyLKCcwa37spYe7uQLj/KG9rqJWl3g MkgJo4ihsT5uqMH/01chWiiKjP073xYnc2wQl0GlmGIy67Se2WsqvHjbAKPtU0I6JiOU xZbA== X-Gm-Message-State: APjAAAW8tWBbbvxsa2Lv+6NRmmJr+Ss5DvrP0GmcztAFQxbSR9thzu74 GmQjVs9ayUzM3clZ8Mbu0/kcPtUuESfvqKauONUcgQ== X-Google-Smtp-Source: APXvYqzDUzpF9+NqltUpcOPhooDFs7tNgzGu3XlNnKrA3Cy90J/bJ8AI2/wlZkkwJul/nW2nin1I3Cs0IRRHMbW4aX0= X-Received: by 2002:a24:6b4b:: with SMTP id v72mr20730293itc.174.1557204020757; Mon, 06 May 2019 21:40:20 -0700 (PDT) MIME-Version: 1.0 From: Tim Bray Date: Mon, 6 May 2019 21:40:09 -0700 Message-ID: To: Ulysse Carion , json@ietf.org Content-Type: multipart/alternative; boundary="00000000000080168b058844d0d7" Archived-At: Subject: [Json] Notes on json-schema-language-00 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, 07 May 2019 04:40:24 -0000 --00000000000080168b058844d0d7 Content-Type: text/plain; charset="UTF-8" I've now had time to give the draft a read. I think it shows promise and would be useful in meeting needs I'm currently facing at work. I'd like to talk it over and if we can move it forward a bit and get significant community support for a revised draft, would be interested in proposing we spin up a WG to see if there's IETF consensus to be had, and in volunteering to invest cycles to help with the process. If anyone objects to using this mailing list for such a conversation, please say so. Obviously since it's on github we could file issues there if that's what people would prefer. Ulysse, if we do have such a discussion, please don't charge off and start revising your draft; it's helpful to keep the document stable for a while while we figure out whether there's consensus. First, a question: I'm a little out of touch with the json-schema work. Is this designed to be a compatible subset? Or is there any other relationship? Depending on the answer, we might want to consider a name for this other than "JSON Schema Language". Some things to discuss: 1. There are problems with JSON terminology; "JSON text", "field", "name"/"value", "corresponding". But these are easy to fix. 2. I'd consider enriching the type range a bit, we don't have to stick strictly with JSON's impoverished diet 1. In 4.1, I think it'd be useful to specify integer/float, bearing in mind the reasonableness in behavior discussed in the intro thread. 2. I'd add a timestamp type (RFC3339 strings) 3. I'd really want to add an enum type (constraint on JSON string value) 3. I'd introduce lots of examples early in section 4, to show how each of the keywords might be used. 4. In 4.4, I suggest the URI reference resolution procedure is way too complicated, and needn't involve the "id" element at all. 5. Probably error objects should allow extra fields such as line/column numbers and human-readable explanations of what went wrong. --00000000000080168b058844d0d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've now had time to give the draft a read.=C2=A0 I think= it shows promise and would be useful in meeting needs I'm currently fa= cing at work.=C2=A0 I'd like to talk it over and if we can move it=C2= =A0forward a bit and get significant community support for a revised draft,= would be interested in proposing we spin up a WG to see if there's IET= F consensus to be had, and in volunteering to invest cycles to help with th= e process.=C2=A0 If anyone objects to using this mailing list for such a co= nversation, please say so.=C2=A0 Obviously since it's on github we coul= d file issues there if that's what people would prefer.

Ulysse, if we do have such a discussion,= please don't charge off and start revising your draft; it's helpfu= l to keep the document stable for a while while we figure out whether there= 's consensus.

First, = a question: I'm a little out of touch with the json-schema work.=C2=A0 = Is this designed to be a compatible subset?=C2=A0 Or is there any other rel= ationship?=C2=A0 Depending on the answer, we might want to consider a name = for this other than "JSON Schema Language".

Some things to discuss:
  1. There are problems with JSON = terminology; "JSON text", "field", "name"/&qu= ot;value", "corresponding". But these are easy to fix.
    2. <= li>I'd consider enriching the type range a bit, we don't have to st= ick strictly with JSON's impoverished diet
    1. In 4.1, I th= ink it'd be useful to specify integer/float, bearing in mind the reason= ableness in behavior discussed in the intro thread.=C2=A0=C2=A0
    2. I&#= 39;d add a timestamp type (RFC3339 strings)
    3. I'd really want to = add an enum type (constraint on JSON string value)
  2. I'd int= roduce lots of examples early in section 4, to show how each of the keyword= s might be used.=C2=A0
  3. In 4.4, I suggest the URI reference resoluti= on procedure is way too complicated, and needn't involve the "id&q= uot; element at all.
  4. Probably error objects should allow extra fiel= ds such as line/column numbers and human-readable explanations of what went= wrong.
--00000000000080168b058844d0d7-- From nobody Mon May 6 21:45: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 70441120041 for ; Mon, 6 May 2019 21:45:01 -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_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 6TDp7ACdw0g2 for ; Mon, 6 May 2019 21:44:58 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 B866C120020 for ; Mon, 6 May 2019 21:44:57 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id s15so20175065wra.12 for ; Mon, 06 May 2019 21:44:57 -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; bh=Tdp51dPUriLJ4v14RSv+di7qcvVkwmx+rmvj/1POEb0=; b=QbgjnybIKFe8R0nwfBv8QFTn8QvTmttN4Tb+HyJp/jDll97PzBzGEpCCew8HC7PBTw ACb7NqzjGQgXl3U/ss20LS1tftJJ2JVhRvvXbs7rUk76tQ+BCE/cFzp8WSDH0gwe4LjW y3acqdC2wF5XymK1UwPY8+UDFKGCUuIxPz3ZZDWffv1Qgm7aqEmRoMOllspKASDffR9G g+3nwf7i318AW5HbYtZsUrBT2iyPx7QNLEHCOp4ha1EPXjmh2N3hlIuedWLX3ye/RCtS IA/4KswumEHYOlwQCaaKqWYhNV9T6Vvt9eKPLOk41W5A7PDVQ1XV16ICx72G87H9wgFI JPDw== 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; bh=Tdp51dPUriLJ4v14RSv+di7qcvVkwmx+rmvj/1POEb0=; b=Y9wQXpvhMh+m5Vt/Iq3t9A6eroBRx9OSvIy5oqE2jYFnUA1me4ZaWideztO3+I5K8g Qa3FINB9ZaVbM935oZRH5xh2b8LihekiSxhO/ha1yRSZnNWLze5+6R4r2wcHV8ZsKJwQ zBOkAlnpVilzaHPy8mTDE6LbMjxeldSS33epEBUpUVKMZgDLic+e2CIRB0eETKstujdg NZFHmwDqFFz6F9DNED+qROLnk7hzelck2hBM5ANglfv8Z7TZrH/idz5XkUbDHZghTLWg OF3zMUknEbNJOi81BDEW6lV4jXpG/Pa83+J1VGvOUwTfmlDLFSGd8T0P+oblLZbNDABL PgxQ== X-Gm-Message-State: APjAAAUvAoY2NTfgE27eehdLP3jn88cD+IKLYkdBVQwLQ8bywxGNTfXj Wdxgzw0qg2KRUlYE7KCYr353OTVhBWE= X-Google-Smtp-Source: APXvYqyMGYC/pgUwAOAg9OQ7kEV5iOwoj7BgwZXbYoTkGn0+dsDPbj+8dsud1Plyp6lQrsX1FwROiw== X-Received: by 2002:a5d:55cb:: with SMTP id i11mr21697256wrw.187.1557204295632; Mon, 06 May 2019 21:44:55 -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 b10sm24075005wme.25.2019.05.06.21.44.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 May 2019 21:44:54 -0700 (PDT) To: Tim Bray Cc: json@ietf.org References: From: Anders Rundgren Message-ID: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> Date: Tue, 7 May 2019 06:44:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8E11B453707C4D4030DFB65B" Content-Language: en-US Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 04:45:02 -0000 This is a multi-part message in MIME format. --------------8E11B453707C4D4030DFB65B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2019-05-07 00:38, Tim Bray wrote: > Hi all.  I haven't got around to reading the draft (but will soon). Prior to that, a few notes: > > 1. I'm pretty sure that we need something better than what we have in the area of JSON schemas.  At least, I'm 100% sure that my job at Amazon Web Services would be easier, and our customer experiences would be more pleasant, if we had something. +1 > > 2. One thing schemas are useful for is to syntax-check JSON texts that claim to conform to some language specification or another. Obviously no schema can ever completely satisfy this requirement - there are always things in specifications which are semantic and not addressable by schemas - but they can still be super useful. +1 > > 3. Another thing they are useful for is for providing help to developers working in strongly typed programming languages. With a well-built schema it is reasonably straightforward to auto-generate nice idiomatic class declarations in modern programming languages, and also to build serializers/deserializers that will move data back and forth between JSON blobs and programming-language constructs, or fail in a clean deterministic way if the JSON fails to match the schema. +1 > > I mostly fail to understand the debate about jq and integers and so on. Clearly, the following is a valid JSON text and will be parsed successfully by any JSON parser. > > { >   "foo": 3.0 > } > > I imagine that most schema-driven software would first deserialize it into a tree, probably something like Jackson ObjectMapper's JsonNode, and then apply schema constructs to the tree.   I would hope that a sane schema would accept this whether a top-level "foo" was required to be an integer or double or most other flavors of number, and reject it if "foo" was required to be a string or boolean. Here we have a little problem.  There are already quite popular parsers out there flagging 3.0 as an invalid integer when explicitly parsing for an integer[*].  Personally, I consider this as right thing to do in a schema as well.  Letting one or two rotten eggs (=JSON serializers that output Numbers that also represent exact integers with fractions) set the bar for the other 99.9% doesn't seem right to me. > > Put another way, no JSON schema spec can change the definition of what JSON is, or make the built-in type system anything but what it is. I don't think anybody is actually proposing that; only mapping things that doesn't have a specific representation in JSON like integers. Anders *] When for example deserializing JSON into a class definition ("unmarshalling") containing an integer property. > > > > > > On Fri, May 3, 2019 at 4:59 PM Ulysse Carion > wrote: > > Hello all, > > I have recently published an I-D for what I'm calling JSON Schema > Language, a way to validate JSON data's shape, and generate code > (i.e., types, classes, docs, etc.) from that shape: > > https://tools.ietf.org/html/draft-json-schema-language-00 > > In previous correspondence with this list, Carsten Bormann has noted > that this WG has hesitated to prematurely adopt any given proposal, > preferring to let them develop until their distinct applications > become clear. > > It is my belief that JSON Schema Language does have a clear use-case, > one which Tim Bray has articulated clearly here: > > https://www.tbray.org/ongoing/When/201x/2018/09/22/JSON-scheming > > I believe JSON Schema Language solves precisely what Tim describes, > while eschewing his concerns with the json-schema.org project. > > For those inclined toward the concrete, the bottom of this page > contains a live demo of JSON Schema Language using the TypeScript > implementation: > > https://json-schema-language.github.io/ > > The project's GitHub organization also contains the source for a Rust > and TypeScript implementation, as well as a full test suite: > > https://github.com/json-schema-language > > With Carsten's note in mind, does there nevertheless exist a path for > JSON Schema Language, or something like it, to become an RFC? I > appreciate the desire to avoid premature adoption by this WG. I assume > this partially stems from caution around throwing the weight of > json@ietf.org behind any given specification. Perhaps some other path > to specification exists? > > With kind regards, > Ulysse Carion > > _______________________________________________ > 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 --------------8E11B453707C4D4030DFB65B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2019-05-07 00:38, Tim Bray wrote:
Hi all.  I haven't got around to reading the draft (but will soon).  Prior to that, a few notes:

1. I'm pretty sure that we need something better than what we have in the area of JSON schemas.  At least, I'm 100% sure that my job at Amazon Web Services would be easier, and our customer experiences would be more pleasant, if we had something.
+1

2. One thing schemas are useful for is to syntax-check JSON texts that claim to conform to some language specification or another. Obviously no schema can ever completely satisfy this requirement - there are always things in specifications which are semantic and not addressable by schemas - but they can still be super useful.
+1

3. Another thing they are useful for is for providing help to developers working in strongly typed programming languages. With a well-built schema it is reasonably straightforward to auto-generate nice idiomatic class declarations in modern programming languages, and also to build serializers/deserializers that will move data back and forth between JSON blobs and programming-language constructs, or fail in a clean deterministic way if the JSON fails to match the schema. 
+1

I mostly fail to understand the debate about jq and integers and so on.  Clearly, the following is a valid JSON text and will be parsed successfully by any JSON parser.

{
  "foo": 3.0
}

I imagine that most schema-driven software would first deserialize it into a tree, probably something like Jackson ObjectMapper's JsonNode, and then apply schema constructs to the tree.   I would hope that a sane schema would accept this whether a top-level "foo" was required to be an integer or double or most other flavors of number, and reject it if "foo" was required to be a string or boolean.

Here we have a little problem.  There are already quite popular parsers out there flagging 3.0 as an invalid integer when explicitly parsing for an integer[*].  Personally, I consider this as right thing to do in a schema as well.  Letting one or two rotten eggs (=JSON serializers that output Numbers that also represent exact integers with fractions) set the bar for the other 99.9% doesn't seem right to me.


Put another way, no JSON schema spec can change the definition of what JSON is, or make the built-in type system anything but what it is.

I don't think anybody is actually proposing that; only mapping things that doesn't have a specific representation in JSON like integers.

Anders

*] When for example deserializing JSON into a class definition ("unmarshalling") containing an integer property.






On Fri, May 3, 2019 at 4:59 PM Ulysse Carion <ulysse@segment.com> wrote:
Hello all,

I have recently published an I-D for what I'm calling JSON Schema
Language, a way to validate JSON data's shape, and generate code
(i.e., types, classes, docs, etc.) from that shape:

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

In previous correspondence with this list, Carsten Bormann has noted
that this WG has hesitated to prematurely adopt any given proposal,
preferring to let them develop until their distinct applications
become clear.

It is my belief that JSON Schema Language does have a clear use-case,
one which Tim Bray has articulated clearly here:

https://www.tbray.org/ongoing/When/201x/2018/09/22/JSON-scheming

I believe JSON Schema Language solves precisely what Tim describes,
while eschewing his concerns with the json-schema.org project.

For those inclined toward the concrete, the bottom of this page
contains a live demo of JSON Schema Language using the TypeScript
implementation:

https://json-schema-language.github.io/

The project's GitHub organization also contains the source for a Rust
and TypeScript implementation, as well as a full test suite:

https://github.com/json-schema-language

With Carsten's note in mind, does there nevertheless exist a path for
JSON Schema Language, or something like it, to become an RFC? I
appreciate the desire to avoid premature adoption by this WG. I assume
this partially stems from caution around throwing the weight of
json@ietf.org behind any given specification. Perhaps some other path
to specification exists?

With kind regards,
Ulysse Carion

_______________________________________________
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

--------------8E11B453707C4D4030DFB65B-- From nobody Mon May 6 23:23:06 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 31A7412006B for ; Mon, 6 May 2019 23:23:04 -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_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 LikkCzg3Nfyy for ; Mon, 6 May 2019 23:23:02 -0700 (PDT) Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (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 8A552120020 for ; Mon, 6 May 2019 23:23:02 -0700 (PDT) Received: by mail-it1-x141.google.com with SMTP id l140so23969852itb.0 for ; Mon, 06 May 2019 23:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QDsY5CwMo1oBQRDxcapHGPto7NmMpVtU3zEWKyO2bxA=; b=JM3hWxDe5VzpwHho7nOA9idsyxpQTX39CWJkFidYUldBTdY47Z1/We/QnkcLhA/t1R q+UR3zBELjzJr+pfgrNGYE7wORBWJbXpERfH1spWM/tW/qb0IzxBbTdp8zjfUL2YtNpz loRIngQl1/0T6762EwnX1o76v13iF4YS/9gSgwZrRx5cq5OSmmy6yOvxsFo5GEqQCSBH L+6bMRvxuB5R08GFI2u1o1TPdfUWNHah6wjyKetvlasnIsCeGBWsv4dPcN5QGU4c0ZWV Q6rDbWIwYHT9buJTLqatmyUZ7A9OrLND3KOiTipvccUcVnOC7jY0WtP02anOn0ilkqRq hIWA== 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=QDsY5CwMo1oBQRDxcapHGPto7NmMpVtU3zEWKyO2bxA=; b=UKMg6gnTiqYPIDPdRowiYRYPSiy3aWF/wuC14Nf8+ENKGL4i/j8crBOv27waQ/Dd1L PkTz3UN+CClCsLcqZHTnplQczlGZfeqh52iE+jgWfjZa1j6hg2xkn9Pxjb8p8dNAo2yz wtzlEO01sZv/1crRrZL+tWVlIZMDfkR5nKYDNvXv0u0qEJ6omYJ7SkyCw9mNJW9zN8Kq YEnOH8YE4P/zlfGl8pMM9Lifc7H9C5SZDH9hcGWKUmh8yBI4n4qJqRlgKwm3R9lDiKRS z07tyoHIwxjIY3DPztj9MvytJQRmIT03XvgjggcUW2X7myF6aeBg/niL0ArJg4bFjIVD OkwA== X-Gm-Message-State: APjAAAV4H1Bg2vfppCT+qB8Bd2wBVAtqKEHovrcvAH5j8KcvKVgCR+QJ EsB/1tSZkdXTjkaAuFUyzmqgyMeoCSApa+VidMg= X-Google-Smtp-Source: APXvYqz7RPRPK9uYBcasdCA0YbhlYCVoQP1e63dcTqwBWayud8ucVkKsr+ioXXwbAIWMLYVX9u5n8mKEfOe8//PXTcs= X-Received: by 2002:a24:6110:: with SMTP id s16mr22485713itc.169.1557210181715; Mon, 06 May 2019 23:23:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Mon, 6 May 2019 23:22:50 -0700 Message-ID: To: Tim Bray Cc: Ulysse Carion , json@ietf.org Content-Type: multipart/alternative; boundary="000000000000b8cdda0588463f7d" Archived-At: Subject: Re: [Json] Notes on json-schema-language-00 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, 07 May 2019 06:23:04 -0000 --000000000000b8cdda0588463f7d Content-Type: text/plain; charset="UTF-8" Would a JSON message with such a schema be self-describing? If not, what benefit would this scheme provide over Thrift or Protobuf? It seems like it would be strictly worse. - Rob On Mon, May 6, 2019 at 9:40 PM Tim Bray wrote: > I've now had time to give the draft a read. I think it shows promise and > would be useful in meeting needs I'm currently facing at work. I'd like to > talk it over and if we can move it forward a bit and get significant > community support for a revised draft, would be interested in proposing we > spin up a WG to see if there's IETF consensus to be had, and in > volunteering to invest cycles to help with the process. If anyone objects > to using this mailing list for such a conversation, please say so. > Obviously since it's on github we could file issues there if that's what > people would prefer. > > Ulysse, if we do have such a discussion, please don't charge off and start > revising your draft; it's helpful to keep the document stable for a while > while we figure out whether there's consensus. > > First, a question: I'm a little out of touch with the json-schema work. > Is this designed to be a compatible subset? Or is there any other > relationship? Depending on the answer, we might want to consider a name > for this other than "JSON Schema Language". > > Some things to discuss: > > 1. There are problems with JSON terminology; "JSON text", "field", > "name"/"value", "corresponding". But these are easy to fix. > 2. I'd consider enriching the type range a bit, we don't have to stick > strictly with JSON's impoverished diet > 1. In 4.1, I think it'd be useful to specify integer/float, bearing in > mind the reasonableness in behavior discussed in the intro thread. > 2. I'd add a timestamp type (RFC3339 strings) > 3. I'd really want to add an enum type (constraint on JSON string > value) > 3. I'd introduce lots of examples early in section 4, to show how each > of the keywords might be used. > 4. In 4.4, I suggest the URI reference resolution procedure is way too > complicated, and needn't involve the "id" element at all. > 5. Probably error objects should allow extra fields such as > line/column numbers and human-readable explanations of what went wrong. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --000000000000b8cdda0588463f7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would a JSON message with such a schema be self-descr= ibing? If not, what benefit would this scheme provide over Thrift or Protob= uf? It seems like it would be strictly worse.

- Ro= b

On Mon, May 6, 2019 at 9:40 PM Tim Bray <tbray@textuality.com> wrote:
I've now had time to give the draft a read.=C2=A0 = I think it shows promise and would be useful in meeting needs I'm curre= ntly facing at work.=C2=A0 I'd like to talk it over and if we can move = it=C2=A0forward a bit and get significant community support for a revised d= raft, would be interested in proposing we spin up a WG to see if there'= s IETF consensus to be had, and in volunteering to invest cycles to help wi= th the process.=C2=A0 If anyone objects to using this mailing list for such= a conversation, please say so.=C2=A0 Obviously since it's on github we= could file issues there if that's what people would prefer.

Ulysse, = if we do have such a discussion, please don't charge off and start revi= sing your draft; it's helpful to keep the document stable for a while w= hile we figure out whether there's consensus.

First, a question: I= 9;m a little out of touch with the json-schema work.=C2=A0 Is this designed= to be a compatible subset?=C2=A0 Or is there any other relationship?=C2=A0= Depending on the answer, we might want to consider a name for this other t= han "JSON Schema Language".
<= br>
Some things to discuss:
  1. There are problems with JSON terminology; = "JSON text", "field", "name"/"value"= ;, "corresponding". But these are easy to fix.
  2. I'd co= nsider enriching the type range a bit, we don't have to stick strictly = with JSON's impoverished diet
    1. In 4.1, I think it'd = be useful to specify integer/float, bearing in mind the reasonableness in b= ehavior discussed in the intro thread.=C2=A0=C2=A0
    2. I'd add a ti= mestamp type (RFC3339 strings)
    3. I'd really want to add an enum t= ype (constraint on JSON string value)
  3. I'd introduce lots o= f examples early in section 4, to show how each of the keywords might be us= ed.=C2=A0
  4. In 4.4, I suggest the URI reference resolution procedure = is way too complicated, and needn't involve the "id" element = at all.
  5. Probably error objects should allow extra fields such as li= ne/column numbers and human-readable explanations of what went wrong.
    6. <= /ol>
_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--000000000000b8cdda0588463f7d-- From nobody Mon May 6 23:33: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 D9F0B120072 for ; Mon, 6 May 2019 23:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jd2a0la6USB for ; Mon, 6 May 2019 23:32:59 -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 7736512006B for ; Mon, 6 May 2019 23:32:59 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id z4so6637276iol.0 for ; Mon, 06 May 2019 23:32:59 -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:content-transfer-encoding; bh=NnWhYbxB9HGPIoqYYm+SOEEdwzdvd1Rk8tgUNFRcEw4=; b=VprozN07gsKzafd0FXbRG6tC97vQSdBUJGu3rbE/StpigO74na37WXPAnESxfRDGuF o7NIRKQWOSvmK8tWCIq5nDrrRYGjLcvqIiMngn3jtUJKih9wiwdDEPq/WLEfGlUVmEnX 08ukoggazpANSAdWb++LCjFS/DrpuSj2/Z1RM= 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=NnWhYbxB9HGPIoqYYm+SOEEdwzdvd1Rk8tgUNFRcEw4=; b=i6BtJPRfi8j48Wp//hXrYqcCGObwCc0HnssQwrfBg4CodEkjmyeK50foAG4hMAK2Dm QwTB/VzbssMMk//8REg1+p/q6mXJnNhr/ayNWENiU8gSacZIdS9DgW+62RvOwtUPO7VW p2Vxpl2DZCw5QV15aZ6XDgdoXP2cUt2w+mw2YHiicrXj5Z5vTUTgilipDszbD0iaD1UO hieht9R2vWGVFnWNspH91UlMieHqXYKFPPvf5g0fZ/Ml/fnASYoF0q+WcsQ4ONA9JJ6Z J+dVPp8ACAnvYMb/vV+rzHR9AX/7WZjBOL7xT0KEexff0ExT4/RMUAroNVtf60Zt50ID Fc5Q== X-Gm-Message-State: APjAAAXZDNOvDGJf6cnDFNRcfF5XrBjzcGN1/qwiNIcMXN8ztUH9J/I5 VN2SZ6aqlzmle41f2KFHa8c2n8S5JPmuMYgitRjUG4o9SHw= X-Google-Smtp-Source: APXvYqw+d5lQyVYJxKul+xNiFFwKsA4ehf9WLglwGQe+FPsCj/BnwCE+7Dako+SHE4+cmsqQIKcrvQnkzcIEKkR8A8Y= X-Received: by 2002:a6b:b7ce:: with SMTP id h197mr14797557iof.169.1557210778503; Mon, 06 May 2019 23:32:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulysse Carion Date: Mon, 6 May 2019 23:32:47 -0700 Message-ID: To: Tim Bray Cc: json@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] Notes on json-schema-language-00 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, 07 May 2019 06:33:02 -0000 On your direct comments to me: > Ulysse, if we do have such a discussion, please don't charge off and star= t revising your draft; it's helpful to keep the document stable for a while= while we figure out whether there's consensus. You got it. The document will remain stable. > First, a question: I'm a little out of touch with the json-schema work. = Is this designed to be a compatible subset? Or is there any other relation= ship? Depending on the answer, we might want to consider a name for this o= ther than "JSON Schema Language". No, it is not meant to be a compatible subset. There is no formal relationship between the two projects, although I have contributed to both. In the interest of not letting the perfect be the enemy of the good, I simply chose the most apt name I could think of. I agree that "JSON Schema Language" will likely provoke confusion, and that it may require a renaming. On the broader points: > There are problems with JSON terminology; "JSON text", "field", "name"/"v= alue", "corresponding". But these are easy to fix. Agreed. Loosely speaking, I suspect there's a sort of linguistic yoga which I didn't manage to muster in the I-D's language. Hopefully the intention is clear, and I trust the language can be tightened. All three of your suggested extensions were originally in the first draft, but I ultimately cut them out to produce a sort of minimum viable proposal which didn't extend JSON at all, just to keep it simple at first. 1. On integers: the use-case likely will be to produce the equivalent of an integer in some programming language, no? If so, would we need to restrict data further, to perhaps (u)int(64, 32, 16, 8)? 2. On timestamps: I agree that RFC 3339 is the enlightened choice of timestamps, and that their validation is part of the tedium that is checking JSON validity for APIs. But we are bound to disappoint some by choosing this format at the expense of others. I think a case can be made that validating timestamps is an applicative, not a schema, concern. 3. On enums: I agree that these are desirable. They were dropped at the last minute because I wanted to at first ship something that didn't extend JSON at all. As long as we limit ourselves to enums of strings, that is -- I'm skeptical of numerical or other sorts of enums being worth adding. I ultimately think these would all be valuable extensions. But I would urge restraint in going any further. The language shouldn't have constructs any more powerful than the average, non-exotic type system. on my view. > I'd introduce lots of examples early in section 4, to show how each of th= e keywords might be used. I agree that there's a dearth of examples in the opening. My concern was that the examples would ultimately be mostly redundant with examples in the validation section. But happy to change that if we desire. > In 4.4, I suggest the URI reference resolution procedure is way too compl= icated, and needn't involve the "id" element at all. Agreed that it's complicated. What would you propose as an alternative? Should inter-document references still be possible? Perhaps the "id" element is omitted, and instead this information is provided out-of-band? > Probably error objects should allow extra fields such as line/column numb= ers and human-readable explanations of what went wrong. If the document precludes such additional fields, then that is a mistake. Error messages should be so extensible, but I don't think we should formalize any extensions at this time. On Mon, May 6, 2019 at 9:40 PM Tim Bray wrote: > > I've now had time to give the draft a read. I think it shows promise and= would be useful in meeting needs I'm currently facing at work. I'd like t= o talk it over and if we can move it forward a bit and get significant comm= unity support for a revised draft, would be interested in proposing we spin= up a WG to see if there's IETF consensus to be had, and in volunteering to= invest cycles to help with the process. If anyone objects to using this m= ailing list for such a conversation, please say so. Obviously since it's o= n github we could file issues there if that's what people would prefer. > > Ulysse, if we do have such a discussion, please don't charge off and star= t revising your draft; it's helpful to keep the document stable for a while= while we figure out whether there's consensus. > > First, a question: I'm a little out of touch with the json-schema work. = Is this designed to be a compatible subset? Or is there any other relation= ship? Depending on the answer, we might want to consider a name for this o= ther than "JSON Schema Language". > > Some things to discuss: > > There are problems with JSON terminology; "JSON text", "field", "name"/"v= alue", "corresponding". But these are easy to fix. > I'd consider enriching the type range a bit, we don't have to stick stric= tly with JSON's impoverished diet > > In 4.1, I think it'd be useful to specify integer/float, bearing in mind = the reasonableness in behavior discussed in the intro thread. > I'd add a timestamp type (RFC3339 strings) > I'd really want to add an enum type (constraint on JSON string value) > > I'd introduce lots of examples early in section 4, to show how each of th= e keywords might be used. > In 4.4, I suggest the URI reference resolution procedure is way too compl= icated, and needn't involve the "id" element at all. > Probably error objects should allow extra fields such as line/column numb= ers and human-readable explanations of what went wrong. From nobody Tue May 7 08:42:13 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 B863112016E for ; Tue, 7 May 2019 08:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 Ss8IM94zaVjW for ; Tue, 7 May 2019 08:42:09 -0700 (PDT) Received: from eastern.maple.relay.mailchannels.net (eastern.maple.relay.mailchannels.net [23.83.214.55]) (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 D5C3C120144 for ; Tue, 7 May 2019 08:42:08 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id DDD158C28A0; Tue, 7 May 2019 15:42:07 +0000 (UTC) Received: from pdx1-sub0-mail-a48.g.dreamhost.com (100-96-79-4.trex.outbound.svc.cluster.local [100.96.79.4]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 3C9338C2576; Tue, 7 May 2019 15:42:07 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a48.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Tue, 07 May 2019 15:42:07 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Keen-Bored: 4864379d3b737830_1557243727722_93180319 X-MC-Loop-Signature: 1557243727722:1917675356 X-MC-Ingress-Time: 1557243727721 Received: from pdx1-sub0-mail-a48.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a48.g.dreamhost.com (Postfix) with ESMTP id 1254E7FD9D; Tue, 7 May 2019 08:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=Hg7Ogi/sQxeJm76mXmQx3AlfSho=; b=F8azpvkmjs6 nfyajSCtX27AQCoUDU8pLHmrfu/U7tYgAS0CrzIbu14GWph5njCQLfd9Ysv+ZVKF xMHjExblTge+CYlUpg9RsnBWq9VCCJM6iCygNUWboYG33snbJ0Yj56a1jf7ayQgW rB/bnZITaUd6gQWLRReiT7nm01nFce6Y= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a48.g.dreamhost.com (Postfix) with ESMTPSA id D92F77FD99; Tue, 7 May 2019 08:42:04 -0700 (PDT) Date: Tue, 7 May 2019 10:42:02 -0500 X-DH-BACKEND: pdx1-sub0-mail-a48 From: Nico Williams To: Anders Rundgren Cc: Tim Bray , json@ietf.org Message-ID: <20190507154201.GP21049@localhost> References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrkedtgdeljecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderudenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 15:42:11 -0000 On Tue, May 07, 2019 at 06:44:49AM +0200, Anders Rundgren wrote: > On 2019-05-07 00:38, Tim Bray wrote: > > I mostly fail to understand the debate about jq and integers and so > > on. Clearly, the following is a valid JSON text and will be parsed > > successfully by any JSON parser. > >=20 > > { > > =A0 "foo": 3.0 > > } > >=20 > > I imagine that most schema-driven software would first deserialize > > it into a tree, probably something like Jackson ObjectMapper's > > JsonNode, and then apply schema constructs to the tree.=A0=A0 I would > > hope that a sane schema would accept this whether a top-level "foo" > > was required to be an integer or double or most other flavors of > > number, and reject it if "foo" was required to be a string or > > boolean. >=20 > Here we have a little problem.=A0 There are already quite popular > parsers out there flagging 3.0 as an invalid integer when explicitly > parsing for an integer[*].=A0 Personally, I consider this as right thin= g > to do in a schema as well.=A0 Letting one or two rotten eggs (=3DJSON > serializers that output Numbers that also represent exact integers > with fractions) set the bar for the other 99.9% doesn't seem right to > me. Those parsers are broken. > > Put another way, no JSON schema spec can change the definition of > > what JSON is, or make the built-in type system anything but what it > > is. >=20 > I don't think anybody is actually proposing that; only mapping things > that doesn't have a specific representation in JSON like integers. Integers do have a specific representation in JSON, and anything that precludes generic encoders that might emit 10.0 where a peer parser will reject that as not-an-integer *is* a change to JSON. Nico --=20 From nobody Tue May 7 09:03:21 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 9DF6612017A for ; Tue, 7 May 2019 09:03:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 XngOln2HNhkj for ; Tue, 7 May 2019 09:03:17 -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 77A9C120176 for ; Tue, 7 May 2019 09:03:15 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id z4so7985342iol.0 for ; Tue, 07 May 2019 09:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fHXrJW/+UlskOKSRhCu3j2/WCoLJI74XGsT2r0HStQo=; b=OOSCdsfuC7ghB5oeNhOVQg7QRRxsRsHcjjEVm/Otz2a2FihWLoTbYCM3VYwDHOe6Nr xTDB78qm1W80SbYTzje4XGMUhUdcGiOljtldysv1h2LxJ8ehzrCzpUZ5Gspd+l+Y1ler jVeVNyh4ht58c/uaHjfxu3f4JvRXgEiQry9dgZyYftTIruCfaGai7ptrfKUu0b79g/pP y6Eyba1XrobuAT8vf4HYxzWl2YQDxPLZV94AGOc+kR5wDondI6J79Ny2oIaYlHlQ+gj/ ma7LBYlEdkg1ucSwAItwlXdzVXFAhKwQ6M55VDXMyEvTPI9nz1rI6PCCIi8QOJur0SL+ Lb1g== 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=fHXrJW/+UlskOKSRhCu3j2/WCoLJI74XGsT2r0HStQo=; b=K5Ryl8mXe1D/nwnH8Ch6iOEwx+iY6c939Ql/Dld3A6Tu/Au4jqLC2COufeexng2HyY q5NBWaWPNje13oJKVIlo1IFz/qeCytoEkbdrqAJ+7NIzYb1d/ZfhgjdJmFmOEB4kmePk AhJvQF1gZhMYR6jnhOKnocKR7VO8Ns1CbplVNSi9oNQom88NeptPiEeFo07k3giuz0O8 3Mu4kv8cW6cctjuVFxmreTb3ICoKr9+LqdPQk7/iWZBQahPyq12y83JhCe39MYXfXJZm MLp2J0AvFckbFTv1M9IaMf4RYx3DZnOwMbe9mEBNM9yTOO5hEisL44vGWmHGcwPh9j4C /XuQ== X-Gm-Message-State: APjAAAXA+zAXFjj4XXuilREAC5c/PWkO9XiFBWq69FDQr33tr9XDFLve 5p6RDJUEb35NSer8K2UtTQZ2QxjgxGIvwvvHILHGGA== X-Google-Smtp-Source: APXvYqxYcY/vC0pXOLYF3tyTsVHx6AszXItAkEney1Kn338O+jNTdUy4vGe3UXMZtkUexluirWPPFDAJ+Rwwt/ROMrw= X-Received: by 2002:a6b:ea12:: with SMTP id m18mr10325690ioc.173.1557244994587; Tue, 07 May 2019 09:03:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Tue, 7 May 2019 09:03:03 -0700 Message-ID: To: Rob Sayre Cc: Ulysse Carion , json@ietf.org Content-Type: multipart/alternative; boundary="000000000000bb270405884e5a68" Archived-At: Subject: Re: [Json] Notes on json-schema-language-00 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, 07 May 2019 16:03:20 -0000 --000000000000bb270405884e5a68 Content-Type: text/plain; charset="UTF-8" Last time I checked, MustIgnore was harder to implement in the binary formats. Is that still true? That matters for some of us. In any case, JSON remains the lingua franca for lots of APIs and event-driven systems, and upgrading its data typing a little seems worth doing for its own sake, since there would be substantial cost and effort involved in ripping it out and replacing it with anything else. Yes, I do really want to start imposing types retroactively on existing message streams. On Mon, May 6, 2019 at 11:23 PM Rob Sayre wrote: > Would a JSON message with such a schema be self-describing? If not, what > benefit would this scheme provide over Thrift or Protobuf? It seems like it > would be strictly worse. > > - Rob > > On Mon, May 6, 2019 at 9:40 PM Tim Bray wrote: > >> I've now had time to give the draft a read. I think it shows promise and >> would be useful in meeting needs I'm currently facing at work. I'd like to >> talk it over and if we can move it forward a bit and get significant >> community support for a revised draft, would be interested in proposing we >> spin up a WG to see if there's IETF consensus to be had, and in >> volunteering to invest cycles to help with the process. If anyone objects >> to using this mailing list for such a conversation, please say so. >> Obviously since it's on github we could file issues there if that's what >> people would prefer. >> >> Ulysse, if we do have such a discussion, please don't charge off and >> start revising your draft; it's helpful to keep the document stable for a >> while while we figure out whether there's consensus. >> >> First, a question: I'm a little out of touch with the json-schema work. >> Is this designed to be a compatible subset? Or is there any other >> relationship? Depending on the answer, we might want to consider a name >> for this other than "JSON Schema Language". >> >> Some things to discuss: >> >> 1. There are problems with JSON terminology; "JSON text", "field", >> "name"/"value", "corresponding". But these are easy to fix. >> 2. I'd consider enriching the type range a bit, we don't have to >> stick strictly with JSON's impoverished diet >> 1. In 4.1, I think it'd be useful to specify integer/float, bearing >> in mind the reasonableness in behavior discussed in the intro thread. >> 2. I'd add a timestamp type (RFC3339 strings) >> 3. I'd really want to add an enum type (constraint on JSON string >> value) >> 3. I'd introduce lots of examples early in section 4, to show how >> each of the keywords might be used. >> 4. In 4.4, I suggest the URI reference resolution procedure is way >> too complicated, and needn't involve the "id" element at all. >> 5. Probably error objects should allow extra fields such as >> line/column numbers and human-readable explanations of what went wrong. >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > --000000000000bb270405884e5a68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Las= t time I checked, MustIgnore was=C2=A0 harder to implement in the binary fo= rmats.=C2=A0 Is that still true?=C2=A0=C2=A0 That matters for some=C2=A0 of= us.

In any case, JSO= N remains the lingua franca for lots of APIs and event-driven systems, and = upgrading its data typing a little seems worth doing for its own sake, sinc= e there would be substantial cost and effort involved in ripping it out and= replacing it with anything else. Yes, I do really want to start imposing t= ypes retroactively on existing message streams.

On Mon, May 6, 201= 9 at 11:23 PM Rob Sayre <sayrer@gmai= l.com> wrote:
Would a JSON message with such a schema be self-= describing? If not, what benefit would this scheme provide over Thrift or P= rotobuf? It seems like it would be strictly worse.

- Rob

On Mon, May 6, 2019 at 9:40 PM Tim Bray <tbray@textuality.com> wrote:
I've now had time to give th= e draft a read.=C2=A0 I think it shows promise and would be useful in meeti= ng needs I'm currently facing at work.=C2=A0 I'd like to talk it ov= er and if we can move it=C2=A0forward a bit and get significant community s= upport for a revised draft, would be interested in proposing we spin up a W= G to see if there's IETF consensus to be had, and in volunteering to in= vest cycles to help with the process.=C2=A0 If anyone objects to using this= mailing list for such a conversation, please say so.=C2=A0 Obviously since= it's on github we could file issues there if that's what people wo= uld prefer.

Ulysse, if we do have such a discussion, please don't cha= rge off and start revising your draft; it's helpful to keep the documen= t stable for a while while we figure out whether there's consensus.

F= irst, a question: I'm a little out of touch with the json-schema work.= =C2=A0 Is this designed to be a compatible subset?=C2=A0 Or is there any ot= her relationship?=C2=A0 Depending on the answer, we might want to consider = a name for this other than "JSON Schema Language".

Some things = to discuss:
  1. There are problems = with JSON terminology; "JSON text", "field", "name= "/"value", "corresponding". But these are easy to = fix.
  2. I'd consider enriching the type range a bit, we don't = have to stick strictly with JSON's impoverished diet
    1. In= 4.1, I think it'd be useful to specify integer/float, bearing in mind = the reasonableness in behavior discussed in the intro thread.=C2=A0=C2=A0
    2. I'd add a timestamp type (RFC3339 strings)
    3. I'd reall= y want to add an enum type (constraint on JSON string value)
  3. I= 'd introduce lots of examples early in section 4, to show how each of t= he keywords might be used.=C2=A0
  4. In 4.4, I suggest the URI referenc= e resolution procedure is way too complicated, and needn't involve the = "id" element at all.
  5. Probably error objects should allow = extra fields such as line/column numbers and human-readable explanations of= what went wrong.
_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--000000000000bb270405884e5a68-- From nobody Tue May 7 09:05:52 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 1C9E012018B for ; Tue, 7 May 2019 09:05:50 -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_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 CafD5jiYY2eL for ; Tue, 7 May 2019 09:05:46 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 5E018120181 for ; Tue, 7 May 2019 09:05:46 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id s30so6216329uas.8 for ; Tue, 07 May 2019 09:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gt/tkBbMlGVX42gipGAJtvqHRy0OYgcX2RCX0e9eMrI=; b=RCJT2Xl20jbLFfBO1LzK9iEvjdDktg+VlHOnkrnDE0a+GoN29b3rOOcF3PJBgVkDpm Q9t7HOLX2i999oDpRIQ02x99uDNn9PK/YzOtt0taDb535aPTM33XrBiihAoXwiq0y3CQ YlnQ9++KqKI33GGha/jMRA6/0SC14kRsEtxDKXgYVeqodFbwpjLNhLsYzmHBIUQp96kZ gXFV71Quaw4R2YtnMnqEJpRwnuDntFYeL5W2SNvfUOaOCHozyra348dxsIiglfJBBxm3 e93g+1Chy0FD7bffJjCYL0UwQFeVHB/DAbzjuadzgXRg1gNdqlAYdHTQY/zV1giPMn/v fO4w== 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=Gt/tkBbMlGVX42gipGAJtvqHRy0OYgcX2RCX0e9eMrI=; b=sEWXbXutEhOxwBjksfXGxUpAPvpQ0mwztCB9w3hWtaaFTf0/ccrTIE8C/XjNew2o9z pI4sgGxSYoeE4qSMsc3DVvEIr72coYB0LmoHgyzJXFcu6DT1pwiBezo7bnOjQ4tQJ0+F ZIbBhbnNPxmL8I78KM+kJfPHH7/ZW8kpjBpiuHGznta1K/88jXWCSGQ++vbaKwBpvwtM LBwzcNLFkDPSOWI9W7luV+3yn7fgklgHJvP0kkOAyimD9SFjJFgY2mAaYiHBJ4mLFaR8 Gp/Bz+xARZfX7KJawnqR1avqBFrSJ4aAwMIRKZy0HwKE+IgP7bs490Wf5w9FhceKNJMg MkwQ== X-Gm-Message-State: APjAAAVoYxAN2AkFVpnzyLB6TTda0+IK3Rf3RRwHZtx7+r5wHn/gIp4P gCXQXPxZsOqMf7Vvd7H5xG3cMraGYszchUPoGHs= X-Google-Smtp-Source: APXvYqwhjqX0aLQBZQdI5JWVNxuqmMEfY12tFu9FiYd08pc6SmY/85mHJ96qPaeY4+jVu0N7I9GGNh8oSAp1gx7v2YU= X-Received: by 2002:ab0:30a1:: with SMTP id b1mr5489371uam.104.1557245144870; Tue, 07 May 2019 09:05:44 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> In-Reply-To: <20190507154201.GP21049@localhost> From: Peter Patel-Schneider Date: Tue, 7 May 2019 09:05:33 -0700 Message-ID: To: Nico Williams Cc: Anders Rundgren , Tim Bray , JSON WG Content-Type: multipart/alternative; boundary="000000000000b036d805884e637f" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 16:05:50 -0000 --000000000000b036d805884e637f Content-Type: text/plain; charset="UTF-8" I was looking through the JSON specification and nowhere could I find a reference to integers. That indicates to me that any conversion from JSON numbers to integers has to be done outside of JSON. Conformant implementations of JSON are thus free to do conversion from JSON numbers to integers in whatever way they want. There is a cost in doing the conversion differently than common JSON implementations do, but that is a different discussion. I could, if I wanted, use JSON numbers to represent inexact numbers where the precision of is +-1 in the last digit, so 4 is different from 4.0 is different from 4.000000. I have to be very careful that the only JSON texts I allow are ones that are created with this understanding of numbers, but I haven't done anything that violates the JSON specification. Peter F. Patel-Schneider On Tue, May 7, 2019 at 8:42 AM Nico Williams wrote: > On Tue, May 07, 2019 at 06:44:49AM +0200, Anders Rundgren wrote: > > On 2019-05-07 00:38, Tim Bray wrote: > > > I mostly fail to understand the debate about jq and integers and so > > > on. Clearly, the following is a valid JSON text and will be parsed > > > successfully by any JSON parser. > > > > > > { > > > "foo": 3.0 > > > } > > > > > > I imagine that most schema-driven software would first deserialize > > > it into a tree, probably something like Jackson ObjectMapper's > > > JsonNode, and then apply schema constructs to the tree. I would > > > hope that a sane schema would accept this whether a top-level "foo" > > > was required to be an integer or double or most other flavors of > > > number, and reject it if "foo" was required to be a string or > > > boolean. > > > > Here we have a little problem. There are already quite popular > > parsers out there flagging 3.0 as an invalid integer when explicitly > > parsing for an integer[*]. Personally, I consider this as right thing > > to do in a schema as well. Letting one or two rotten eggs (=JSON > > serializers that output Numbers that also represent exact integers > > with fractions) set the bar for the other 99.9% doesn't seem right to > > me. > > Those parsers are broken. > > > > Put another way, no JSON schema spec can change the definition of > > > what JSON is, or make the built-in type system anything but what it > > > is. > > > > I don't think anybody is actually proposing that; only mapping things > > that doesn't have a specific representation in JSON like integers. > > Integers do have a specific representation in JSON, and anything that > precludes generic encoders that might emit 10.0 where a peer parser will > reject that as not-an-integer *is* a change to JSON. > > Nico > -- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --000000000000b036d805884e637f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was looking through the JSON specification and nowh= ere could I find a reference to integers.=C2=A0 That indicates to me that a= ny conversion from JSON numbers to integers has to be done outside of JSON.= =C2=A0 Conformant implementations of JSON are thus free to do conversion fr= om JSON numbers to integers in whatever way they want.=C2=A0 There is a cos= t in doing the conversion differently than common JSON implementations do, = but that is a different discussion.

I could, if I = wanted, use JSON numbers to represent inexact numbers where the precision o= f is +-1 in the last digit, so 4 is different from 4.0 is different from 4.= 000000.=C2=A0 I have to be very careful that the only JSON texts I allow ar= e ones that are created with this understanding of numbers, but I haven'= ;t done anything that violates the JSON specification.

Peter F. Patel-Schneider



On Tue, May = 7, 2019 at 8:42 AM Nico Williams <nico@cryptonector.com> wrote:
On Tue, May 07, 2019 at 06:44:49AM +0200, Anders Ru= ndgren wrote:
> On 2019-05-07 00:38, Tim Bray wrote:
> > I mostly fail to understand the debate about jq and integers and = so
> > on. Clearly, the following is a valid JSON text and will be parse= d
> > successfully by any JSON parser.
> >
> > {
> > =C2=A0 "foo": 3.0
> > }
> >
> > I imagine that most schema-driven software would first deserializ= e
> > it into a tree, probably something like Jackson ObjectMapper'= s
> > JsonNode, and then apply schema constructs to the tree.=C2=A0=C2= =A0 I would
> > hope that a sane schema would accept this whether a top-level &qu= ot;foo"
> > was required to be an integer or double or most other flavors of<= br> > > number, and reject it if "foo" was required to be a str= ing or
> > boolean.
>
> Here we have a little problem.=C2=A0 There are already quite popular > parsers out there flagging 3.0 as an invalid integer when explicitly > parsing for an integer[*].=C2=A0 Personally, I consider this as right = thing
> to do in a schema as well.=C2=A0 Letting one or two rotten eggs (=3DJS= ON
> serializers that output Numbers that also represent exact integers
> with fractions) set the bar for the other 99.9% doesn't seem right= to
> me.

Those parsers are broken.

> > Put another way, no JSON schema spec can change the definition of=
> > what JSON is, or make the built-in type system anything but what = it
> > is.
>
> I don't think anybody is actually proposing that; only mapping thi= ngs
> that doesn't have a specific representation in JSON like integers.=

Integers do have a specific representation in JSON, and anything that
precludes generic encoders that might emit 10.0 where a peer parser will reject that as not-an-integer *is* a change to JSON.

Nico
--

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--000000000000b036d805884e637f-- From nobody Tue May 7 09:15:28 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 344B512018B for ; Tue, 7 May 2019 09:15:27 -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 Zz1qEVbLcBAB for ; Tue, 7 May 2019 09:15:24 -0700 (PDT) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3E5120144 for ; Tue, 7 May 2019 09:15:23 -0700 (PDT) Received: (qmail 14283 invoked from network); 7 May 2019 17:13:31 +0100 Received: from host109-157-169-192.range109-157.btcentralplus.com (HELO ?192.168.1.72?) (109.157.169.192) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 7 May 2019 17:13:30 +0100 To: Tim Bray , Ulysse Carion Cc: json@ietf.org References: From: Pete Cordell Message-ID: Date: Tue, 7 May 2019 17:15:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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 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, 07 May 2019 16:15:27 -0000 On 06/05/2019 23:38, Tim Bray wrote: > Hi all.  I haven't got around to reading the draft (but will soon). > Prior to that, a few notes: > > 1. I'm pretty sure that we need something better than what we have in > the area of JSON schemas.  At least, I'm 100% sure that my job at Amazon > Web Services would be easier, and our customer experiences would be more > pleasant, if we had something. > > 2. One thing schemas are useful for is to syntax-check JSON texts that > claim to conform to some language specification or another. Obviously no > schema can ever completely satisfy this requirement - there are always > things in specifications which are semantic and not addressable by > schemas - but they can still be super useful. > > 3. Another thing they are useful for is for providing help to developers > working in strongly typed programming languages. With a well-built > schema it is reasonably straightforward to auto-generate nice idiomatic > class declarations in modern programming languages, and also to build > serializers/deserializers that will move data back and forth between > JSON blobs and programming-language constructs, or fail in a clean > deterministic way if the JSON fails to match the schema. For me: 4. Person-to-person communication is an important use-case for schemas as a way of describing valid formats, either in design documents or during brainstorming sessions on whiteboards or personal notes on the back of envelopes. When you do that you want to be discussing JSON rather than also working out a convention for defining JSON. Hence the need for something already defined that is readily and widely understood. The human need puts me off a JSON format for this. It is too long winded and, like W3C XML Schema, unnecessarily difficult for humans to use. It's why XML Relax NG Compact Syntax was developed. And why I prefer JSON Content Rules JSON-like (but not JSON) syntax. You can get an idea of a comparison of the two types of specification at: http://json-content-rules.org/drafts/draft-newton-json-content-rules-10-pjc.html#rfc.section.2.3 I my mind, JCR is a clear winner in this situation. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Tue May 7 09:41:11 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 85C3F120196 for ; Tue, 7 May 2019 09:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 bbSf_I1FG-vu for ; Tue, 7 May 2019 09:41:07 -0700 (PDT) Received: from smtp.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 23FC112018B for ; Tue, 7 May 2019 09:41:07 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44z52m5zVcz10H0; Tue, 7 May 2019 18:41:04 +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: Tue, 7 May 2019 18:41:04 +0200 Cc: Tim Bray , Ulysse Carion , json@ietf.org X-Mao-Original-Outgoing-Id: 578940062.159153-213330db636ddd43e68b4554133f0e40 Content-Transfer-Encoding: quoted-printable Message-Id: <211E9F29-901A-4D5F-A958-C760AD2A49C4@tzi.org> References: To: Pete Cordell X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 16:41:10 -0000 On May 7, 2019, at 18:15, Pete Cordell wrote: >=20 > long winded Here are a few examples from the JSL draft with the CDDL equivalents = (behind the =E2=80=9C=3D=3D=3D=E2=80=9C; note that CDDL supports both = text and byte strings, so uses =E2=80=9Ctext=E2=80=9D for text strings): { =E2=80=9Ctype=E2=80=9D: =E2=80=9Cnumber=E2=80=9D } =20 =3D=3D=3D number { =20 =E2=80=9Celements=E2=80=9D: { =E2=80=9Ctype=E2=80=9D: =E2=80=9Cnumber=E2=80=9D } } =3D=3D=3D [* number] ([] signifies an array, * signifies zero or more) { =20 "properties": { "a": { "type": "string" }, "b": { "type": "string" } }, "optionalProperties": { "c": { "type": "string" }, "d": { "type": "string" } } } =3D=3D=3D { a: text, b: text, ? c: text, ? d: text } ({} signifies an object, ? signifies zero or one) { "values": { "type": "number" } } =3D=3D=3D { * text =3D> number } (=3D> can be used to separate type names for key and value) { "discriminator": { "tag": "version", "mapping": { "v1": { "properties": { "a": { "type": "number" } } }, "v2": { "properties": { "a": { "type": "string" } } } } } } =3D=3D=3D { tag: =E2=80=9Cv1=E2=80=9D, a: number } / { tag: =E2=80=9Cv2=E2=80=9D,= a: text } (/ signifies a choice) Noise in specifications hurts: = https://www.iab.org/wp-content/IAB-uploads/2016/03/Noise-in-specifications= -hurts.pdf Gr=C3=BC=C3=9Fe, Carsten From nobody Tue May 7 09:46:17 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 73CA51201B4 for ; Tue, 7 May 2019 09:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 vE-y_pawLE1l for ; Tue, 7 May 2019 09:46:14 -0700 (PDT) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (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 A3EE312018A for ; Tue, 7 May 2019 09:46:14 -0700 (PDT) Received: by mail-oi1-f175.google.com with SMTP id j9so12149498oie.10 for ; Tue, 07 May 2019 09:46:14 -0700 (PDT) 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=YYi2SOoNp3d4S5bqkygfhKlw6K1oAbOF/pZq0Lw5iiY=; b=hClAjqx3zzN4i+FVAfflq/OTTcaZosB39DqTGtWLnOMvtECe6Qx39JoNSKtKDiJ3aw T+IRPouaQNCcQtT8+PZs43U8WsFJrE1Ey5s6pV5Ldezvx2Ifd/mbndx9AhcgsG1pZu5s LxhyiKWvd8RKyd8QeY+n82HvvKNDmvhAguP7GLhPep4gfyjbkV10dwwCCKVMmuq94BCs I6wjis+wPpDvpGB4gs79ATcBYe3qbVGYGMrNWfYrwEyE/9SEIipMQuXLWaHlao4xyZa7 7ZbirITxlUwAo+0HhaUkvbWv+t3+to17rSrKOVTOe0v/pBeFKQYXc5sN07ro/Aadhdwq RUNA== X-Gm-Message-State: APjAAAXvmvujyWwYmzG8vWXkhJ8O2kICD/riZ1FfkI7LFd6bMY/rhzGW yTI+dyQK4Oki2vAjUB77MjjVCRWBpAtPR8dc0clpHE8Fr0Q= X-Google-Smtp-Source: APXvYqw6BsvRkKSuUH09eleNaTqykoCVUyeIKi7dLZQUIWFjQHqkaZsrdLSRAvvTq2K6O1WvnZwmOPF1aUactCtjvjE= X-Received: by 2002:aca:c348:: with SMTP id t69mr803717oif.95.1557247573680; Tue, 07 May 2019 09:46:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Tue, 7 May 2019 12:46:03 -0400 Message-ID: To: Tim Bray Cc: Ulysse Carion , JSON WG Content-Type: multipart/alternative; boundary="00000000000074e7d505884ef47b" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 16:46:16 -0000 --00000000000074e7d505884ef47b Content-Type: text/plain; charset="UTF-8" On Mon, May 6, 2019 at 6:38 PM Tim Bray wrote: > 1. I'm pretty sure that we need something better than what we have in the > area of JSON schemas. At least, I'm 100% sure that my job at Amazon Web > Services would be easier, and our customer experiences would be more > pleasant, if we had something. > I agree. And I think most others here agree. The problem is that when we go down the 'schema' road, we tend to end up with schema languages that become baroque and more hassle than they are worth. > 2. One thing schemas are useful for is to syntax-check JSON texts that > claim to conform to some language specification or another. Obviously no > schema can ever completely satisfy this requirement - there are always > things in specifications which are semantic and not addressable by schemas > - but they can still be super useful. > > 3. Another thing they are useful for is for providing help to developers > working in strongly typed programming languages. With a well-built schema > it is reasonably straightforward to auto-generate nice idiomatic class > declarations in modern programming languages, and also to build > serializers/deserializers that will move data back and forth between JSON > blobs and programming-language constructs, or fail in a clean deterministic > way if the JSON fails to match the schema. > That is one reason I need a schema language. The other is that I want to document the protocol design so that I can generate the reference manual and the reference code from the same source. This is NOT something I have seen in any proposal other than mine to date. But it is the one I think most relevant to IETF purposes. For example, this is a fragment of a schema I am working with right now: Section 1 "Shared Classes" Description |The following classes are used as common elements in |Mesh profile specifications.a Structure HostEntry Description |Describes a current or pending connection to a Mesh account String ID Description |Unique object instance identifier. The description sections flow straight into my Internet Drafts. This is not how I would do the same thing now. That would be more like: Shared: Section 1 "Shared Classes" // The following classes are used as common elements in // Mesh profile specifications. HostEntry: Class // Describes a current or pending connection to a Mesh account ID: String //Unique object instance identifier. In fact, I would probably get rid of the colons as they aren't needed by the parser and are therefore clutter. The point is that documentation and code should be integrated. > I mostly fail to understand the debate about jq and integers and so on. > Clearly, the following is a valid JSON text and will be parsed successfully > by any JSON parser. > > { > "foo": 3.0 > } > It will be parsed successfully but the problem that comes up are that a lexical analyzer may legitimately interpret 1.0 as a float and 1 as an integer and so when the parse tree is traversed end up rejecting the data as invalid. But that is only an issue if your schema validator doesn't know how the parse tree handles numbers. > I imagine that most schema-driven software would first deserialize it into > a tree, > That isn't what I do. I parse directly to the memory data structures. I don't need the tree structure. That said, I am thinking of rewriting the code so that it does both at the same time probably something like Jackson ObjectMapper's JsonNode, and then apply > schema constructs to the tree. I would hope that a sane schema would > accept this whether a top-level "foo" was required to be an integer or > double or most other flavors of number, and reject it if "foo" was required > to be a string or boolean. > > Put another way, no JSON schema spec can change the definition of what > JSON is, or make the built-in type system anything but what it is. > But do we actually want a JSON schema spec or a general data schema spec that supports JSON? JSON meets pretty much all the requirements I have for writing protocols except for representing binary data. The application that JSON does not currently support is data representation because as things stand, floats do not round trip. One option would be to write a profile of JSON which ensures floats round trip. But I can't see that being adopted consistently enough to get traction. A better solution would be to introduce new float encodings which do round trip. It wouldn't be JSON but is could use 95% of JSON, be 100% backwards compatible reading old data and not corrupt data when writing the new. Point is that any spec that attempts to solve interop issues by declaring it can never ever change will fail. Instead of there being one extension, there will be many and we will end up in the Markdown situation where it has taken ten years for the market to converge on a common set of tags. And that mainly because GitHub chose one particular flavor and so iPython/Jypityr did, etc. --00000000000074e7d505884ef47b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 6, 2019 at 6:38 PM Tim Bray <= tbray@textuality.= com> wrote:
1. I'm pretty sure that we need something better than what we = have in the area of JSON schemas.=C2=A0 At least, I'm 100% sure that my= job at Amazon Web Services would be easier, and our customer experiences w= ould be more pleasant, if we had something.
I agree= . And I think most others here agree. The problem is that when we go down t= he 'schema' road, we tend to end up with schema languages that beco= me baroque and more hassle than they are worth.

<= div>=C2=A0
2. One thing schemas are useful for= is to syntax-check JSON texts that claim to conform to some language speci= fication or another. Obviously no schema can ever completely satisfy this r= equirement - there are always things in specifications which are semantic a= nd not addressable by schemas - but they can still be super useful.

3. An= other thing they are useful for is for providing help to developers working= in strongly typed programming languages. With a well-built schema it is re= asonably straightforward to auto-generate nice idiomatic class declarations= in modern programming languages, and also to build serializers/deserialize= rs that will move data back and forth between JSON blobs and programming-la= nguage constructs, or fail in a clean deterministic way if the JSON fails t= o match the schema.=C2=A0=C2=A0

That is one reason = I need a schema language. The other is that I want to document the protocol= design so that I can generate the reference manual and the reference code = from the same source.

Thi= s is NOT something I have seen in any proposal other than mine to date. But= it is the one I think most relevant to IETF purposes. For example, this is= a fragment of a schema I am working with right now:

Section 1 "Shared Classes"
Description
|The following= classes are used as common elements in
<= span style=3D"white-space:pre-wrap"> |Mesh profile specifications.= a

=
Structure HostEntry
Description
|Describes a current o= r pending connection to a Mesh account
String ID
Description
|Unique object instance identifier.

The= description sections flow straight into my Internet Drafts.

This is not how I would do the same thi= ng now. That would be more like:

Shared: Section 1 "Shared Classes"
= // The following classes are used as common elements in
// Mesh profile specifications.

HostEntry: Class
//=C2=A0Describes a current or pending connection to= a Mesh account=C2=A0=C2=A0
ID: String=C2= =A0
= //Unique object instance identifier.

In fact, I would probably get rid = of the colons as they aren't needed by the parser and are therefore clu= tter.

The point is that d= ocumentation and code should be integrated.=C2=A0
=C2=A0
I mostly fail to understand the debate abou= t jq and integers and so on.=C2=A0 Clearly, the following is a valid JSON t= ext and will be parsed successfully by any JSON parser.

{
=C2=A0 "foo": 3.0
}

It will be parsed successfully but = the problem that comes up are that a lexical analyzer may legitimately inte= rpret 1.0 as a float and 1 as an integer and so when the parse tree is trav= ersed end up rejecting the data as invalid. But that is only an issue if yo= ur schema validator doesn't know how the parse tree handles numbers.=C2= =A0
=C2=A0
I imagine that most schema-driven software would first deserialize it into= a tree,

That isn't what I do. I parse d= irectly to the memory data structures. I don't need the tree structure.=

That said, I am thinking= of rewriting the code so that it does both at the same time
=C2=A0

probab= ly something like Jackson ObjectMapper's JsonNode, and then apply schem= a constructs to the tree.=C2=A0=C2=A0 I would hope that a sane schema would= accept this whether a top-level "foo" was required to be an inte= ger or double or most other flavors of number, and reject it if "foo&q= uot; was required to be a string or boolean.

Put another way, no JSON sch= ema spec can change the definition of what JSON is, or make the built-in ty= pe system anything but what it is.

<= /div>
But do we = actually want a JSON schema spec or a general data schema spec that support= s JSON?

JSON meets pretty much all the requirements I have for writing prot= ocols except for representing binary data. The application that JSON does n= ot currently support is data representation because as things stand, floats= do not round trip.

One option would be to write a profile of JSON which ensures floats round = trip. But I can't see that being adopted consistently enough to get tra= ction. A better solution would be to introduce new float encodings which do= round trip. It wouldn't be JSON but is could use 95% of JSON, be 100% = backwards compatible reading old data and not corrupt data when writing the= new.

Point is that any s= pec that attempts to solve interop issues by declaring it can never ever ch= ange will fail. Instead of there being one extension, there will be many an= d we will end up in the Markdown situation where it has taken ten years for= the market to converge on a common set of tags. And that mainly because Gi= tHub chose one particular flavor and so iPython/Jypityr did, etc.
--00000000000074e7d505884ef47b-- From nobody Tue May 7 10:24: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 0891912024B for ; Tue, 7 May 2019 10:24:41 -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_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 nu9DnPAqq7FF for ; Tue, 7 May 2019 10:24:38 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 AB9931202C1 for ; Tue, 7 May 2019 10:24:34 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id l140so27051118itb.0 for ; Tue, 07 May 2019 10:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8uxzLKXofY8YYjT3o4/7JRrKiYzSNjQAF2MAYZagnlY=; b=sC2adYMz+Hbk2pioGHpvZ3ylHwhNobc5C05XoxeFTSeEbYDclBq20+rVwF35RtNqO4 Uv6m/U6Ny5rua2yArp7FG6U56Bj+5N3NLNPFc16MJtZuhI9uOKtV+PDHVQQ+cdZ+duVa v6eQOkyhBXkfKdBVZIVAwyVlF5+v5Ueyc4npyYH+XPUGZCSHAor9YplfouN2fQUAXlHd 5gzQUoVIIz8h3V0bl8tCTLGfJIRxMh8qu97y7wzIb1Yq5igFkZR5UwGdpAXRzAmj6TeI jYqaiC2rw81uDzng16TTYeKV3n32uST+yNUbL4O6lNK+WW20wiuGbQeSp8DlLAt4Xsu6 GgLw== 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=8uxzLKXofY8YYjT3o4/7JRrKiYzSNjQAF2MAYZagnlY=; b=aD/cNF1GNJP6QixOsWxtDDIM+Y5/wNevjLaULx6Lx91tlplpjU5c/UYzNh7FhRyFni VWdNLDXsZxJDDKW8LlN76A9827V3LrB64bXStWFwJB11Yd4L88FK5gjBKWMlSRqXO9a4 X+rCyMwd5NhT2YJ5It3TIJJ7X0J2ULmjPig6IEWsHUmgKQFB12eBwSyCrcVG5i6Wy2sH twW2YqU+8nsJwN1w7EHpt79Wren/Cql4vBRFzNXJR+p5oHYXaPee3t7uAD+oEtDgWLEV 22+l8iTN0dAyn2R/gSGq/O0iMZge1wQv07H0eiHnKEdkv7HccFuCoGeblWAjZAMN9WZf K/ww== X-Gm-Message-State: APjAAAWIOzDqzA8dTO/Ug6/telqHOd/JWrMpim+TcuZTEfjJhbCVDnu3 zYSnk0E/Dez2cFFm9C5MaItr5wLSwHNk7IKQRto= X-Google-Smtp-Source: APXvYqzXZEWcKsj6eDOrJ3UZJefSn3DKfVTEIaVHhyKYDCaACllPJHcFj/2Kc1rMWxEqf3cugX6n/OJHV+80aaZT/pU= X-Received: by 2002:a24:c347:: with SMTP id s68mr9027172itg.140.1557249873940; Tue, 07 May 2019 10:24:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Tue, 7 May 2019 10:24:22 -0700 Message-ID: To: Tim Bray Cc: Ulysse Carion , json@ietf.org Content-Type: multipart/alternative; boundary="00000000000090136505884f7dcf" Archived-At: Subject: Re: [Json] Notes on json-schema-language-00 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, 07 May 2019 17:24:45 -0000 --00000000000090136505884f7dcf Content-Type: text/plain; charset="UTF-8" On Tue, May 7, 2019 at 9:03 AM Tim Bray wrote: > Last time I checked, MustIgnore was harder to implement in the binary > formats. Is that still true? That matters for some of us. > Here's protobuf's docs: https://developers.google.com/protocol-buffers/docs/proto3#unknowns Anything that can be rolled out gradually usually has this property to some extent. > > In any case, JSON remains the lingua franca for lots of APIs and > event-driven systems, and upgrading its data typing a little seems worth > doing for its own sake, since there would be substantial cost and effort > involved in ripping it out and replacing it with anything else. Yes, I do > really want to start imposing types retroactively on existing message > streams. > I've never seen one of these systems save money vs switching to something that deserializes directly to programming language data structures. It's true that it might not be possible to switch from JSON for some use cases. - Rob > > On Mon, May 6, 2019 at 11:23 PM Rob Sayre wrote: > >> Would a JSON message with such a schema be self-describing? If not, what >> benefit would this scheme provide over Thrift or Protobuf? It seems like it >> would be strictly worse. >> >> - Rob >> >> On Mon, May 6, 2019 at 9:40 PM Tim Bray wrote: >> >>> I've now had time to give the draft a read. I think it shows promise >>> and would be useful in meeting needs I'm currently facing at work. I'd >>> like to talk it over and if we can move it forward a bit and get >>> significant community support for a revised draft, would be interested in >>> proposing we spin up a WG to see if there's IETF consensus to be had, and >>> in volunteering to invest cycles to help with the process. If anyone >>> objects to using this mailing list for such a conversation, please say so. >>> Obviously since it's on github we could file issues there if that's what >>> people would prefer. >>> >>> Ulysse, if we do have such a discussion, please don't charge off and >>> start revising your draft; it's helpful to keep the document stable for a >>> while while we figure out whether there's consensus. >>> >>> First, a question: I'm a little out of touch with the json-schema work. >>> Is this designed to be a compatible subset? Or is there any other >>> relationship? Depending on the answer, we might want to consider a name >>> for this other than "JSON Schema Language". >>> >>> Some things to discuss: >>> >>> 1. There are problems with JSON terminology; "JSON text", "field", >>> "name"/"value", "corresponding". But these are easy to fix. >>> 2. I'd consider enriching the type range a bit, we don't have to >>> stick strictly with JSON's impoverished diet >>> 1. In 4.1, I think it'd be useful to specify integer/float, bearing >>> in mind the reasonableness in behavior discussed in the intro thread. >>> 2. I'd add a timestamp type (RFC3339 strings) >>> 3. I'd really want to add an enum type (constraint on JSON string >>> value) >>> 3. I'd introduce lots of examples early in section 4, to show how >>> each of the keywords might be used. >>> 4. In 4.4, I suggest the URI reference resolution procedure is way >>> too complicated, and needn't involve the "id" element at all. >>> 5. Probably error objects should allow extra fields such as >>> line/column numbers and human-readable explanations of what went wrong. >>> >>> _______________________________________________ >>> json mailing list >>> json@ietf.org >>> https://www.ietf.org/mailman/listinfo/json >>> >> --00000000000090136505884f7dcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue,= May 7, 2019 at 9:03 AM Tim Bray <tbray@textuality.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Last time I checked, MustIgnore was=C2=A0 harder to i= mplement in the binary formats.=C2=A0 Is that still true?=C2=A0=C2=A0 That = matters for some=C2=A0 of us.

Here's protobuf's docs:


Anything that can be rolled out gradually usually has this = property to some extent.
=C2=A0

In= any case, JSON remains the lingua franca for lots of APIs and event-driven= systems, and upgrading its data typing a little seems worth doing for its = own sake, since there would be substantial cost and effort involved in ripp= ing it out and replacing it with anything else. Yes, I do really want to st= art imposing types retroactively on existing message streams.

I've never seen one of these systems= save money vs switching to something that deserializes directly to program= ming language data structures. It's true that it might not be possible = to switch from JSON for some use cases.

- Rob

=C2=A0

On Mon, May 6= , 2019 at 11:23 PM Rob Sayre <sayrer@gmail.com> wrote:
Would a JSON message with= such a schema be self-describing? If not, what benefit would this scheme p= rovide over Thrift or Protobuf? It seems like it would be strictly worse.

- Rob

On Mon, May 6, 2019 at 9:40 PM Tim Bray <<= a href=3D"mailto:tbray@textuality.com" target=3D"_blank">tbray@textuality.c= om> wrote:
I've= now had time to give the draft a read.=C2=A0 I think it shows promise and = would be useful in meeting needs I'm currently facing at work.=C2=A0 I&= #39;d like to talk it over and if we can move it=C2=A0forward a bit and get= significant community support for a revised draft, would be interested in = proposing we spin up a WG to see if there's IETF consensus to be had, a= nd in volunteering to invest cycles to help with the process.=C2=A0 If anyo= ne objects to using this mailing list for such a conversation, please say s= o.=C2=A0 Obviously since it's on github we could file issues there if t= hat's what people would prefer.
Ulysse, if we do have such a discussi= on, please don't charge off and start revising your draft; it's hel= pful to keep the document stable for a while while we figure out whether th= ere's consensus.

First, a question: I'm a little out of touch wit= h the json-schema work.=C2=A0 Is this designed to be a compatible subset?= =C2=A0 Or is there any other relationship?=C2=A0 Depending on the answer, w= e might want to consider a name for this other than "JSON Schema Langu= age".

Some things to discuss:
  • There are problems with JSON terminology; "JSON text", &quo= t;field", "name"/"value", "corresponding"= ;. But these are easy to fix.
  • I'd consider enriching the type r= ange a bit, we don't have to stick strictly with JSON's impoverishe= d diet
    1. In 4.1, I think it'd be useful to specify intege= r/float, bearing in mind the reasonableness in behavior discussed in the in= tro thread.=C2=A0=C2=A0
    2. I'd add a timestamp type (RFC3339 strin= gs)
    3. I'd really want to add an enum type (constraint on JSON str= ing value)
  • I'd introduce lots of examples early in section= 4, to show how each of the keywords might be used.=C2=A0
  • In 4.4, I= suggest the URI reference resolution procedure is way too complicated, and= needn't involve the "id" element at all.
  • Probably er= ror objects should allow extra fields such as line/column numbers and human= -readable explanations of what went wrong.
    • _______________________________________________
    json mailing list
    json@ietf.org
    https://www.ietf.org/mailman/listinfo/json
    --00000000000090136505884f7dcf-- From nobody Tue May 7 14:13: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 8A80012026E for ; Tue, 7 May 2019 14:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net 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 JOY13BTMO23R for ; Tue, 7 May 2019 14:13:36 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 ADC54120291 for ; Tue, 7 May 2019 14:13:36 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id h1so8940709pgs.2 for ; Tue, 07 May 2019 14:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WyXq5PbRg+7eDkssdpuovLxPibb3sKY08+w7VIzmHm4=; b=PISJjtYvFKPMA1Ce8EpKF3gmvr7Ao2/jEKAnmde3X1Q9GakNI14q0v6cx+8c0og7JQ SgcnXtNZPmU6txGd7hWrXukTWOXNZuoXrZCr92ybgFgLxEWVcQhXGTobFNpyN/I1tsFW J5arsh5MwDklQ9g2s7PnHVVYIlcgwTtM0zVh0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WyXq5PbRg+7eDkssdpuovLxPibb3sKY08+w7VIzmHm4=; b=PmC4UibEWahM6haNELLYyd/92YDHIWGJmNrFjU7yXAjd6BSXBHdCgzl2KSWwTTB9H/ hhZcuech2aqWjHUthoZbInDE7FtWFpGGTTGeWSb6RTaHxkvQHWc7mzl5L2QfoRfaUsTD Cj05PSp3kEIdAGCpOuYZ1LGwFd1w8q4VsBlmQo6SuOMaqaI9t59rWYVdbSZ7Ex3e8UIr 1svHM6F1nAkAwdpV5ZHuMxpJE3Ve26qEWkWNRqpB19mOhy/Mik7+LUoGVkwPyPOIYHZ6 lBSU/Qz/x3gtBTGrWxwzP2TJEtoNwQ4LF0my90Hvo+MEf+Nom0fcfxOWqx/fzM6+nFV8 oSMg== X-Gm-Message-State: APjAAAWsS20LRv9WQfui6B2Pzw3CSFW30xSTzLzsixwW14/iNe5H6KJu RKZJxVr3I95GlhYSiqVZM6rYlw== X-Google-Smtp-Source: APXvYqxl0yIrDhKE0H7t0Jq+o4c9VvpjnguIPaUDmXr8P4ISgF5Tjnt3unW84zueMno/iFOMZUGAhw== X-Received: by 2002:a62:b411:: with SMTP id h17mr43681073pfn.61.1557263615946; Tue, 07 May 2019 14:13:35 -0700 (PDT) Received: from [192.168.0.175] ([184.101.46.90]) by smtp.gmail.com with ESMTPSA id j16sm17391810pfi.58.2019.05.07.14.13.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 14:13:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Austin Wright In-Reply-To: <20190507154201.GP21049@localhost> Date: Tue, 7 May 2019 14:13:33 -0700 Cc: Anders Rundgren , Tim Bray , json@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 21:13:45 -0000 > On May 7, 2019, at 08:42, Nico Williams wrote: >=20 > On Tue, May 07, 2019 at 06:44:49AM +0200, Anders Rundgren wrote: >> On 2019-05-07 00:38, Tim Bray wrote: >>> I mostly fail to understand the debate about jq and integers and so >>> on. Clearly, the following is a valid JSON text and will be parsed >>> successfully by any JSON parser. >>>=20 >>> { >>> "foo": 3.0 >>> } >>>=20 >>> I imagine that most schema-driven software would first deserialize >>> it into a tree, probably something like Jackson ObjectMapper's >>> JsonNode, and then apply schema constructs to the tree. I would >>> hope that a sane schema would accept this whether a top-level "foo" >>> was required to be an integer or double or most other flavors of >>> number, and reject it if "foo" was required to be a string or >>> boolean. >>=20 >> Here we have a little problem. There are already quite popular >> parsers out there flagging 3.0 as an invalid integer when explicitly >> parsing for an integer[*]. Personally, I consider this as right = thing >> to do in a schema as well. Letting one or two rotten eggs (=3DJSON >> serializers that output Numbers that also represent exact integers >> with fractions) set the bar for the other 99.9% doesn't seem right to >> me. >=20 > Those parsers are broken. >=20 >>> Put another way, no JSON schema spec can change the definition of >>> what JSON is, or make the built-in type system anything but what it >>> is. >>=20 >> I don't think anybody is actually proposing that; only mapping things >> that doesn't have a specific representation in JSON like integers. >=20 > Integers do have a specific representation in JSON, and anything that > precludes generic encoders that might emit 10.0 where a peer parser = will > reject that as not-an-integer *is* a change to JSON. I would put it slightly differently: While JSON doesn=E2=80=99t define = any concept of an =E2=80=9Cinteger=E2=80=9D, applications that encode = integers (e.g. uint32_t or similar) might conceivably emit it with the = "frac=E2=80=9D production (using a trailing decimal and zero); this is = not ambiguous, and in the interest of being liberal in what you accept, = parsers shouldn=E2=80=99t produce any error. >=20 > Nico > --=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Tue May 7 14:29: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 E974012015D for ; Tue, 7 May 2019 14:29:22 -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, 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 TTduUawK5pAF for ; Tue, 7 May 2019 14:29:20 -0700 (PDT) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 DED84120086 for ; Tue, 7 May 2019 14:29:19 -0700 (PDT) Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:56798 helo=[192.168.1.78]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hO7eG-00063R-6u; Tue, 07 May 2019 17:29:17 -0400 To: Austin Wright , Nico Williams Cc: json@ietf.org, Tim Bray , Anders Rundgren References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> From: Erik Wilde Message-ID: <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> Date: Tue, 7 May 2019 14:29:13 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 21:29:23 -0000 On 2019-05-07 14:13, Austin Wright wrote: > I would put it slightly differently: While JSON doesn’t define any concept of an “integer”, applications that encode integers (e.g. uint32_t or similar) might conceivably emit it with the "frac” production (using a trailing decimal and zero); this is not ambiguous, and in the interest of being liberal in what you accept, parsers shouldn’t produce any error. at the risk of referring to XSD too much, but i think they got it right: - constraining facets for constraining the value space. - lexical facets for constraining the representation of values. maybe JSON schema languages do not want to copy that exact model, but the general design approach might be helpful to look at. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Tue May 7 14:30: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 4448B120254 for ; Tue, 7 May 2019 14:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 WwMQvM1zdyRR for ; Tue, 7 May 2019 14:30:10 -0700 (PDT) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 A3B3B12029D for ; Tue, 7 May 2019 14:30:10 -0700 (PDT) Received: by mail-ot1-f53.google.com with SMTP id w6so16425115otl.7 for ; Tue, 07 May 2019 14:30:10 -0700 (PDT) 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=w7PhAUl6XCYqDHx0BD9pOUmwWV3cBBYHlloRSvowInc=; b=rUdCykctUOjI8d6eN3iKMxm1QtvttLZLYUpK/TaYWon9DdGzMNaWQAWZFmiSW7ITeZ 7xqQx8q3q4uCFrhzRUk59WkUxZpf3Km7e178+DpYMzEQPidlDtZNJaIxdebnM1qs8Y99 PC7qBwmvc+c7LQUILnN6rOucYP2DfrmXEzz0zQroLmmYWniu77EadFEAAEoSwYI1jJP6 7k6EpeEa8A72cuSJ6xFcUMymXuyvWUA2WfA9pjfRZgRXjfPjf9ciblRQc8oR6CIetQ3V lqQiOwLi78gHwZQji8GLVVYmoi3mlVAmogXVD57e56CPRNhZzYO3idFI8lAYscZ6qC7h K1FQ== X-Gm-Message-State: APjAAAXNfBl69j3Goh+dCORkP49LhFhTW2Na7aDqhAuvwyPvlvO+hOJU d5BhpFFmhwGPYvFeRMt45J1UCMNabjAP5wFTslQ= X-Google-Smtp-Source: APXvYqxRtyqo9D2jRgNvW9uvdf2j76kujdMa23Dp3FcynD7pXe40zRjpKSZnvrMFM0om2npytFfIhmB3/8fmVB5a2N0= X-Received: by 2002:a9d:6d93:: with SMTP id x19mr12474174otp.157.1557264609933; Tue, 07 May 2019 14:30:09 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Tue, 7 May 2019 17:29:59 -0400 Message-ID: To: Austin Wright Cc: Nico Williams , JSON WG , Tim Bray , Anders Rundgren Content-Type: multipart/alternative; boundary="000000000000e58403058852ebd8" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 21:30:12 -0000 --000000000000e58403058852ebd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 7, 2019 at 5:14 PM Austin Wright wrote: > > I would put it slightly differently: While JSON doesn=E2=80=99t define an= y concept > of an =E2=80=9Cinteger=E2=80=9D, applications that encode integers (e.g. = uint32_t or > similar) might conceivably emit it with the "frac=E2=80=9D production (us= ing a > trailing decimal and zero); this is not ambiguous, and in the interest of > being liberal in what you accept, parsers shouldn=E2=80=99t produce any e= rror. > The problem that arise are: 1) The lexical analyzer may distinguish integers and floats and this may cause a schema driven parser to reject legitimate number because it is encoded as a double. (e.g. 1.0) 2) There may be precision loss because the number is presented in exponential form (1.0E20) 3) There may be precision loss because the integer is larger than the floating point mantissa can hold. We should probably stop talking about 'float' values because I don't know of any JSON tech likely to use them at this point. Pretty much every programming language out there today will cause all calculations to be performed in Intel 80 bit floating point until the data has to be stored in a program data value when the mantissa will be truncated at 52 bits and stored in a double. Fact is that a 64 bit processor can do 64 bit mantissa ops more easily than 52 bit. But we are stuck in the choices of the 1980s when memory was scarce and nobody had 64 bit CPUs yet. --000000000000e58403058852ebd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On = Tue, May 7, 2019 at 5:14 PM Austin Wright <aaa@bzfx.net> wrote:

    I would put it slightly differently: While JSON doesn=E2=80=99t define any = concept of an =E2=80=9Cinteger=E2=80=9D, applications that encode integers = (e.g. uint32_t or similar) might conceivably emit it with the "frac=E2= =80=9D production (using a trailing decimal and zero); this is not ambiguou= s, and in the interest of being liberal in what you accept, parsers shouldn= =E2=80=99t produce any error.

    The problem that arise are:

    1) The lexical analyzer ma= y distinguish integers and floats and this may cause a schema driven parser= to reject legitimate number because it is encoded as a double. (e.g. 1.0)<= /div>

    2) There may be precision= loss because the number is presented in exponential form (1.0E20)

    3) There may be precis= ion loss because the integer is larger than the floating point mantissa can= hold.

    We should probably= stop talking about 'float' values because I don't know of any = JSON tech likely to use them at this point. Pretty much every programming l= anguage out there today will cause all calculations to be performed in Inte= l 80 bit floating point until the data has to be stored in a program data v= alue when the mantissa will be truncated at 52 bits and stored in a double.=

    Fact is that a 64 bit pr= ocessor can do 64 bit mantissa ops more easily than 52 bit. But we are stuc= k in the choices of the 1980s when memory was scarce and nobody had 64 bit = CPUs yet.

    <= /div>
    --000000000000e58403058852ebd8-- From nobody Tue May 7 14:49:00 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 640751200EF for ; Tue, 7 May 2019 14:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 DoAe7PYbOKEo for ; Tue, 7 May 2019 14:48:57 -0700 (PDT) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (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 456791200EB for ; Tue, 7 May 2019 14:48:57 -0700 (PDT) Received: by mail-ot1-f47.google.com with SMTP id f23so16444353otl.9 for ; Tue, 07 May 2019 14:48:57 -0700 (PDT) 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=wpaX950sW93x59I+rmO6Iw+cS4tnObELp8en6MkC7jA=; b=KaFYiKi+098V53Dzb+65/PUpnKt+dVNGruH9yunZEmCH4WQxVnCKxpqLP/b7bU7Cp2 L8+7AIdWP3fS23N0FiSVnsvlxTuTSZ70edUeNEI6fe41kKqKGJjjaq2AZd446srdedSy f7JamCsTQzp1dqw9tecXXwZhFBJouEnQucaR/NHnqcj3P9habQyF1BPUZE6uez3Lh/gP wubxUq2vo3ATGoem4xvTRIZTosErSVLFGqi9nmhLQdvFUH3McmBICQsK08kAcOk6fn8c nnxcXAksMtM9rb0YAOAgGZeNnBRgu6IUJ36JRjhsJVhjLPi5AidrpJ+D8npbQMwClKa0 QdSA== X-Gm-Message-State: APjAAAWjkXS4Xck/ZAgDxzTZuutGyKYwKsCCPms+ozlag45zPvnjPkzV X/s2/wvwbV9c/HG7E2EghqJG/eKho/5Jwzq6KJ0= X-Google-Smtp-Source: APXvYqykQw1y0dUtvpVeLUqTt4NOxwvWkl9G7aa6G1oUQn5YofKG+MSr5LuLrmIjvy06HNn0Ummrtc/AaTutoIh6H/0= X-Received: by 2002:a9d:e8c:: with SMTP id 12mr24601867otj.120.1557265736369; Tue, 07 May 2019 14:48:56 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> In-Reply-To: <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> From: Phillip Hallam-Baker Date: Tue, 7 May 2019 17:48:46 -0400 Message-ID: To: Erik Wilde Cc: Austin Wright , Nico Williams , Anders Rundgren , Tim Bray , JSON WG Content-Type: multipart/alternative; boundary="000000000000098adf0588532f57" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 21:48:59 -0000 --000000000000098adf0588532f57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 7, 2019 at 5:29 PM Erik Wilde wrote: > On 2019-05-07 14:13, Austin Wright wrote: > > I would put it slightly differently: While JSON doesn=E2=80=99t define = any > concept of an =E2=80=9Cinteger=E2=80=9D, applications that encode integer= s (e.g. uint32_t > or similar) might conceivably emit it with the "frac=E2=80=9D production = (using a > trailing decimal and zero); this is not ambiguous, and in the interest of > being liberal in what you accept, parsers shouldn=E2=80=99t produce any e= rror. > > at the risk of referring to XSD too much, but i think they got it right: > > - constraining facets for constraining the value space. > - lexical facets for constraining the representation of values. > > maybe JSON schema languages do not want to copy that exact model, but > the general design approach might be helpful to look at. > I disagree on the constraining facets part. The only values I have found useful to put in a schema are 0 or 1 minimum occurrences and 1 or infinity maximum occurrences. I don't have these constraints in any programming language I have used since I did formal methods 25 years ago. The only ones that did were Z and VDM. --000000000000098adf0588532f57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Tue, May 7, 2019 at 5:29 PM Erik Wilde <erik.wilde@dret.net> wrote:
    On 2019-05-07 14:13, A= ustin Wright wrote:
    > I would put it slightly differently: While JSON doesn=E2=80=99t define= any concept of an =E2=80=9Cinteger=E2=80=9D, applications that encode inte= gers (e.g. uint32_t or similar) might conceivably emit it with the "fr= ac=E2=80=9D production (using a trailing decimal and zero); this is not amb= iguous, and in the interest of being liberal in what you accept, parsers sh= ouldn=E2=80=99t produce any error.

    at the risk of referring to XSD too much, but i think they got it right:
    - constraining facets for constraining the value space.
    - lexical facets for constraining the representation of values.

    maybe JSON schema languages do not want to copy that exact model, but
    the general design approach might be helpful to look at.

    I = disagree on the constraining facets part. The only values I have found usef= ul to put in a schema are 0 or 1 minimum occurrences and 1 or infinity maxi= mum occurrences.

    I don= 9;t have these constraints in any programming language I have used since I = did formal methods 25 years ago. The only ones that did were Z and VDM.
    =C2=A0
    --000000000000098adf0588532f57-- From nobody Tue May 7 14:50: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 3397A1200EB for ; Tue, 7 May 2019 14:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net 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 x5Qopr76x7Ge for ; Tue, 7 May 2019 14:50:42 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0: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 503CE120086 for ; Tue, 7 May 2019 14:50:42 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id 10so9343268pfo.5 for ; Tue, 07 May 2019 14:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=87MY/b89nCqfDryVFBdkb86a+QRoi8uQpYD2ETdeeQM=; b=xkuagk3+3cmtGKt1LKhnnLlAOBxz18PHPgvYoYPkMTG3pDzEVS5a2YgxDx4lHxs4Dx hi/lhIIpHLLLkzB6B66xbmhq+nvaMhiZmReCve3hzkc0nWXFPLnLY6953SHbZA///zHv giEh8N0MinqBElu6s7BiXB9lW76yZ+jLsi/9Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=87MY/b89nCqfDryVFBdkb86a+QRoi8uQpYD2ETdeeQM=; b=lY1FPGhqpIXoRSQg6FYpTJlERmL4KHHqSd424ewMGprBf/OmgqKP/bmFtfVsmvHyuf oKoR8AD0hxHUlNYJ6+AWCA2EiKrQNWUy6YgzfVm4+TTqikVuZ85wh2TBCkt5B0MVJGQ1 tqYKf11Kh8V/sbn9T4D2WAWkgfK2jfppv/dd1n98/O2+csCWMKKtXbAEECdhsxk9Z+sE maW75kcn33IiThyv6YgCvBG9rPuI0t/B8Ati7mMML8SwM94/fskV+CU1pPA9GdRyqzVj uuTH8gzGj+HprzGAW/ut0fPGnbjgbYnIf8PXOBiu15sweEzOwpa2vkeaMlP4GgaDEgF7 L/PA== X-Gm-Message-State: APjAAAWFQjbirdmliyMo1lzvWU+XV5Z1TWjYKwC5RcDS0tKBY2t8tXoT hoOGO4R0XGLPIidbb67nmp2H/Q== X-Google-Smtp-Source: APXvYqywlX3+DIH+uFg7IvzdzT+1yLHG3jgoNOLpv1VbnGnKRhbdZqWC0QCNv7GEdMEgQXc+01CJzw== X-Received: by 2002:a63:234c:: with SMTP id u12mr4137526pgm.264.1557265841627; Tue, 07 May 2019 14:50:41 -0700 (PDT) Received: from [192.168.0.116] ([184.101.46.90]) by smtp.gmail.com with ESMTPSA id x30sm1642160pgl.76.2019.05.07.14.50.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 14:50:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Austin Wright In-Reply-To: Date: Tue, 7 May 2019 14:50:38 -0700 Cc: Tim Bray , Ulysse Carion , json@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <46584E26-AE7F-444C-A73C-BBB393BDCBD7@bzfx.net> References: To: Pete Cordell X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 21:50:45 -0000 > On May 7, 2019, at 09:15, Pete Cordell wrote: >=20 > On 06/05/2019 23:38, Tim Bray wrote: >> Hi all. I haven't got around to reading the draft (but will soon). = Prior to that, a few notes: >> 1. I'm pretty sure that we need something better than what we have in = the area of JSON schemas. At least, I'm 100% sure that my job at Amazon = Web Services would be easier, and our customer experiences would be more = pleasant, if we had something. >> 2. One thing schemas are useful for is to syntax-check JSON texts = that claim to conform to some language specification or another. = Obviously no schema can ever completely satisfy this requirement - there = are always things in specifications which are semantic and not = addressable by schemas - but they can still be super useful. >> 3. Another thing they are useful for is for providing help to = developers working in strongly typed programming languages. With a = well-built schema it is reasonably straightforward to auto-generate nice = idiomatic class declarations in modern programming languages, and also = to build serializers/deserializers that will move data back and forth = between JSON blobs and programming-language constructs, or fail in a = clean deterministic way if the JSON fails to match the schema. >=20 > For me: >=20 > 4. Person-to-person communication is an important use-case for schemas = as a way of describing valid formats, either in design documents or = during brainstorming sessions on whiteboards or personal notes on the = back of envelopes. >=20 > When you do that you want to be discussing JSON rather than also = working out a convention for defining JSON. Hence the need for something = already defined that is readily and widely understood. >=20 > The human need puts me off a JSON format for this. It is too long = winded and, like W3C XML Schema, unnecessarily difficult for humans to = use. It's why XML Relax NG Compact Syntax was developed. And why I = prefer JSON Content Rules JSON-like (but not JSON) syntax. >=20 > You can get an idea of a comparison of the two types of specification = at: >=20 > = http://json-content-rules.org/drafts/draft-newton-json-content-rules-10-pj= c.html#rfc.section.2.3 >=20 > I my mind, JCR is a clear winner in this situation. Yes, JSON is really not well suited for markup, I consider it as bulk = data language, closer to ASN.1 than XML. The upside of JSON Schema is that it=E2=80=99s primarily defined as a = vocabulary; and although it defines a JSON-based media type to encode = schemas as, you can invent any media type you want that=E2=80=99s = capable of encoding the same assertions. I still have to spend more time with JCR, but it appears to me JSON = Schema implementations could import JCR documents as a JSON Schema with = few problems, and it could very well be a superior method of authoring a = JSON Schema. Would you consider elaborating on this possibility in JCR? Cheers, Austin. >=20 > Pete. > --=20 > --------------------------------------------------------------------- > Pete Cordell > Codalogic Ltd > Read & write XML in C++, http://www.xml2cpp.com > --------------------------------------------------------------------- >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Tue May 7 14:54: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 9E651120273 for ; Tue, 7 May 2019 14:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 ddz4G6Dw_8cc for ; Tue, 7 May 2019 14:54:42 -0700 (PDT) Received: from common.maple.relay.mailchannels.net (common.maple.relay.mailchannels.net [23.83.214.38]) (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 4AE21120298 for ; Tue, 7 May 2019 14:54:42 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 57F375E2052; Tue, 7 May 2019 21:54:41 +0000 (UTC) Received: from pdx1-sub0-mail-a31.g.dreamhost.com (100-96-79-6.trex.outbound.svc.cluster.local [100.96.79.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 9A8965E2813; Tue, 7 May 2019 21:54:40 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a31.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Tue, 07 May 2019 21:54:41 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Stupid-Callous: 655c5b85433cc828_1557266081067_1223061152 X-MC-Loop-Signature: 1557266081066:2747493427 X-MC-Ingress-Time: 1557266081066 Received: from pdx1-sub0-mail-a31.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTP id 795F581B09; Tue, 7 May 2019 14:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=iZb5ZYfqeHGlt7 KHmi1J8ftSd3A=; b=n9VkFob4kwSFwEdbMZYA+EKWAhuiEfhZ+SooZEKMjWvw1u OA6Vvi8PykbMAeylrAm5J0VGLcxrWpLtIkzYoU57GMcZ/I6kgAZeXPE9AIZH6yjf x9L7uBao06Meb4zqfZI34xXcSWfYmr2hc4XkZPDLmj26VzpM9LcvntOakNk3w= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 98C2882EE4; Tue, 7 May 2019 14:54:34 -0700 (PDT) Date: Tue, 7 May 2019 16:54:31 -0500 X-DH-BACKEND: pdx1-sub0-mail-a31 From: Nico Williams To: Phillip Hallam-Baker Cc: Erik Wilde , Austin Wright , Anders Rundgren , Tim Bray , JSON WG Message-ID: <20190507215431.GQ21049@localhost> References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrkedugddtvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 21:54:46 -0000 On Tue, May 07, 2019 at 05:48:46PM -0400, Phillip Hallam-Baker wrote: > On Tue, May 7, 2019 at 5:29 PM Erik Wilde wrote: > > [...] > > > > I disagree on the constraining facets part. The only values I have found > useful to put in a schema are 0 or 1 minimum occurrences and 1 or infinity > maximum occurrences. +1e3 I've seen the option to have arbitrary Ns of relations in a database, and the only min/max value pairs ever used are {0,1}, {1,1}, {0,max}, and {1,max}, where max is usually just a very large number (2^31 - 1 in the case I have in mind). > I don't have these constraints in any programming language I have used > since I did formal methods 25 years ago. The only ones that did were Z and > VDM. +1e3 Nico -- From nobody Tue May 7 14:56:37 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 A85F61200EB for ; Tue, 7 May 2019 14:56:19 -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, 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 9wWZJUK6ETij for ; Tue, 7 May 2019 14:56:15 -0700 (PDT) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 79997120291 for ; Tue, 7 May 2019 14:56:15 -0700 (PDT) Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:56957 helo=[192.168.1.78]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hO84L-0000PT-4A; Tue, 07 May 2019 17:56:13 -0400 To: Phillip Hallam-Baker Cc: Austin Wright , Nico Williams , Anders Rundgren , Tim Bray , JSON WG References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> From: Erik Wilde Message-ID: <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> Date: Tue, 7 May 2019 14:56:10 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 21:56:20 -0000 On 2019-05-07 14:48, Phillip Hallam-Baker wrote: > at the risk of referring to XSD too much, but i think they got it right: > > - constraining facets for constraining the value space. > - lexical facets for constraining the representation of values. > > I disagree on the constraining facets part. The only values I have found > useful to put in a schema are 0 or 1 minimum occurrences and 1 or > infinity maximum occurrences. there may be a misunderstanding here. constraining facets are limiting the value space of datatypes, for example by defining minimum and maximum values. https://www.w3.org/TR/xmlschema-2/#rf-facets cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Tue May 7 15:17:39 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 2960212014B for ; Tue, 7 May 2019 15:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 2bNAYuEFmw4c for ; Tue, 7 May 2019 15:17:36 -0700 (PDT) Received: from bonobo.maple.relay.mailchannels.net (bonobo.maple.relay.mailchannels.net [23.83.214.22]) (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 514E412013A for ; Tue, 7 May 2019 15:17:36 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 829FA1424F7; Tue, 7 May 2019 22:17:35 +0000 (UTC) Received: from pdx1-sub0-mail-a31.g.dreamhost.com (100-96-78-10.trex.outbound.svc.cluster.local [100.96.78.10]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E36FD1413E5; Tue, 7 May 2019 22:17:34 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a31.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Tue, 07 May 2019 22:17:35 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Well-Made-Plucky: 303eab061a05eddf_1557267455291_2040399923 X-MC-Loop-Signature: 1557267455291:1572949887 X-MC-Ingress-Time: 1557267455290 Received: from pdx1-sub0-mail-a31.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTP id 4041E82EF0; Tue, 7 May 2019 15:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=vqqmenVAIwhBMs y57HoZqYMYzZ8=; b=S6Llp3zSab1VjYruCa7tawa+DMyfyKaCFdt+QDW3ZyI9B/ AhMuuvKoN4XJPoOK1YI0Q+lW6wpPl3tnwC/aK9nd1SvArzPV3ytD4nt5qoKnLyqh o/G3ze/xGEVQ7E7zAQ7QSbOXyhrZ1x/MZm6qO5ZndfzSJmpu6TrYxOCs2BdYc= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 2EAC982EEC; Tue, 7 May 2019 15:17:29 -0700 (PDT) Date: Tue, 7 May 2019 17:17:27 -0500 X-DH-BACKEND: pdx1-sub0-mail-a31 From: Nico Williams To: Erik Wilde Cc: Phillip Hallam-Baker , Tim Bray , JSON WG , Austin Wright , Anders Rundgren Message-ID: <20190507221726.GR21049@localhost> References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrkedugddtjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 22:17:38 -0000 On Tue, May 07, 2019 at 02:56:10PM -0700, Erik Wilde wrote: > On 2019-05-07 14:48, Phillip Hallam-Baker wrote: > > at the risk of referring to XSD too much, but i think they got it right: > > > > - constraining facets for constraining the value space. > > - lexical facets for constraining the representation of values. > > > > I disagree on the constraining facets part. The only values I have found > > useful to put in a schema are 0 or 1 minimum occurrences and 1 or > > infinity maximum occurrences. > > there may be a misunderstanding here. constraining facets are limiting the > value space of datatypes, for example by defining minimum and maximum > values. As long as they don't constrain the encoding when multiple representations are available. From nobody Tue May 7 16:57:17 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 474F8120073 for ; Tue, 7 May 2019 16:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A1fcPVZS22g for ; Tue, 7 May 2019 16:57:14 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13ED81200CD for ; Tue, 7 May 2019 16:57:14 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id q14so1156277itk.0 for ; Tue, 07 May 2019 16:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iHymrwLZYkLiA2GP/XQV+rg29gJYzTqWBpfXWKloVmk=; b=ZoDzdVS3KClZ8lSRKHMtS2FuRGRpZy2dOUopps5+76Yk/5xfYeMwcqMpE9TpEfUPl6 oHqXdQISpLyN7e+aQFEdT0XeDevZiGl8rqWQ0W5yNOEbJXBebQG8ktkL297+k52H7+G/ hXBI1HOj6T8DuqSaRsnkIeRBErWW5Ro50NbJ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iHymrwLZYkLiA2GP/XQV+rg29gJYzTqWBpfXWKloVmk=; b=WGMTtXlYWEQNn/w8Q35Nt6whO7AZe1i9mVsK35wqZk2Lr7wDi9WqsMI9dNJ7m4sSeY L+uFPnNDdiAmYj5GqnMOQqbOcbsEY0V6ug8e4WbnsModVnNzIQdcDTedOhW5lKT1INN5 CtkK8qkQ+rvE9VzVX5p5HKiF009nUuNtZ08b7Rc8Yd/yu9KfLnXPuO7qECuhkHHHA7oo JdBFZkLzRfiMGtGAMFgJdE+5RGQP/LR20aZqr69WQmO5vEgx6vjzN/V2bUD2OaYGZtiL 4PZZI7NW6jWENez+itMpIKNav4kEz1s3ZpOWdeXR90q9wZvQLT8KGgzu2/v3U0ppff0I XlyA== X-Gm-Message-State: APjAAAWUAW0PEnrW6s/Ky+uqEfsBg5iwLMJgHR/5+vSkeMQo9hpgcQGW YWkkGCspHuBOoIjKYDMtu4GFMosc64/Q+NIJfx1Wbw== X-Google-Smtp-Source: APXvYqzdiVAXM/zU0+HqyOz02zvQCJmh1mIjKq6whR355E97S5sDFPKOpW2jpDN8inRxv5dj5+k0WUxTIChgP/UjUNE= X-Received: by 2002:a24:3ec6:: with SMTP id s189mr1091862its.138.1557273433124; Tue, 07 May 2019 16:57:13 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> In-Reply-To: <20190507221726.GR21049@localhost> From: Ulysse Carion Date: Tue, 7 May 2019 16:57:01 -0700 Message-ID: To: Nico Williams Cc: Erik Wilde , Anders Rundgren , Austin Wright , Phillip Hallam-Baker , Tim Bray , JSON WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 23:57:16 -0000 Hi all, I'd like to offer a summary of what has been stated thus far, so as to make a bit more sense of the conversation. 1. Considerable ink has been spilled on the question of integers in a schema language. The main question has been how such an integral constraint should relate to serialization. 2. Some have raised questions around the terseness of JSON Schema and JSON Schema Language. Proposed alternatives are JCR and CDDL, by their respective editors. On the first question, I would agree with Messrs. Bormann and Bray, who both suggest that a generic JSON parser runs first, followed by a second pass over the data to convert the parsed data in the context of a schema. On such a view, "3" and "3.0" are typically indistinguishable by the time the schema is taken into account. Bormann aptly notes that the alternative runs the risk of de facto forking JSON itself. I don't think there is much more to be said on the matter. The second question is perhaps more interesting, although it has provoked less discussion. I went with JSON as the representation because it makes building tooling atop of JSON Schema Language much easier, since it doesn't require that the implementor write a parser. Such ease of extension is valuable: JSON is widespread largely because of how easy it is to build atop of, and we should not readily sacrifice this. JSON as the representation also unlocks syntax highlighting, formatting, and other such niceties for free. Furthermore, and most importantly, using JSON as a representation does not preclude later creating a RELAX NG-style compact representation later on. I would also like to echo Bray's point about the real-world utility of such a system. My day-job involves APIs, event-sourcing, and analytics messages. In all three, JSON is the lingua franca, and in all three considerable tedium is involved in writing and maintaining validators and language-idiomatic containers for JSON messages. No language-portable solution to this problem exists today, short of moving away from JSON toward something like Protobufs or CBOR. I'd like to return to the initial question of this thread, this time rephrased: Are we in agreement that the question of describing JSON, and from that description generating validators and idiomatic classes/types/etc, is a problem worth solving? Are we in agreement that something along the lines of the proposed I-D may be a way we address this problem? Best, Ulysse On Tue, May 7, 2019 at 3:17 PM Nico Williams wrote: > > On Tue, May 07, 2019 at 02:56:10PM -0700, Erik Wilde wrote: > > On 2019-05-07 14:48, Phillip Hallam-Baker wrote: > > > at the risk of referring to XSD too much, but i think they got it right: > > > > > > - constraining facets for constraining the value space. > > > - lexical facets for constraining the representation of values. > > > > > > I disagree on the constraining facets part. The only values I have found > > > useful to put in a schema are 0 or 1 minimum occurrences and 1 or > > > infinity maximum occurrences. > > > > there may be a misunderstanding here. constraining facets are limiting the > > value space of datatypes, for example by defining minimum and maximum > > values. > > As long as they don't constrain the encoding when multiple > representations are available. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Tue May 7 19:15: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 46498120073 for ; Tue, 7 May 2019 19:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-org.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 37_QYC5uwJWJ for ; Tue, 7 May 2019 19:15:41 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 7156612002E for ; Tue, 7 May 2019 19:15:41 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id f2so1043824wmj.3 for ; Tue, 07 May 2019 19:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wbrXhuB/zfQVfAZ8wR90OCHnLV9uwd5pzGZNkRQJmHI=; b=dSl7i0QJvMDWtURAAbPAIU9dQq5oNySG8W/caiXSgXzn9zMJgfMuJ8TBrrj9TKoeYf xfouqQg84+rTpgwcn6JHs76R/o8TGbMLWPKOWkGTSlRG1vYIC90cceXBZbEMCiO/oFmp A92XAlecAUYKvu+JKesctxEIQ9Vg/vdAaV/n7YTcpD+bUnznXeHREZQm8WemSDT4k5U/ Z/GVy6XCc3T+lABDbgvSG9ESqAHLlVBYUeQRi1as7xfCPxBMS8OeORgVaXcKsSivYZnr mAsmXDBvSHKPsraOM4H3Rxed0We6RCQ9Zww6g9zlo+0UqP25j/TMDHTK+pL0MLQEmbjp pQPA== 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=wbrXhuB/zfQVfAZ8wR90OCHnLV9uwd5pzGZNkRQJmHI=; b=oHYQGVqOyiO/zBeQl1Rg05BiWS/p7n8VOj6rirfa/UyhxWCBhiP8hl3pEcStQpSduY GgYzJQWZmRNsjtmrcm3Ba8zte0hqcfJ9iLiXHr3G917uYuk0u83QKpGzyd/oVE2fsrtq SqPrhdo98DogngJpTxAke0YLd566FubmxGLmdP19UYrb9PXyCVROZv7iZTzZppLXWRIy tT8J85U5t4ltb+wkoBi65t9HOG5AaTKPHKzoKpHZyo8wCSWf20bjVYsK16jtlI2U4fni GdsqfaNEoN/LS3AITFhbl0KOEvjYvnbZk8xfr3KjKE6zmmstlQ1PEdKnSaO5TXwqbGyh 7pTw== X-Gm-Message-State: APjAAAX4ONU6SjA5awKMP+9YjyIO6qGsvby7JdzXZDl6aXeCDD0pEeq3 K4AplHb6GwIVqbzP0oR+DSNyfcxKCGQceyCusNvlKg== X-Google-Smtp-Source: APXvYqzi6P/kPkGd1DrWMhWSb4noq94s6ae3kKK4AjJBqWGJpaLtomMPZzl3lIOUndzNGBodUWzaivKzxVKtT7LdW6o= X-Received: by 2002:a1c:7008:: with SMTP id l8mr939438wmc.49.1557281739808; Tue, 07 May 2019 19:15:39 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> In-Reply-To: From: John Cowan Date: Tue, 7 May 2019 22:15:27 -0400 Message-ID: To: Phillip Hallam-Baker Cc: Austin Wright , Nico Williams , Anders Rundgren , Tim Bray , JSON WG Content-Type: multipart/alternative; boundary="000000000000eabcdc058856e8ce" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 02:15:44 -0000 --000000000000eabcdc058856e8ce Content-Type: text/plain; charset="UTF-8" On Tue, May 7, 2019 at 5:30 PM Phillip Hallam-Baker wrote: 1) The lexical analyzer may distinguish integers and floats and this may > cause a schema driven parser to reject legitimate number because it is > encoded as a double. (e.g. 1.0) > > 2) There may be precision loss because the number is presented in > exponential form (1.0E20) > > 3) There may be precision loss because the integer is larger than the > floating point mantissa can hold. > JSON encodes absolutely no information about whether its numbers are to be interpreted as exact or inexact. 1.23 may be an exact number equivalent to 123 divided by 100, and 1.0E20 may by the same token be the exact integer 100,000,000,000,000,000,000. Per contra, 12 could be an inexact number that happens to have been rounded to the nearest integer. We are so used to the idea that dots and Es *mean* inexact, and their absence *means* exact, and that all our numbers are *inherently* bounded in range and (if non-integral) precision, that we think these things must be requirements of our data notation. But they aren't. I agree.. And I think most others here agree. The problem is that when we > go down the 'schema' road, we tend to end up with schema languages that > become baroque and more hassle than they are worth. The conclusion I drew from the XML Schema debacle is that schema languages get wrong-footed when they try to do two things at once: validating purely syntactically (as Relax NG does) and validating for data binding, especially to rigid static languages. Pretty much every programming language out there today will cause all > calculations to be performed in Intel 80 bit floating point until the data > has to be stored in a program data value when the mantissa will be > truncated at 52 bits and stored in a double. Practically every programming language can handle arbitrary size, aribtrary precision exact numbers, either as built-ins or through a library. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org De plichten van een docent zijn divers, die van het gehoor ook. --Edsger Dijkstra --000000000000eabcdc058856e8ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Tue, May 7, 2019 = at 5:30 PM Phillip Hallam-Baker <ietf@hallambaker.com> wrote:

    1) = The lexical analyzer may distinguish integers and floats and this may cause= a schema driven parser to reject legitimate number because it is encoded a= s a double. (e.g. 1.0)

    2) There may be precision loss because the number = is presented in exponential form (1.0E20)

    3) There may be prec= ision loss because the integer is larger than the floating point mantissa c= an hold.

    JSON encod= es absolutely no information about whether its numbers are to be interprete= d as exact or inexact.=C2=A0 1.23 may be an exact number equivalent to 123 = divided by 100, and 1.0E20 may by the same token be the exact integer 100,0= 00,000,000,000,000,000.=C2=A0 =C2=A0Per contra, 12 could be an inexact numb= er that happens to have been rounded to the nearest integer.=C2=A0 We are s= o used to the idea that dots and Es *mean* inexact, and their absence *mean= s* exact, and that all our numbers are *inherently* bounded in range and (i= f non-integral) precision, that we think these things must be requirements = of our data notation.=C2=A0 But they aren't.

    I agree.. And I think most othe= rs here agree. The problem is that when we go down the 'schema' roa= d, we tend to end up with schema languages that become baroque and more has= sle than they are worth.=C2=A0=C2=A0

    The co= nclusion I drew from the XML Schema debacle is that schema languages get wr= ong-footed when they try to do two things at once: validating purely syntac= tically (as Relax NG does) and validating for data binding, especially to r= igid static languages.

    Pretty much every programming language out there today wi= ll cause all calculations to be performed in Intel 80 bit floating point un= til the data has to be stored in a program data value when the mantissa wil= l be truncated at 52 bits and stored in a double.=C2=A0=C2=A0
    <= div>
    Practically every programming language can handle arbitr= ary size, aribtrary precision exact numbers, either as built-ins or through= a library.


    John Cowan=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 http://vri= ci.lojban.org/~cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 cowan@ccil.org
    De plichten van een docent zijn div= ers, die van het gehoor ook.
    =C2=A0 =C2=A0 =C2=A0 --Edsger Dijkst= ra
    =C2=A0
    --000000000000eabcdc058856e8ce-- From nobody Tue May 7 21:40:27 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 1998F12011F for ; Tue, 7 May 2019 21:40:26 -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_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 V4SmgWBKhvar for ; Tue, 7 May 2019 21:40:24 -0700 (PDT) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 DDA34120052 for ; Tue, 7 May 2019 21:40:23 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id o189so1402992wmb.1 for ; Tue, 07 May 2019 21:40:23 -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=RiYOhMvYVlsLrzRv7PvvltQRokwSJgSXmBgB2NWkdII=; b=LIKhLj+oeR2p4ZMStAB8SyfXBmU5BjHOlg+XwpRcUkAqsdxBWHN7TKQmtX71ZzJp3X NYS3kLu8klZ0xBO4Gi7IYNphWhX1bIsbYVvVH3bK+iu2phAKfTqEy6bxaQiz7zn1kCjn F1MYDINM6E7rzA/xEQqETI0fjv4xWqe96ikuBlbLBTcZx4qO6rahWCAClCL6uOhia670 ps1DndAU1rmipCSYKMhx6fb4KorO3xhghdzyvXCsxkhCpIPIhLhvTF+QpSpgTB03BqxO LVQNjiKtlNi/l9ADe/1AR1uxnh0lHGZQDaWnNHoDGrf0W6swQlPtRnw/M0DEoxMExNmC 3AoQ== 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=RiYOhMvYVlsLrzRv7PvvltQRokwSJgSXmBgB2NWkdII=; b=I82kk2Yqt45E4QkoBs4Iae3fcgfhTTJtQ79im+jMBo8kBBWLeWGmjyfIluOmQxR7l/ J+zqDv54U5eIcGp5jX9BeDHhKdMFb8i/r5qI4kk7Vxe5ps55PV+qL29YUSOchqFwtw3B hOqQnUvTymMG91s4ZHEZKN0OoWSt4l3hh9utAQNKYSex5SpqhzDtnk1NY1WrHMveyepe 1uOqGjgrZC/wwtmjqMUl00+xPBKI9DDZiltFX24HpbcsW+sGuDtZNr9KGN1uvSJ5YBdb BpjrwKukzTsGbyYNFocmGegMWGJTeVE/CiXBjBmcs4njEe7D7K6e+h5k9r2w1KM0o6Q9 8Atg== X-Gm-Message-State: APjAAAVA5AQKtFOS1o6RE1rQUm9fKaZe5UJ9/ecc9nULELvjyHphJJaE 8obmqdm6yPe8wZJvA5glmmJRVG9BCXs= X-Google-Smtp-Source: APXvYqwmULvXFt8zMqZmBs8CUAv30VOOplQnKMvxAJAb+29E7g7dJAuLZfG6N45ScH8yHWaeDMU4Rw== X-Received: by 2002:a1c:f616:: with SMTP id w22mr1244858wmc.28.1557290421758; Tue, 07 May 2019 21:40:21 -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 o130sm886449wmo.43.2019.05.07.21.40.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 May 2019 21:40:20 -0700 (PDT) To: Ulysse Carion Cc: Austin Wright , JSON WG References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> From: Anders Rundgren Message-ID: <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> Date: Wed, 8 May 2019 06:40:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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 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, 08 May 2019 04:40:26 -0000 I believe I have stated my opinion but here it is again: The idea is not changing JSON in any way but to add *strictness* to its interpretation. This has ZERO impact on JSON parsers but could in some cases affect JSON serialization. There are no problems defining a set of numeric types having a range and syntax that conforms to what is the norm for most programming languages since all of that fits nicely into JSON. However, assuming that any JSON parser also could be used for *implementing* JSL (including verifying arbitrary input data) will set the bar way too low. Regarding the integer discussion I believe Open API/Swagger which has quite an active and big user community already flags 3.0 as an invalid integer. A bug report on Open API (or on Jackson) would most likely return "works as intended". There's more, but I leave it there. Anders On 2019-05-08 01:57, Ulysse Carion wrote: > Hi all, > > I'd like to offer a summary of what has been stated thus far, so as to > make a bit more sense of the conversation. > > 1. Considerable ink has been spilled on the question of integers in a > schema language. The main question has been how such an integral > constraint should relate to serialization. > > 2. Some have raised questions around the terseness of JSON Schema and > JSON Schema Language. Proposed alternatives are JCR and CDDL, by their > respective editors. > > On the first question, I would agree with Messrs. Bormann and Bray, > who both suggest that a generic JSON parser runs first, followed by a > second pass over the data to convert the parsed data in the context of > a schema. On such a view, "3" and "3.0" are typically > indistinguishable by the time the schema is taken into account. > Bormann aptly notes that the alternative runs the risk of de facto > forking JSON itself. I don't think there is much more to be said on > the matter. > > The second question is perhaps more interesting, although it has > provoked less discussion. I went with JSON as the representation > because it makes building tooling atop of JSON Schema Language much > easier, since it doesn't require that the implementor write a parser. > Such ease of extension is valuable: JSON is widespread largely because > of how easy it is to build atop of, and we should not readily > sacrifice this. JSON as the representation also unlocks syntax > highlighting, formatting, and other such niceties for free. > Furthermore, and most importantly, using JSON as a representation does > not preclude later creating a RELAX NG-style compact representation > later on. > > I would also like to echo Bray's point about the real-world utility of > such a system. My day-job involves APIs, event-sourcing, and analytics > messages. In all three, JSON is the lingua franca, and in all three > considerable tedium is involved in writing and maintaining validators > and language-idiomatic containers for JSON messages. No > language-portable solution to this problem exists today, short of > moving away from JSON toward something like Protobufs or CBOR. > > I'd like to return to the initial question of this thread, this time rephrased: > > Are we in agreement that the question of describing JSON, and from > that description generating validators and idiomatic > classes/types/etc, is a problem worth solving? > > Are we in agreement that something along the lines of the proposed I-D > may be a way we address this problem? > > Best, > Ulysse > > On Tue, May 7, 2019 at 3:17 PM Nico Williams wrote: >> >> On Tue, May 07, 2019 at 02:56:10PM -0700, Erik Wilde wrote: >>> On 2019-05-07 14:48, Phillip Hallam-Baker wrote: >>>> at the risk of referring to XSD too much, but i think they got it right: >>>> >>>> - constraining facets for constraining the value space. >>>> - lexical facets for constraining the representation of values. >>>> >>>> I disagree on the constraining facets part. The only values I have found >>>> useful to put in a schema are 0 or 1 minimum occurrences and 1 or >>>> infinity maximum occurrences. >>> >>> there may be a misunderstanding here. constraining facets are limiting the >>> value space of datatypes, for example by defining minimum and maximum >>> values. >> >> As long as they don't constrain the encoding when multiple >> representations are available. >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json From nobody Tue May 7 21:44:00 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 613BE120125 for ; Tue, 7 May 2019 21:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 IDu2qPM-dq8h for ; Tue, 7 May 2019 21:43:55 -0700 (PDT) Received: from smtp.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 A5C59120052 for ; Tue, 7 May 2019 21:43:55 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44zP4n3Yy4zyZf; Wed, 8 May 2019 06:43:53 +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: Wed, 8 May 2019 06:43:52 +0200 Cc: JSON WG X-Mao-Original-Outgoing-Id: 578983430.893343-302d029010ca245cbcaa6fb329711992 Content-Transfer-Encoding: quoted-printable Message-Id: References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> To: Ulysse Carion X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 04:43:58 -0000 On May 8, 2019, at 01:57, Ulysse Carion wrote: >=20 > Are we in agreement that the question of describing JSON, Certainly. Describing protocols that are based on JSON benefits from a notation for = describing the JSON data items to be interchanged. So like we have ABNF for protocols based on text (there are only very = few people who would argue that ABNF is not useful =E2=80=94 yes, I have = met them, but I don=E2=80=99t agree with them), we have CDDL for = protocols based on the JSON data model (as realized in CBOR or JSON). = See https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/referencedby/ and = https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/refe= rencedby/ for some 30 IETF documents referencing the approved CDDL specification = or a previous version of it (CDDL has been essentially stable since = March 2015 and was finally approved in March 2019); CDDL is also being = used in other SDOs that define JSON-/CBOR-encoded protocols. > and from > that description generating validators and idiomatic > classes/types/etc, is a problem worth solving? Well, we probably have different ideas on the specific contexts in which = =E2=80=9Cvalidation=E2=80=9D and code generators become useful. (With = ABNF, there is a whole spectrum of =E2=80=9Cspecification only=E2=80=9D = usage up to parser generators that can read ABNF.) But having a = notation for the structures that the protocol provides is a first step = that is needed whenever validators and code generators are useful, which = they sometimes are. Other useful tools that benefit from a description = notation include example instance generators and pretty printers. Comparing JSON-based tools with XML-based ones, CDDL is probably closest = to Relax-NG (ISO/IEC 19757-2). There are other approaches for = describing data, e.g., Schematron (ISO/IEC 19757-3) for XML; I would = expect we will grow those approaches in conjunction with what we = already have. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 8 06:01:28 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 8812C1200FB for ; Wed, 8 May 2019 06:01:27 -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_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 SMAT-XWFcVRf for ; Wed, 8 May 2019 06:01:25 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 832811200F6 for ; Wed, 8 May 2019 06:01:25 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id h4so7839968wre.7 for ; Wed, 08 May 2019 06:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=x+0Pjpjggx5S1x8h+skmjPps+eKCivSmpxwgiTbQ8Cw=; b=q6S4jXxm2RiMjl75bmSr1nQCHLzObkwXYJuoM587AhE4LDKFT6LrDUfVV14wznOTCp aJUFPDjLDrxla7Ej8GpXIJfbsJKT5eBcROIMeIJOg12KoW1zjhxiIAA1FivcE7kpICwX dRvXOjSzohBV3yPqakQ9CKS00LWuLgbS0XjPZe3mfiHMnijmLFkd1lg5kKjDyhW9mARU XIN/AE1DnOdgHtXbRM9gUG4bK2rpjYnnHEOCxiKhEfYzYqqnQIL2Zsd3gLLzZyPsW6RA kkTgK60PVUMfP/QS5oKgYGy+VpjII8bDVw7ggU1HnLypZ/jxjCEzzoAPym9Ok/1nelfv dVvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=x+0Pjpjggx5S1x8h+skmjPps+eKCivSmpxwgiTbQ8Cw=; b=TI91wWoiXRWCUkva8ph2K+1OVRrXkpUR3vIQXDU7rYAi+MrkYPrMGHQ4rcOUqPRwOx /9aza7xMECYVEWeklrd2FgENenp56jyL+tezI6w7L/41l12kXa4XyWD97jcNFafiQWTe PPC7XaBh8AW1RkG5I6EEJb4tLN3TCcX+xjf5ERkwwJtdOtKoDXU7rlgtBiwS1zQdvBIA G9ySJQ0mWMLXNGEd1OggS7TJ+7DzkiarhS8ZqVV15PMoPJ5JOkLbnB0E0iqZYWyD7Pa7 mWiNvNY+OhwN+73wSWTFQ6ON63GSO7JWI0PFe9/c9aKVQ0FruiYl3canr481aZsm6AzF oxfw== X-Gm-Message-State: APjAAAVAt0IS6ni/7wMagoHJ7oguMI8kzCBon8HfuoHAmPHzuK8Xbj8Q 1F2A8FmuV9/LOMTVzeq+nVf7Y6oarjA= X-Google-Smtp-Source: APXvYqxnDnzbbteKake58w6YrBsJ7yd8bqCnYsO2gB16pm74oggGWqUmnAW9pO7drX6OicWrvu4lDQ== X-Received: by 2002:a05:6000:104:: with SMTP id o4mr28827716wrx.106.1557320483629; Wed, 08 May 2019 06:01:23 -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 130sm2270356wmd.15.2019.05.08.06.01.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 May 2019 06:01:22 -0700 (PDT) To: "json@ietf.org" From: Anders Rundgren Message-ID: <0eb4f515-d2fd-7494-e3dd-4d106be7e796@gmail.com> Date: Wed, 8 May 2019 15:01:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Json] JSON Canonicalization - IETF-104 Meeting Summary 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, 08 May 2019 13:01:27 -0000 In case you want to start a flame-war,  this may be what you have been looking for :) https://cyberphone.github.io/ietf-json-canon/ietf-104-report.html Or to be more serious: Please refrain from academic dissertations, JCS is actually not (at all) very sophisticated.  BY DESIGN. thanx, Anders From nobody Wed May 8 06:38: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 23A88120129 for ; Wed, 8 May 2019 06:38:13 -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 FQTBOJ7lUvuZ for ; Wed, 8 May 2019 06:38:11 -0700 (PDT) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98099120123 for ; Wed, 8 May 2019 06:38:10 -0700 (PDT) Received: (qmail 32203 invoked from network); 8 May 2019 14:36:18 +0100 Received: from host109-157-169-192.range109-157.btcentralplus.com (HELO ?192.168.1.72?) (109.157.169.192) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 8 May 2019 14:36:18 +0100 To: Austin Wright Cc: json@ietf.org References: <46584E26-AE7F-444C-A73C-BBB393BDCBD7@bzfx.net> From: Pete Cordell Message-ID: <3864ddba-4c67-2d01-a7e3-2c3a459eae02@codalogic.com> Date: Wed, 8 May 2019 14:38:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <46584E26-AE7F-444C-A73C-BBB393BDCBD7@bzfx.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 13:38:13 -0000 On 07/05/2019 22:50, Austin Wright wrote: > I still have to spend more time with JCR, but it appears to me JSON Schema implementations could import JCR documents as a JSON Schema with few problems, and it could very well be a superior method of authoring a JSON Schema. > > Would you consider elaborating on this possibility in JCR? At a guess, the best approach might be to have JCR to JSON Schema (and vice versa) translation tools, possibly as a library that can be included into other programs rather than as standalone tools in their own right. There will likely be some features that can't be translated. Identifying those features could be a useful exercise in converging the technologies. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Wed May 8 06:48: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 99EC312010D for ; Wed, 8 May 2019 06:48:17 -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 dpAGJANbdaBb for ; Wed, 8 May 2019 06:48:15 -0700 (PDT) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B4D120089 for ; Wed, 8 May 2019 06:48:14 -0700 (PDT) Received: (qmail 736 invoked from network); 8 May 2019 14:46:22 +0100 Received: from host109-157-169-192.range109-157.btcentralplus.com (HELO ?192.168.1.72?) (109.157.169.192) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 8 May 2019 14:46:20 +0100 To: Ulysse Carion Cc: JSON WG References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> From: Pete Cordell Message-ID: <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> Date: Wed, 8 May 2019 14:48:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 13:48:18 -0000 On 08/05/2019 00:57, Ulysse Carion wrote: > ... I went with JSON as the representation > because it makes building tooling atop of JSON Schema Language much > easier, since it doesn't require that the implementor write a parser. > Such ease of extension is valuable: JSON is widespread largely because > of how easy it is to build atop of, and we should not readily > sacrifice this. JSON as the representation also unlocks syntax > highlighting, formatting, and other such niceties for free. > Furthermore, and most importantly, using JSON as a representation does > not preclude later creating a RELAX NG-style compact representation > later on. This makes sense if the only things reading and writing JSON Schema are machines. Once you have humans involved, my experience (e.g. XML Schema) is that it is a bad choice. Writing XML Schema becomes more bearable if you have XML Schema aware editors. Being XML aware alone isn't sufficient. So in addition to having a JSON aware editor, you would also need a JSON Schema aware editor that included auto-suggestion and more advanced editing features beyond syntax highlighting etc like that. IMO, in that case you would be better off putting effort into a JSON specification format that didn't need as much help to edit it in the first place. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Wed May 8 08:46:27 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 00B6F12013C for ; Wed, 8 May 2019 08:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 OVsy3oTgA68S for ; Wed, 8 May 2019 08:46:22 -0700 (PDT) Received: from smtp.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 0DFE1120043 for ; Wed, 8 May 2019 08:46:22 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44zgn819BFzyNF; Wed, 8 May 2019 17:46:20 +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: <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> Date: Wed, 8 May 2019 17:46:19 +0200 Cc: Ulysse Carion , JSON WG X-Mao-Original-Outgoing-Id: 579023177.252328-62deaaede997e7f8288bd17aeeed7a87 Content-Transfer-Encoding: quoted-printable Message-Id: <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> To: Pete Cordell X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 15:46:25 -0000 On May 8, 2019, at 15:48, Pete Cordell wrote: >=20 > Writing XML Schema becomes more bearable if you have XML Schema aware = editors. Being XML aware alone isn't sufficient. Writing is not the main activity. Reading is. That is nearly = unbearable without tools. If I have to work on a W3C Schema(*), I convert it to Relax-NG compact = first. True, I=E2=80=99ll lose some information, but as a net result = I'll digest much more information out of the W3C Schema document than if = I had directly looked at that. At the time when I was closer to the XML community, the hallway = consensus was that W3C Schema was *designed* to sell more tools. (Hence my short note yesterday giving the CDDL translations for JSL; = that would probably be the way I would be reading =E2=80=94 or writing = =E2=80=94 JSL.) Gr=C3=BC=C3=9Fe, Carsten (*) The data description spec that W3C called XML Schema From nobody Wed May 8 08:51:27 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 8F133120155 for ; Wed, 8 May 2019 08:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 qCVf-3Q-VfPt for ; Wed, 8 May 2019 08:51:23 -0700 (PDT) Received: from ladybird.maple.relay.mailchannels.net (ladybird.maple.relay.mailchannels.net [23.83.214.98]) (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 265AB120274 for ; Wed, 8 May 2019 08:51:23 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 9308B5E2520; Wed, 8 May 2019 15:51:19 +0000 (UTC) Received: from pdx1-sub0-mail-a33.g.dreamhost.com (100-96-80-14.trex.outbound.svc.cluster.local [100.96.80.14]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 11A2C5E0D6E; Wed, 8 May 2019 15:51:19 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a33.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 08 May 2019 15:51:19 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Belong-Quick: 3904db501b825937_1557330679405_3129482382 X-MC-Loop-Signature: 1557330679405:3988147571 X-MC-Ingress-Time: 1557330679404 Received: from pdx1-sub0-mail-a33.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a33.g.dreamhost.com (Postfix) with ESMTP id 7E20380065; Wed, 8 May 2019 08:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=k3InLmTHVEIG8NA6AdM1iVjSPOc=; b=rQ4JUQlLo5m YraLuA4CJZzRpMhks1FMPnhV2Lh6tsdZ3nJHyEfxgc/O+SxlTBmeJLgqT8WbOgq5 lh1fIC0W0VL+Xi3OKHhZ5fLmf8RqC94OA9JCTm8VoYbuGIf7kxYh5vcM3owNe2kO LaD5zRhzYAdUWST3/pmagDvtMYCYEC3I= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 22A6C80063; Wed, 8 May 2019 08:51:13 -0700 (PDT) Date: Wed, 8 May 2019 10:51:11 -0500 X-DH-BACKEND: pdx1-sub0-mail-a33 From: Nico Williams To: Austin Wright Cc: Anders Rundgren , Tim Bray , json@ietf.org Message-ID: <20190508155110.GS21049@localhost> References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrkeefgdelgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 15:51:26 -0000 On Tue, May 07, 2019 at 02:13:33PM -0700, Austin Wright wrote: > > Integers do have a specific representation in JSON, and anything that > > precludes generic encoders that might emit 10.0 where a peer parser w= ill > > reject that as not-an-integer *is* a change to JSON. >=20 > I would put it slightly differently: While JSON doesn=E2=80=99t define = any > concept of an =E2=80=9Cinteger=E2=80=9D, applications that encode integ= ers (e.g. > uint32_t or similar) might conceivably emit it with the "frac=E2=80=9D > production (using a trailing decimal and zero); this is not ambiguous, > and in the interest of being liberal in what you accept, parsers > shouldn=E2=80=99t produce any error. +1 From nobody Wed May 8 09:03:28 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 B0ABF12012D for ; Wed, 8 May 2019 09:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 oG-jNqn4GDLO for ; Wed, 8 May 2019 09:03:24 -0700 (PDT) Received: from orchid.birch.relay.mailchannels.net (orchid.birch.relay.mailchannels.net [23.83.209.137]) (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 24B1F120089 for ; Wed, 8 May 2019 09:03:24 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 334FD342786; Wed, 8 May 2019 16:03:22 +0000 (UTC) Received: from pdx1-sub0-mail-a33.g.dreamhost.com (100-96-28-9.trex.outbound.svc.cluster.local [100.96.28.9]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 2CF1B341A92; Wed, 8 May 2019 16:03:20 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a33.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 08 May 2019 16:03:22 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Wipe-Stop: 7d4f5fb37b16a05a_1557331401418_3813076323 X-MC-Loop-Signature: 1557331401418:554141429 X-MC-Ingress-Time: 1557331401417 Received: from pdx1-sub0-mail-a33.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a33.g.dreamhost.com (Postfix) with ESMTP id D4E2180067; Wed, 8 May 2019 09:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=1foka0POQFDnzj WKvS9hOaXAwUk=; b=j2V/nKQeSftIGQsc1JDPLJLoy/DQR7jYpgXTJc9r2w7FEc BYOwyaxd8h1n4onEXJTpKEu3VR+by8ixjZBb/A5Vaeqrw3nVRuMfzUuh/sA4rKdz 8drgJv0hiFJDR0cHwK8hhQtTjHCRKlOdm5CrShrnIrDbhQd1Et/4KWmgCZpoM= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 2242A80063; Wed, 8 May 2019 09:03:13 -0700 (PDT) Date: Wed, 8 May 2019 11:03:11 -0500 X-DH-BACKEND: pdx1-sub0-mail-a33 From: Nico Williams To: Ulysse Carion Cc: Erik Wilde , Anders Rundgren , Austin Wright , Phillip Hallam-Baker , Tim Bray , JSON WG Message-ID: <20190508160309.GT21049@localhost> References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrkeefgdeliecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 16:03:27 -0000 On Tue, May 07, 2019 at 04:57:01PM -0700, Ulysse Carion wrote: > 1. Considerable ink has been spilled on the question of integers in a > schema language. The main question has been how such an integral > constraint should relate to serialization. > > 2. Some have raised questions around the terseness of JSON Schema and > JSON Schema Language. Proposed alternatives are JCR and CDDL, by their > respective editors. > > On the first question, I would agree with Messrs. Bormann and Bray, > who both suggest that a generic JSON parser runs first, followed by a It's not that "a generic JSON parser runs first, followed by ...", but that that must be a valid implementation choice. > second pass over the data to convert the parsed data in the context of > a schema. On such a view, "3" and "3.0" are typically > indistinguishable by the time the schema is taken into account. Correct. > Bormann aptly notes that the alternative runs the risk of de facto > forking JSON itself. I don't think there is much more to be said on > the matter. Excellent. I think that's been put to bed now. > The second question is perhaps more interesting, although it has > provoked less discussion. I went with JSON as the representation > because it makes building tooling atop of JSON Schema Language much > easier, since it doesn't require that the implementor write a parser. +1 I've been meaning for some time now to create an ASN.1 -> JSON schema converter. The idea would be to then use JS or jq to perform additional analysis / modifications, and generate code. In particular I'm looking to express code generation controls using path-like expressions and thus avoid having to express such controls as commentary or other modifications to an ASN.1 module. A similar approach using XML would also work, but then the right tool would be XSLT/XPath, and I'm not too keen on that, having written a not-too-trivial XSLT app. > Such ease of extension is valuable: JSON is widespread largely because > of how easy it is to build atop of, and we should not readily > sacrifice this. JSON as the representation also unlocks syntax > highlighting, formatting, and other such niceties for free. JSON is a bit awful, honestly, but yes, it has these properties: that is widely used, somewhat readable and editable, and has a lot of tooling available. > Furthermore, and most importantly, using JSON as a representation does > not preclude later creating a RELAX NG-style compact representation > later on. > > I would also like to echo Bray's point about the real-world utility of > such a system. My day-job involves APIs, event-sourcing, and analytics > messages. In all three, JSON is the lingua franca, and in all three > considerable tedium is involved in writing and maintaining validators > and language-idiomatic containers for JSON messages. No > language-portable solution to this problem exists today, short of > moving away from JSON toward something like Protobufs or CBOR. CBOR and other binary JSON formats have the benefit of keeping the data model, which means that existing tooling can easily be made to interface with them. > I'd like to return to the initial question of this thread, this time > rephrased: > > Are we in agreement that the question of describing JSON, and from > that description generating validators and idiomatic > classes/types/etc, is a problem worth solving? Of course it is. > Are we in agreement that something along the lines of the proposed I-D > may be a way we address this problem? I shall have to read it. Nico -- From nobody Wed May 8 09:07:59 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 4B07B120150 for ; Wed, 8 May 2019 09:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 XJ3cX4RWv2zx for ; Wed, 8 May 2019 09:07:53 -0700 (PDT) Received: from golden.birch.relay.mailchannels.net (golden.birch.relay.mailchannels.net [23.83.209.73]) (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 51BA812013C for ; Wed, 8 May 2019 09:07:53 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4EAF95020C6; Wed, 8 May 2019 16:07:52 +0000 (UTC) Received: from pdx1-sub0-mail-a33.g.dreamhost.com (100-96-15-20.trex.outbound.svc.cluster.local [100.96.15.20]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 27B0A502118; Wed, 8 May 2019 16:07:51 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a33.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 08 May 2019 16:07:52 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Stretch-Rock: 25d856eb1203cc7a_1557331671694_624645791 X-MC-Loop-Signature: 1557331671694:1951836751 X-MC-Ingress-Time: 1557331671693 Received: from pdx1-sub0-mail-a33.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a33.g.dreamhost.com (Postfix) with ESMTP id 870C580062; Wed, 8 May 2019 09:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=FFZCyDRf85BAxB 4ickXiQHx2vWE=; b=CzcjQB9jYEq/8n0dhxrJG1uu5IGPHJlBnVOuFPVJCl4oZm JSKQXNqiIC44HpBLL4rk9B1scbIx15/3YBRMgBoFRyRHTS80Wjkda3Y4Iq6Dv9F5 GeI7X5OUXr0SWYkp0yV8FiDAO2HUd7R1xPYEoVs2AbckeFkAfwdAu22FgoSs8= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a33.g.dreamhost.com (Postfix) with ESMTPSA id AC69D8003F; Wed, 8 May 2019 09:07:43 -0700 (PDT) Date: Wed, 8 May 2019 11:07:41 -0500 X-DH-BACKEND: pdx1-sub0-mail-a33 From: Nico Williams To: Anders Rundgren Cc: Ulysse Carion , Austin Wright , JSON WG Message-ID: <20190508160740.GU21049@localhost> References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrkeefgdeljecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 16:07:55 -0000 On Wed, May 08, 2019 at 06:40:14AM +0200, Anders Rundgren wrote: > I believe I have stated my opinion but here it is again: > > The idea is not changing JSON in any way but to add *strictness* to > its interpretation. That's not an innocent change. It breaks interoperability. > This has ZERO impact on JSON parsers but could in some cases affect Not true: it makes them reject more inputs, which makes them less interoperable. > JSON serialization. Exactly, so not OK. > There are no problems defining a set of numeric types having a range > and syntax that conforms to what is the norm for most programming > languages since all of that fits nicely into JSON. This is insufficient justification for making JSON parsing more strict. > However, assuming that any JSON parser also could be used for > *implementing* JSL (including verifying arbitrary input data) will set > the bar way too low. > > Regarding the integer discussion I believe Open API/Swagger which has > quite an active and big user community already flags 3.0 as an invalid > integer. A bug report on Open API (or on Jackson) would most likely > return "works as intended". That's an interop bug. They should fix it. Nico -- From nobody Wed May 8 09:43:00 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 022BB120225 for ; Wed, 8 May 2019 09:42:59 -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, 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 1v9Rgs3RmGpP for ; Wed, 8 May 2019 09:42:56 -0700 (PDT) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 86E12120173 for ; Wed, 8 May 2019 09:42:56 -0700 (PDT) Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:59911 helo=[192.168.1.78]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hOPeg-0007oH-83; Wed, 08 May 2019 12:42:54 -0400 To: Carsten Bormann , Pete Cordell Cc: JSON WG , Ulysse Carion References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> From: Erik Wilde Message-ID: <5a592d14-9468-6420-8420-52fd84a588fd@dret.net> Date: Wed, 8 May 2019 09:42:52 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 16:42:59 -0000 On 2019-05-08 08:46, Carsten Bormann wrote: > If I have to work on a W3C Schema(*), I convert it to Relax-NG compact first. True, I’ll lose some information, but as a net result I'll digest much more information out of the W3C Schema document than if I had directly looked at that. > At the time when I was closer to the XML community, the hallway consensus was that W3C Schema was *designed* to sell more tools. that's one way to look at it. given the complexity of XSD's model (which is a different discussion to have), it's hard to imagine how you could easily work with it just using a generic underlying model (of any kind: even the RNG compact syntax isn't easily revealing all relationships). it's probably fair to say that any sufficiently complex domain model will require you to use tooling supporting it, instead of being able to just work with a source file of any format. to me, the first discussion to have is how complex/powerful you want the domain model to be (XSD went completely overboard there). *after* that has been decided, and if it is of modest complexity, then it may make sense to consider a syntax based on a generic model so that people can directly read (and possibly even write) the source. for old times sake, at https://www.xml.com/pub/a/2003/08/27/xscs.html is a specific XSD syntax we worked on to have a good "source file UX" for XSD. of course it never caught on because people used tools anyways, and this approach required specific code for reading and writing XSCS. cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Wed May 8 10:00:01 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 620AA120164 for ; Wed, 8 May 2019 10:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 HCAb1g0pUUOb for ; Wed, 8 May 2019 09:59:58 -0700 (PDT) Received: from smtp.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 31157120189 for ; Wed, 8 May 2019 09:59:58 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44zjQ362RhzyNF; Wed, 8 May 2019 18:59:54 +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: <20190508160740.GU21049@localhost> Date: Wed, 8 May 2019 18:59:54 +0200 Cc: JSON WG X-Mao-Original-Outgoing-Id: 579027591.743409-5396a9c1703ba3cb3e1837f1a47a80ae Content-Transfer-Encoding: quoted-printable Message-Id: References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Json] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 17:00:01 -0000 On May 8, 2019, at 18:07, Nico Williams wrote: >=20 > That's an interop bug. They should fix it. It also nicely demonstrates the law of inevitable extensibility. JSON was designed not to provide extensibility. Ever. Radical, but a well motivated idea at the time. Now people did not want to accept that. They wanted to extend the JSON data model with the distinction between = two number types. The law of inevitable extensibility says: # If you don=E2=80=99t provide an extension point, somebody will. # They will shove their extension into any crevice available. # (And your up to now rock-solid design breaks.) The crevice here was that there are many ways to express the number 3: = 3, 3.0, 3e0, 0.03e2, 300e-2 etc. We can give some of these expressions = different semantics than the other. Voila. Extensibility achieved. = Brittleness added. I have seen the law of inevitable extensibility applied to: =E2=80=94 duplicate map keys for adding comments to JSON. Some people = believe: { =E2=80=9Cpostcode=E2=80=9D: =E2=80=9CThis is a comment about the = post code 4711=E2=80=9D, =E2=80=9Cpostcode=E2=80=9D: 4711 } is a valid way to extend JSON with comments. (Because their = implementation happens to ignore map keys that are invalidly used again = later, which is not a given.) - unnecessary escaping for ascribing some special semantics. Say, if a = string starts with =E2=80=9C\u0073=E2=80=9D and not with the equivalent = =E2=80=9Cs=E2=80=9D, this is supposed to mean the string has some = different semantics (e.g., the rest is a base64url encoded byte string = as opposed to what would normally be a text string, or a type tag, = or=E2=80=A6). =E2=80=94 millions of ways of interpreting whitespace or the lack = thereof. I=E2=80=99ve lost count. I do not think any longer that anything that is meant to see significant = usage can be designed without designing in extensibility points from the = start. At least if it is supposed to last. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 8 10:01:37 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 1C2F61202B0 for ; Wed, 8 May 2019 10:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Gu4AL3ciNTeP for ; Wed, 8 May 2019 10:01:34 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 D995B1202C1 for ; Wed, 8 May 2019 10:01:25 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id h4so8884803wre.7 for ; Wed, 08 May 2019 10:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:cc:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=yhDFbnv9Avd+JaLfki3rEs+MVW4KWrn7gOHHIeEq+F4=; b=gq4PuLfRoaNDw/MoevZu44nYbpm9zZNMKj8oTSMhN3cm+4nX2hWWxnu+7JvAFkHLZ3 Horo6E7MxPsn3vm3tVWQ3u0lowyg8GeakyNtexOJfPrYSoa6CEd/ZfS4W8k4FFLtb6Y1 LOnuMMksFUeW7gc7fUoKhEPP5qYosIVXcd4A9x58RhoVZw6fkpmcYXQquy7K70rwf40i q7m2UhU0lfoNHJd7dQFuFCf+uBH6M6GvLGK3bM99gXwOtYbEggaKNkRJgIUcjwtZ0+I4 N6YJ8yEZuhCEq4dssuqm5UzJgNPJYzc1AGHg0YsGGiTt/2qUdUWjhE7ztvBupRGQ66Y7 KsJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yhDFbnv9Avd+JaLfki3rEs+MVW4KWrn7gOHHIeEq+F4=; b=tGEk5WynNJc3z0T+48aZlf+jeLho3Nr3x0jmq75zLu8CF+NC8lXpOC06Kzh/vh07Xk OmeY+Es2cyLEbNhKdZimWRHNmvZ0nXkn5K0t28KaCK4fQIbQAeKR99SZVHc6bSwpVMBL BKnAc5jI5YNpb6IhXaE30iYgVz4jAQX4q+9W9ScoqAGtRWuERx7m8MwAqKebkzp6KzRI 1IMe9Xu3Seu72LPd468W8PI5pS/Fj4snX6ER/Cm6pZk6e7yd8XLQZb19vqmp6aabrde4 MfSE3AgMnoaXWCm4PH9ob7wz6oFcEJu6F1butgorCS2coka60h67SX678REVB2nqDy2O 2a3A== X-Gm-Message-State: APjAAAUZnnYccZrxYU3Kdw9Sw91OxDLWnIsdzd0vjyKSiznZtxqUS2eZ miSclI6DGg3ftHSGoG0PtaDWiN4X3EM= X-Google-Smtp-Source: APXvYqwJG4a/sKf9XoZfN96+Yz4cBZQNyRo6HvoAKepUaaaSWJAwDNeD/EnZYCLHu23xY3qgrXAiMQ== X-Received: by 2002:adf:fe10:: with SMTP id n16mr1027265wrr.304.1557334883804; Wed, 08 May 2019 10:01:23 -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 x17sm17752308wru.27.2019.05.08.10.01.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 May 2019 10:01:22 -0700 (PDT) Cc: Ulysse Carion , Austin Wright , JSON WG References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> From: Anders Rundgren Message-ID: <821ce39a-01a6-8c2c-4323-96b41f4248c7@gmail.com> Date: Wed, 8 May 2019 19:01:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190508160740.GU21049@localhost> 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 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, 08 May 2019 17:01:36 -0000 Since I have what appears to be the diametrically opposed opinion, I'd better leave it there [*]. Flame-wars are kinda boring. That a stricter interpretation (=subset) could break parsers is beyond my understanding. Probably it is because you seem to plot with a different order of execution. Or maybe the problem is rather than you want to apply schemas to existing systems, [almost] irrespective how broken these may be? In my book you start by validating data (strict) and only if that works out you dispatch it to your good ol' JSON tools and applications to digest. For verifying serializations you would do the opposite. Anyway, I wish you good luck with your project! cheers, Anders *] I won't respond.... On 2019-05-08 18:07, Nico Williams wrote: > On Wed, May 08, 2019 at 06:40:14AM +0200, Anders Rundgren wrote: >> I believe I have stated my opinion but here it is again: >> >> The idea is not changing JSON in any way but to add *strictness* to >> its interpretation. > > That's not an innocent change. It breaks interoperability. > >> This has ZERO impact on JSON parsers but could in some cases affect > > Not true: it makes them reject more inputs, which makes them less > interoperable. > >> JSON serialization. > > Exactly, so not OK. > >> There are no problems defining a set of numeric types having a range >> and syntax that conforms to what is the norm for most programming >> languages since all of that fits nicely into JSON. > > This is insufficient justification for making JSON parsing more strict. > >> However, assuming that any JSON parser also could be used for >> *implementing* JSL (including verifying arbitrary input data) will set >> the bar way too low. >> >> Regarding the integer discussion I believe Open API/Swagger which has >> quite an active and big user community already flags 3.0 as an invalid >> integer. A bug report on Open API (or on Jackson) would most likely >> return "works as intended". > > That's an interop bug. They should fix it. > > Nico > From nobody Wed May 8 11:31:51 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 3A3061201D0 for ; Wed, 8 May 2019 11:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 21nfBOyPs9Zf for ; Wed, 8 May 2019 11:31:47 -0700 (PDT) Received: from goldenrod.birch.relay.mailchannels.net (goldenrod.birch.relay.mailchannels.net [23.83.209.74]) (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 705E712013C for ; Wed, 8 May 2019 11:31:47 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id AB2EA2104A; Wed, 8 May 2019 18:31:46 +0000 (UTC) Received: from pdx1-sub0-mail-a9.g.dreamhost.com (100-96-30-10.trex.outbound.svc.cluster.local [100.96.30.10]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id F02F42252C; Wed, 8 May 2019 18:31:40 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a9.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 08 May 2019 18:31:46 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Army-Army: 07b5c4152c878725_1557340306434_1092658021 X-MC-Loop-Signature: 1557340306434:2462942237 X-MC-Ingress-Time: 1557340306434 Received: from pdx1-sub0-mail-a9.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTP id 8DC8C7FCA0; Wed, 8 May 2019 11:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=MTwubr71ola6EHjrWH/fvxVuZTA=; b=cgrIFDrtHxc q6ZJ51RIxnke6s6GZFaewjTPTwOdGvBrdF/Ks9XMJxVyH4A/1fQlOVKYDOWuxnBl tAOWnGaIqlli1BNTb/vfJ/KXfk4ACb/8YJf9q/v5n/6GHqYu4sIBu68BL8c0KRJ1 sov/NbhsvreMv8HuTf2iioBNzeSiiG9k= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 869537FC9E; Wed, 8 May 2019 11:31:33 -0700 (PDT) Date: Wed, 8 May 2019 13:31:31 -0500 X-DH-BACKEND: pdx1-sub0-mail-a9 From: Nico Williams To: Carsten Bormann Cc: JSON WG Message-ID: <20190508183130.GV21049@localhost> References: <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrkeefgdduvdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 18:31:49 -0000 On Wed, May 08, 2019 at 06:59:54PM +0200, Carsten Bormann wrote: > On May 8, 2019, at 18:07, Nico Williams wrote: > > That's an interop bug. They should fix it. >=20 > It also nicely demonstrates the law of inevitable extensibility. >=20 > JSON was designed not to provide extensibility. Ever. > Radical, but a well motivated idea at the time. The spec allows extensions, actually, but indeed, it doesn't provide for extensibility. (For example, jq will parse Inf and Infinity, but it will not output such words, nor will it output NaN.) > The law of inevitable extensibility says: >=20 > # If you don=E2=80=99t provide an extension point, somebody will. > # They will shove their extension into any crevice available. > # (And your up to now rock-solid design breaks.) The particular "extension" we're talking about isn't an extension. > The crevice here was that there are many ways to express the number 3: > 3, 3.0, 3e0, 0.03e2, 300e-2 etc. We can give some of these > expressions different semantics than the other. Voila. Extensibility > achieved. Brittleness added. If anything one would expect this to bring up canonicalization... (oh no, I've mentioned that. please no one take that as a serious invitation to discuss canonical JSON!) > I have seen the law of inevitable extensibility applied to: >=20 > =E2=80=94 duplicate map keys for adding comments to JSON. Some people = believe: >=20 > { =E2=80=9Cpostcode=E2=80=9D: =E2=80=9CThis is a comment about the po= st code 4711=E2=80=9D, > =E2=80=9Cpostcode=E2=80=9D: 4711 } >=20 > is a valid way to extend JSON with comments. (Because their > implementation happens to ignore map keys that are invalidly used > again later, which is not a given.) Yes. > - unnecessary escaping for ascribing some special semantics. Say, if > a string starts with =E2=80=9C\u0073=E2=80=9D and not with the equivale= nt =E2=80=9Cs=E2=80=9D, this is > supposed to mean the string has some different semantics (e.g., the > rest is a base64url encoded byte string as opposed to what would > normally be a text string, or a type tag, or=E2=80=A6). Oof. > =E2=80=94 millions of ways of interpreting whitespace or the lack there= of. > I=E2=80=99ve lost count. Play stupid games... > I do not think any longer that anything that is meant to see > significant usage can be designed without designing in extensibility > points from the start. At least if it is supposed to last. Maybe. Nico --=20 From nobody Wed May 8 11:49:13 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 701041201EC for ; Wed, 8 May 2019 11:49:12 -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_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 kfkcCw1aoUHo for ; Wed, 8 May 2019 11:49:11 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 E9C651201ED for ; Wed, 8 May 2019 11:49:10 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id 94so5503562uaf.10 for ; Wed, 08 May 2019 11:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=H+cAVja39EJgxM2pojQNYVMbZLBqbiZvNIS68WicZ98=; b=SeMbsz+U2WWi+n2RPr9LX7fLYs8a7ZT8/yyd3BijN8lBXop2yHZKiA2X0ex52MTJU8 TIs8yHR24M2wl7G+SlGmUcNN24fSFQArnRtJSFoedom776E/UOKbj7zd7GtTUGz+clGm iHXB0ekmiAiIvnOxPy2Q6UxcpTGWn/56u4ahfcFl45SZGlpocrCBzvTxcsFg0v50Xk+J RH9F2DURLLGi8tQPetOaHU3eZGvZ4NanZDAKrsHnau0mcLc1ZtgwCumRc8lVB61X7xQz YWW3bNkIxx0xCBJ+ZFqbqFh/nbOxTCOi8bjpulIWCsBr5GZu7SSOMbeLolJkzqK02vFZ f/gQ== 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=H+cAVja39EJgxM2pojQNYVMbZLBqbiZvNIS68WicZ98=; b=rBux+LXvVchXHn06IFLuKZNuNeoqzkecHjeYJU9sfZDmHc4LyxGkq/6OIt2TwMZTds PkGJFJFXBt/sS3cle/YbCnSEZmzczaQmxUlEYtsYIRyIvGTopgdNegc6zRr3N76ExjR0 1tB9A3qn04DWxOwdwhkfKF8f4eLqkeCFXSlWVrJC35/WdcsXIOdsXqiuoX8HMcq0CRSo y5pabC/FwYVkKGPaedZDWxzrTTEIeNwa85Rxl9WP9nFATA7eBsDYTdx1fvFuAAb9bk6D mEEhjx0nyiLwJoZqieAKzc7bo26vqXZVVp8UN2g8mLRZts1+UfW5DuxDWUDxEbuOKI0c b5Tg== X-Gm-Message-State: APjAAAXvP0CJM/oJSAU2cAT65THv29xj5L4+/o5GL2lJR8/MAzvci0BG 3oTkxZrL2tsD8u9K28bwbUEyoNBcP4RJwfKNqghdmr3G X-Google-Smtp-Source: APXvYqx+oqVY1SvrFV1dPqcX+bDpP3bmty+X3zpSS+8714BZxe6DENuh3nwbEW/oKgOzxLxD+l42Q50cIjKItm1EOXQ= X-Received: by 2002:ab0:6595:: with SMTP id v21mr7692822uam.113.1557341349660; Wed, 08 May 2019 11:49:09 -0700 (PDT) MIME-Version: 1.0 From: Daniel P Date: Wed, 8 May 2019 14:48:58 -0400 Message-ID: To: JSON WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 18:49:12 -0000 On May 8, 2019, at 15:48, Pete Cordell ; wrote: > On 08/05/2019 00:57, Ulysse Carion wrote: >> ... I went with JSON as the representation >> because it makes building tooling atop of JSON Schema Language much >> easier, since it doesn't require that the implementor write a parser. > This makes sense if the only things reading and writing JSON Schema are > machines. Once you have humans involved, my experience (e.g. XML > Schema) is that it is a bad choice. Agreed, I don't think there is any compelling reason to choose JSON as the representation for a schema language. The grammar of JCR, for instance, is not particularly difficult to implement, and cannot reasonably be considered as a barrier to its adoption. What is a barrier is the absence of any clear coalescing around any schema proposal, apart from the defacto standard one, JSON Schema. Without that, it's hard to see people making the investment. Daniel From nobody Wed May 8 12:30: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 A5CCF1201FA for ; Wed, 8 May 2019 12:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 4e-m9DxAuYBx for ; Wed, 8 May 2019 12:30:40 -0700 (PDT) Received: from smtp.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 C024F1201CA for ; Wed, 8 May 2019 12:30:39 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44zmlx2pLDzybH; Wed, 8 May 2019 21:30:37 +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: <20190508183130.GV21049@localhost> Date: Wed, 8 May 2019 21:30:36 +0200 Cc: JSON WG X-Mao-Original-Outgoing-Id: 579036634.4782569-d40057c4d26aac1a8239b4ad9ef3b935 Content-Transfer-Encoding: quoted-printable Message-Id: <52F0F8D4-277F-4E7E-A5E0-7444C83DEF57@tzi.org> References: <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> <20190508183130.GV21049@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 19:30:43 -0000 Hi Nico, > On May 8, 2019, at 20:31, Nico Williams wrote: >=20 > On Wed, May 08, 2019 at 06:59:54PM +0200, Carsten Bormann wrote: >> On May 8, 2019, at 18:07, Nico Williams = wrote: >>> That's an interop bug. They should fix it. >>=20 >> It also nicely demonstrates the law of inevitable extensibility. >>=20 >> JSON was designed not to provide extensibility. Ever. >> Radical, but a well motivated idea at the time. >=20 > The spec allows extensions, actually, but indeed, it doesn't provide = for > extensibility. >=20 > (For example, jq will parse Inf and Infinity, but it will not output > such words, nor will it output NaN.) Huh? RFC 8259 is very outspoken here: Numeric values that cannot be represented in the grammar below (such as Infinity and NaN) are not permitted. So you have a superset of JSON as your jq input grammar, which is fine = for me (it just isn=E2=80=99t JSON anymore). Maybe you mean the = sentence in the section about Parsers: A JSON parser MAY accept non-JSON forms or extensions. Yep, non-JSON. JSON has no extensibility points. >> The law of inevitable extensibility says: >>=20 >> # If you don=E2=80=99t provide an extension point, somebody will. >> # They will shove their extension into any crevice available. >> # (And your up to now rock-solid design breaks.) >=20 > The particular =E2=80=9Cextension" we're talking about isn't an = extension. Extending the data model to enable expressing two different kinds of = numbers, which are identical in numeric value (i.e., JSON semantics), = but have different semantics in the data model defined by the extension = (distinguishing integer 3 from floating point 3), definitely is an = extension. The fact that only instances are communicated that are also = valid under (by definition unextended) JSON semantics doesn=E2=80=99t = change this. >> The crevice here was that there are many ways to express the number = 3: >> 3, 3.0, 3e0, 0.03e2, 300e-2 etc. We can give some of these >> expressions different semantics than the other. Voila. = Extensibility >> achieved. Brittleness added. >=20 > If anything one would expect this to bring up canonicalization... > (oh no, I've mentioned that. please no one take that as a serious > invitation to discuss canonical JSON!) C14n is a different thing: It reduces the number of different = representations allowed for a specific instance in the data model. = There is no new semantics. A generic decoder will have no problem with = inputting a c14nized serialization. A generic encoder won=E2=80=99t = always spit out a c14nized instance (and we don=E2=80=99t expect it to), = but a step can be added to convert the JSON instance into the equivalent = c14nized instance without breaking that generic JSON encoder. This is = all fairly innocuous. (It is also hard, and the specific proposal = pushed here neither has fully demonstrated that it has nailed the hard = parts nor does it use reasonable taste =E2=80=94 principle of least = surprise =E2=80=94 in some other places. Convert to UTF-16-BE before = sorting? Oof. But sure, sorting Hittite characters between hangul Jamo = and private use can be made interoperable, if it rocks your boat.) More = importantly, C14n ensures that there is no appetite for interpreting two = lexically different instances that have the same semantics in JSON as = different =E2=80=94 at least one of them couldn=E2=80=99t be C14nal! > [=E2=80=A6] Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 8 12:58:49 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 293731200DE for ; Wed, 8 May 2019 12:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 9RCjPxJti1Oo for ; Wed, 8 May 2019 12:58:46 -0700 (PDT) Received: from catfish.maple.relay.mailchannels.net (catfish.maple.relay.mailchannels.net [23.83.214.32]) (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 1AF8012009C for ; Wed, 8 May 2019 12:58:45 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 62DD52C302D; Wed, 8 May 2019 19:58:45 +0000 (UTC) Received: from pdx1-sub0-mail-a9.g.dreamhost.com (100-96-80-14.trex.outbound.svc.cluster.local [100.96.80.14]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BE0392C22CF; Wed, 8 May 2019 19:58:44 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a9.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 08 May 2019 19:58:45 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Arithmetic-Cellar: 215fcaf16410eef3_1557345525231_2242767642 X-MC-Loop-Signature: 1557345525231:4051232021 X-MC-Ingress-Time: 1557345525231 Received: from pdx1-sub0-mail-a9.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTP id 76F177FCA2; Wed, 8 May 2019 12:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=ZP1uDGnYVUjtTEbMHI+u3g+e13Q=; b=bpsgE/VlyuE zN4yZ6sBS8hsagzDDlkJhEOb/6ilRkgXaeWfH/vyZsOBJIi9Gd5XyxfvIg+Yq2L0 NFrfmIh+hOowYt2W0zzQs+1J+b6oReT2+UNAsDmsQDw6RkLL8aLF9ei/P0nNXI/g M3WT+zzyfukTE/l8Sw7RJA7NYDGBPsI0= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 8FB577FC9F; Wed, 8 May 2019 12:58:37 -0700 (PDT) Date: Wed, 8 May 2019 14:58:35 -0500 X-DH-BACKEND: pdx1-sub0-mail-a9 From: Nico Williams To: Carsten Bormann Cc: JSON WG Message-ID: <20190508195834.GW21049@localhost> References: <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> <20190508183130.GV21049@localhost> <52F0F8D4-277F-4E7E-A5E0-7444C83DEF57@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <52F0F8D4-277F-4E7E-A5E0-7444C83DEF57@tzi.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrkeefgddugeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 19:58:48 -0000 On Wed, May 08, 2019 at 09:30:36PM +0200, Carsten Bormann wrote: > Hi Nico, >=20 > > On May 8, 2019, at 20:31, Nico Williams wrote= : > >=20 > > On Wed, May 08, 2019 at 06:59:54PM +0200, Carsten Bormann wrote: > >> On May 8, 2019, at 18:07, Nico Williams wrot= e: > >>> That's an interop bug. They should fix it. > >>=20 > >> It also nicely demonstrates the law of inevitable extensibility. > >>=20 > >> JSON was designed not to provide extensibility. Ever. > >> Radical, but a well motivated idea at the time. > >=20 > > The spec allows extensions, actually, but indeed, it doesn't provide = for > > extensibility. > >=20 > > (For example, jq will parse Inf and Infinity, but it will not output > > such words, nor will it output NaN.) >=20 > Huh? RFC 8259 is very outspoken here: >=20 > Numeric values that cannot be represented in the grammar below (such > as Infinity and NaN) are not permitted. >=20 > So you have a superset of JSON as your jq input grammar, which is fine > for me (it just isn=E2=80=99t JSON anymore). Maybe you mean the senten= ce in > the section about Parsers: >=20 > A JSON parser MAY accept non-JSON forms or extensions. Yes. > Yep, non-JSON. JSON has no extensibility points. A JSON-like text with 'Infinity' in it is not-JSON. > > The particular =E2=80=9Cextension" we're talking about isn't an exten= sion. >=20 > Extending the data model to enable expressing two different kinds of > numbers, which are identical in numeric value (i.e., JSON semantics), > but have different semantics in the data model defined by the > extension (distinguishing integer 3 from floating point 3), definitely > is an extension. The fact that only instances are communicated that > are also valid under (by definition unextended) JSON semantics doesn=E2= =80=99t > change this. Yes, but note that accepting 'Infinity' doesn't cause an interoperability problem, while rejecting '3.0' does. Nico --=20 From nobody Wed May 8 15:49:29 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 B841E120194 for ; Wed, 8 May 2019 15:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net 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 IIkaKjHIQ-Wz for ; Wed, 8 May 2019 15:49:23 -0700 (PDT) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (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 AA3661200E0 for ; Wed, 8 May 2019 15:49:23 -0700 (PDT) Received: by mail-pf1-x444.google.com with SMTP id v80so209592pfa.3 for ; Wed, 08 May 2019 15:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uYaLI6tHXrYgppIK9m9Gr0EmG+cakljTrIlnIKaerJA=; b=qZ9Rd6Pr1DBEJYxIssGvyPFZG1JaPXZ9rvWT/1D2XJiNFBu61dZGh2GXuPBtGbhOZv 9/3yIybA3/pY5mtAuWl5gkXMxqSdv3QCKEerdApCmGZqbp2CM4/qYqidrOfjnJ0OlOyR MfQ0UQr1mEuA9/6XPHyhCtc54DzF/l5EhpTi4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uYaLI6tHXrYgppIK9m9Gr0EmG+cakljTrIlnIKaerJA=; b=K18I5YoZzFWPH2wygNGrhI+0ugMP0c2JDZcuzfmqNmHFw6ifvW3McxqaOgqNa0rtPM 3G6JGUTR/8sWMwo21T/a5x1GhgGe9dpwHPe+1gEw9m9L2jtyjtKhaoqTesWwZZEGzmFk ypqZPokm0x8I4pXnh5pd8eeaVfsL3JDhyfTovd5f6N9ZCJKWoyAdeRyX7QAJgz12CZ/T yk6gzbGKn9/TUZkGxRUfW0jc/Dh/UvzC97rWskfIUAL6dlm6+DT3GF+ppVBCJ77UZxqZ 58BWNOqT0Ftu1NGI77MwP0VqI073UrkAD59HyxlCcJ73tqs7DM1RDZ+DdWQPMCGWbW2I valw== X-Gm-Message-State: APjAAAW5JR4mIsKPn83csC3MfzGp1+uoalpkgbJZYiEDfQWoeGPk8RsE zD+kpPXnJMtQ9Z2weJToJDaxWw== X-Google-Smtp-Source: APXvYqy6chgXrveFFFCrG3A50BGp+d/25qkQCqdg82o07QzXZPnvkg/v2el0L/hpeBANuO74K+7HsQ== X-Received: by 2002:a65:5003:: with SMTP id f3mr863888pgo.336.1557355762797; Wed, 08 May 2019 15:49:22 -0700 (PDT) Received: from [192.168.0.116] ([184.101.46.90]) by smtp.gmail.com with ESMTPSA id r18sm354926pfd.89.2019.05.08.15.49.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 May 2019 15:49:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Austin Wright In-Reply-To: Date: Wed, 8 May 2019 15:49:20 -0700 Cc: Nico Williams , JSON WG Content-Transfer-Encoding: quoted-printable Message-Id: <02755092-1682-45E8-AB6C-0EDA7D35703A@bzfx.net> References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Json] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 22:49:27 -0000 > On May 8, 2019, at 09:59, Carsten Bormann wrote: >=20 > On May 8, 2019, at 18:07, Nico Williams wrote: >>=20 >> That's an interop bug. They should fix it. >=20 > It also nicely demonstrates the law of inevitable extensibility. >=20 > JSON was designed not to provide extensibility. Ever. > Radical, but a well motivated idea at the time. >=20 > Now people did not want to accept that. > They wanted to extend the JSON data model with the distinction between = two number types. Who=E2=80=99s =E2=80=9Cthey=E2=80=9D? There=E2=80=99s only two uses of = =E2=80=9Cinteger=E2=80=9D in relation to JSON that I=E2=80=99m aware of: 1. Implementations that parse JSON documents into a pre-defined = structure, and will raise an error if the struct cannot store the = lexical data (for example, putting a null into a int64_t, or an object = into a char*). 2. JSON Schema, which defines integer as a strict subset of = =E2=80=9Cnumber=E2=80=9D. (It=E2=80=99s not even a data model type, = it=E2=80=99s a special case for the =E2=80=9Ctype=E2=80=9D keyword that = means the same as `{type:=E2=80=9Dnumber=E2=80=9D, multipleOf:1}`) Neither of these =E2=80=9Cextend" JSON, because JSON does not impose any = requirements on how implementations parse numbers. My reading of RFC8259 = allows implementations to differentiate between `3` vs `3.0` vs `3.00`. Nonetheless, JSON Schema specifies that numbers are mathematical, so = `10.0` would still be considered an integer. Likewise, I think parsers = should ignore excess precision if it doesn=E2=80=99t change the = mathematical value. But this is entirely a choice based on how most = implementations work; rather than what JSON seems to allow. For example, = scientific software might store significant figures such that `10.0` is = considered less precise than `10.000`. In my reading of RFC8259 and ECMA = 404, this is perfectly legal, but JSON Schema makes no distinction for = validation purposes (i.e. there would be no way to assert =E2=80=9Cnumber = must be at least this precise=E2=80=9D). >=20 > The law of inevitable extensibility says: >=20 > # If you don=E2=80=99t provide an extension point, somebody will. > # They will shove their extension into any crevice available. > # (And your up to now rock-solid design breaks.) >=20 > The crevice here was that there are many ways to express the number 3: = 3, 3.0, 3e0, 0.03e2, 300e-2 etc. We can give some of these expressions = different semantics than the other. Voila. Extensibility achieved. = Brittleness added. >=20 > I have seen the law of inevitable extensibility applied to: >=20 > =E2=80=94 duplicate map keys for adding comments to JSON. Some people = believe: >=20 > { =E2=80=9Cpostcode=E2=80=9D: =E2=80=9CThis is a comment about the = post code 4711=E2=80=9D, > =E2=80=9Cpostcode=E2=80=9D: 4711 } >=20 > is a valid way to extend JSON with comments. (Because their = implementation happens to ignore map keys that are invalidly used again = later, which is not a given.) Certainly, this is not interoperable. But it is legal: RFC8259 merely = says documents =E2=80=9CSHOULD NOT=E2=80=9D use multiple keys, and = allows different implementations to handle it differently. ECMA-404 = specifically says there=E2=80=99s no limits on string names, even = repeated names (ECMA 404 is the document referenced by ECMAScript, = though that specifies an algorithm that ignores repeated keys.) For this reason, JSON Schema does not have any features dealing with = repeated keys or their order (specifically, the data model specifies = that objects are treated as an unordered string to value mapping), this = is another artistic license that favors uniformity over supporting the = complete lexical space of JSON. >=20 > - unnecessary escaping for ascribing some special semantics. Say, if = a string starts with =E2=80=9C\u0073=E2=80=9D and not with the = equivalent =E2=80=9Cs=E2=80=9D, this is supposed to mean the string has = some different semantics (e.g., the rest is a base64url encoded byte = string as opposed to what would normally be a text string, or a type = tag, or=E2=80=A6). While JSON strongly implies these two forms must be considered the same = thing, note this isn=E2=80=99t true for all formats. Namely, %2F is not = the same as a forward slash in a URI, they are to be treated = differently. (There=E2=80=99s been many security holes caused because = people treat `%2F..%2F` the same as `/../` and it=E2=80=99s not.) >=20 > =E2=80=94 millions of ways of interpreting whitespace or the lack = thereof. I=E2=80=99ve lost count. Could you provide one or two examples please? >=20 >=20 > I do not think any longer that anything that is meant to see = significant usage can be designed without designing in extensibility = points from the start. At least if it is supposed to last. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Wed May 8 23:50:34 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 B5BD41200F5 for ; Wed, 8 May 2019 23:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 9s8asCH1_yNU for ; Wed, 8 May 2019 23:50:30 -0700 (PDT) Received: from smtp.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 2DFD5120049 for ; Wed, 8 May 2019 23:50:30 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 4503rM688dzyTX; Thu, 9 May 2019 08:50:27 +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: <02755092-1682-45E8-AB6C-0EDA7D35703A@bzfx.net> Date: Thu, 9 May 2019 08:50:27 +0200 Cc: JSON WG X-Mao-Original-Outgoing-Id: 579077424.814926-716de49591f48f9e1412b5ca17e8a639 Content-Transfer-Encoding: quoted-printable Message-Id: References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> <02755092-1682-45E8-AB6C-0EDA7D35703A@bzfx.net> To: Austin Wright X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 06:50:33 -0000 On May 9, 2019, at 00:49, Austin Wright wrote: >=20 >> Now people did not want to accept that. >> They wanted to extend the JSON data model with the distinction = between two number types. >=20 > Who=E2=80=99s =E2=80=9Cthey=E2=80=9D? Those people who want 3 and 3.0 to mean different things in a JSON = document. > Neither of these =E2=80=9Cextend" JSON, because JSON does not impose = any requirements on how implementations parse numbers. My reading of = RFC8259 allows implementations to differentiate between `3` vs `3.0` vs = `3.00`. The language that Section 6 of RFC 8259 has inherited is not very good. I cannot achieve a reading, though, that would support the above. >> =E2=80=94 duplicate map keys for adding comments to JSON. Some = people believe: >>=20 >> { =E2=80=9Cpostcode=E2=80=9D: =E2=80=9CThis is a comment about the = post code 4711=E2=80=9D, >> =E2=80=9Cpostcode=E2=80=9D: 4711 } >>=20 >> is a valid way to extend JSON with comments. (Because their = implementation happens to ignore map keys that are invalidly used again = later, which is not a given.) >=20 > Certainly, this is not interoperable. But it is legal: RFC8259 merely = says documents =E2=80=9CSHOULD NOT=E2=80=9D use multiple keys, Please re-read RFC 2119. SHOULD is a normative statement. It is not a = MUST mainly because streaming implementations would have a hard time = properly implementing that prohibition, so they are allowed to = occasionally malfunction. But a malfunction it is. > and allows different implementations to handle it differently. = ECMA-404 specifically says there=E2=80=99s no limits on string names, = even repeated names (ECMA 404 is the document referenced by ECMAScript, = though that specifies an algorithm that ignores repeated keys.) Well, yeah. There is a reason we needed to maintain an IETF = specification here. >> - unnecessary escaping for ascribing some special semantics. Say, if = a string starts with =E2=80=9C\u0073=E2=80=9D and not with the = equivalent =E2=80=9Cs=E2=80=9D, this is supposed to mean the string has = some different semantics (e.g., the rest is a base64url encoded byte = string as opposed to what would normally be a text string, or a type = tag, or=E2=80=A6). >=20 > While JSON strongly implies these two forms must be considered the = same thing, note this isn=E2=80=99t true for all formats. Namely, %2F is = not the same as a forward slash in a URI, they are to be treated = differently. (There=E2=80=99s been many security holes caused because = people treat `%2F..%2F` the same as `/../` and it=E2=80=99s not.) I was talking about JSON, not about URIs, where percent notation indeed = has different semantics (essentially creating a double of the encoded = character without its syntactic properties). The myths and misunderstandings cited in this message are actually a = good corollary to the discussion of the Postel principle and = soupification that is happening over at ietf@ietf.org=E2=80=A6 The JSON = WG historically has shied away from making some of its statements very = clear, and the resultant weasel wording will come back forever biting = us. I hope we can be better in the future. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 9 10:15:28 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 52AAE12011E for ; Thu, 9 May 2019 10:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 MpQRucYwvpjR for ; Thu, 9 May 2019 10:15:24 -0700 (PDT) Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) (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 056CA1200E5 for ; Thu, 9 May 2019 10:15:23 -0700 (PDT) Received: by mail-oi1-f173.google.com with SMTP id 143so2494989oii.4 for ; Thu, 09 May 2019 10:15:23 -0700 (PDT) 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=lhfjaP74mIkJHtMTWLOd1ySPaeJz64Z191ZTRInx9us=; b=uQ7ti9MiICEzJI4GBi7QtD613alu8h0Z8O2Y62c419IPjI8bPf1K30BL7t08BBFZ5A CJXWES0IzSgvgJCaeSkvEAGrPqqGnOWtlzmm//qYEKkSl6zcCZqMe5vgDfP1AAQoCOrE uOv7woVvAbgI7BxYBnHc+Clv2DLQ5Yk1VwvVffEZTA66D9Xu/7+8njfAscbx6Xb2WD8r S6jShHxA5SnljcP/hrdGBOLF1lJfzzAWssfTRqUtw1yXQWe46dWQalSstBIASlMZdRWL Il/JCkOntTsY0phEd+DjV61tnJXGumM+dBSe/wSRWMWEuIHdhpYbVjd+hP8mpu/DqyKO UkTA== X-Gm-Message-State: APjAAAUWCQAtezZ1euMpWvjyFSGYgzLDXWujlohvNo6gq0xSAumopF1E G8dZdRlurHtq27eoPaFspJaGZkYCE3s16y2OiKs= X-Google-Smtp-Source: APXvYqy1NrYyy/9mwGmotqleAptiWF34Txl+BwfQHcjArCDkgzXj1FSV50bL4G7d4Mir/s3eL/PCuCbFnM1HTYXG+9s= X-Received: by 2002:aca:c348:: with SMTP id t69mr2263861oif.95.1557422123109; Thu, 09 May 2019 10:15:23 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Thu, 9 May 2019 13:15:11 -0400 Message-ID: To: Carsten Bormann Cc: Nico Williams , JSON WG Content-Type: multipart/alternative; boundary="00000000000069d0c10588779872" Archived-At: Subject: Re: [Json] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 17:15:26 -0000 --00000000000069d0c10588779872 Content-Type: text/plain; charset="UTF-8" On Wed, May 8, 2019 at 1:00 PM Carsten Bormann wrote: > On May 8, 2019, at 18:07, Nico Williams wrote: > > > > That's an interop bug. They should fix it. > > It also nicely demonstrates the law of inevitable extensibility. > > JSON was designed not to provide extensibility. Ever. > Radical, but a well motivated idea at the time. > My understanding is that you can extend JSON if you like. Just call it something else. And that makes perfect sense for a data encoding. My extensions to JSON are called JSON-B, J-SON-C and JSON-D. Each extension adds functionality that is critical for certain applications (verbatim encoding of binary and text blobs, compression, data types). Since they are strict supersets, an implementation needs separate encoders for each one but a JSON-B decoder will serve JSON and JSON-B extensions. So an implementation only needs one decoder. If we were going to do a text encoding for scientific data, the changes I would propose would be * Hex encoding for floats so as to preserve precision of Real64 and Real32 data. * Allow compact encoding of table data without having to specify tags for every data item. * Allow for comments * Ensure that the new format can be loss-lessly converted to and from JSON. But it would not be JSON. It would be something else. And that is OK because if I am trying to read a data file, I need to know the encoding. I would really like to see a JSON-like format emerge as an alternative to CSV because, I have spent too much time trying to analyze files that contain data separated from the context. If I am doing science, I want files that look like this { "TemperatureData" : { "StartDate" : "2010-1-1", "EndDate" : "2011-2-2", "Location" : "Rome", "Units" : "Centigrade", "Channels" : [ "C1", "C2", "C3", "C4", "Readings" : [[ 20.2, 23.3, 44.3, 20.1 ... ] [34.3, 3.4 ...] ... ] Not this 20.2, 23.3, 44.3, 20.1 ... 34.3, 3.4... ... --00000000000069d0c10588779872 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Wed, May 8, 2019 at 1:00 PM Carsten Bormann <= cabo@tzi.org> wrote:
    On May 8, 2019, at 18:07, Nico = Williams <nic= o@cryptonector.com> wrote:
    >
    > That's an interop bug.=C2=A0 They should fix it.

    It also nicely demonstrates the law of inevitable extensibility.

    JSON was designed not to provide extensibility.=C2=A0 Ever.
    Radical, but a well motivated idea at the time.

    My understa= nding is that you can extend JSON if you like. Just call it something else.= And that makes perfect sense for a data encoding.=C2=A0

    My extensions to JSON are called JSON-B, J-= SON-C and JSON-D. Each extension adds functionality that is critical for ce= rtain applications (verbatim encoding of binary and text blobs, compression= , data types).
    =
    Since they= are strict supersets, an implementation needs separate encoders for each o= ne but a JSON-B decoder will serve JSON and JSON-B extensions. So an implem= entation only needs one decoder.

    If we were going to do a text encoding for scientific data, the cha= nges I would propose would be

    * Hex encoding for floats so as to preserve precision of Real64 and Re= al32 data.
    * Al= low compact encoding of table data without having to specify tags for every= data item.
    * A= llow for comments
    * Ensure that the new format can be loss-lessly converted to and from JS= ON.

    <= div class=3D"gmail_default" style=3D"font-size:small">But it would not be J= SON. It would be something else. And that is OK because if I am trying to r= ead a data file, I need to know the encoding.=C2=A0

    I would really like to see a JSON-like format em= erge as an alternative to CSV because, I have spent too much time trying to= analyze files that contain data separated from the context. If I am doing = science, I want files that look like this

    { "TemperatureData" : {
    =C2=A0 =C2=A0"StartDate" : &q= uot;2010-1-1",
    =C2=A0 =C2=A0"EndDate" : "2011-2-2",
    =C2=A0 =C2=A0"Location&= quot; : "Rome",
    =C2=A0 =C2=A0"Units" : "Centigrade",
    =C2=A0 =C2=A0"Cha= nnels" : [ "C1", "C2", "C3", "C4&qu= ot;,=C2=A0
    =C2= =A0 =C2=A0"Readings" : [[ 20.2, 23.3, 44.3, 20.1 ... ] [34.3, 3.4= ...] ... ]
    Not this20.2, 23.3, 44.3, 20.1 ...
    34.3, 3.4...
    ...


    =C2=A0
    --00000000000069d0c10588779872-- From nobody Thu May 9 10:37:07 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 30FFC12003E for ; Thu, 9 May 2019 10:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 h1ADhj6wHtbz for ; Thu, 9 May 2019 10:37:03 -0700 (PDT) Received: from smtp.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 1903F1200C1 for ; Thu, 9 May 2019 10:37:03 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 450LBM5cGszyVN; Thu, 9 May 2019 19:36:59 +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, 9 May 2019 19:36:58 +0200 Cc: Nico Williams , JSON WG X-Mao-Original-Outgoing-Id: 579116216.983811-e119c885b56fca45e1322bb1d10a9276 Content-Transfer-Encoding: quoted-printable Message-Id: References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 17:37:05 -0000 > I would really like to see a JSON-like format emerge as an alternative = to CSV because, I have spent too much time trying to analyze files that = contain data separated from the context. SenML, RFC 8428, was made for this. Can be serialized in XML, EXI, = JSON, CBOR. > If I am doing science, I want files that look like this >=20 > { "TemperatureData" : { > "StartDate" : "2010-1-1", > "EndDate" : "2011-2-2", > "Location" : "Rome", > "Units" : "Centigrade", > "Channels" : [ "C1", "C2", "C3", "C4",=20 > "Readings" : [[ 20.2, 23.3, 44.3, 20.1 ... ] [34.3, 3.4 ...] ... ] >=20 > Not this > 20.2, 23.3, 44.3, 20.1 ... > 34.3, 3.4... > =E2=80=A6 SenML looks a bit different, but has the same kind of information = content. If you really want the arrays that are in your example, it would be an = interesting exercise to extend SenML for that =E2=80=94 up to now, the = large organizations that use it have been happy with what we have. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 9 13:04:40 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 D26D61200FC for ; Thu, 9 May 2019 13:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 B-BFWmvnMlol for ; Thu, 9 May 2019 13:04:37 -0700 (PDT) Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) (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 BD15D12006B for ; Thu, 9 May 2019 13:04:37 -0700 (PDT) Received: by mail-oi1-f172.google.com with SMTP id l203so2900048oia.3 for ; Thu, 09 May 2019 13:04:37 -0700 (PDT) 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=M8uunREZ3gp85BP2WZ0gzocBwVgbcpYIMz9q5mdOl9A=; b=bLM+NMnt1WHyuYbsLuT+eVe4JEOdZ1vLwUsdQAUWEh5njP4VBtgZniUuATcEPHoE7v mfHztpnccQaHJDJYFhgtFbMcF8h//vqR+b/5JdP8x/frvBe6fUkuh+tR3ocYJm6K42/R nLsGuFDyRenvjjrSU1AK9r0zY9QCNJ2Ax0b7c1cjN/WrPhn5o5yZT3d5IvWrFhiVY6Vj D7GkQwUwon2E/jf+PbpHFxTRni5JBL/SS5zClAGRH/zNvhLl5XIweCrvpVMgNnk/RiFX snqISb65b/7Ad8qO9e9HIay56aN5pTseBwx9/drGHacWlvlfEwHszUiCiDAMSbIXIa52 4Tzg== X-Gm-Message-State: APjAAAU3g0J/cmA7w46AQRudRwiX9UTcpqh0Koy0TTE1jTe4nBMgCGlN SfJ6QXPHRNC0EWz+7qMCMv7d3sthuDpuwCx2xjk= X-Google-Smtp-Source: APXvYqzESkZ7wlpvwMMCtqvIaY3W6SSW2Lytno4F2qouwWj8CboZYs0zihJ3fxLrWVSviBzPwjUBQJBKyWl6zDG8NOY= X-Received: by 2002:aca:43d5:: with SMTP id q204mr2803709oia.100.1557432276785; Thu, 09 May 2019 13:04:36 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Thu, 9 May 2019 16:04:26 -0400 Message-ID: To: Carsten Bormann Cc: Nico Williams , JSON WG Content-Type: multipart/alternative; boundary="0000000000009eacfe058879f515" Archived-At: Subject: Re: [Json] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 20:04:39 -0000 --0000000000009eacfe058879f515 Content-Type: text/plain; charset="UTF-8" On Thu, May 9, 2019 at 1:37 PM Carsten Bormann wrote: > > > I would really like to see a JSON-like format emerge as an alternative > to CSV because, I have spent too much time trying to analyze files that > contain data separated from the context. > > SenML, RFC 8428, was made for this. Can be serialized in XML, EXI, JSON, > CBOR. > I was using temperatures as an example to illustrate the fact that the general case for science data is that I have a bunch of information describing the data set and a series of tables. If I am using SciKit-Learn to analyze data, I am typically importing a bunch of data files containing different tables and doing joins and merges on them. A lot of the context for the process is lost because a CSV file can only contain the table. So this morning I was looking at a ZIP file that had the following file layout: descrip.txt # this file dataset.json # the metadata twitter.csv # Twitter persona data facebook.csv # Facebook persona data tweetlog.csv # Posts to twitter fblog.csv # Posts to Facebook Oh and they each have different layouts and syntax. I have to pull them into Pandas, construct data frames, drop out features to SciKit and then identify the fake news sources. I think it would be actually quite easy to just dump out one file that has everything in JSON and for this to be engineered so that the relevant Pandas frames are constructed automagically.. But that is not where the field is right now. --0000000000009eacfe058879f515 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Thu, May 9, 2019 at 1:37 PM Carsten Bormann <cabo@tzi.org> wrote:

    > I would really like to see a JSON-like format emerge as an alternative= to CSV because, I have spent too much time trying to analyze files that co= ntain data separated from the context.

    SenML, RFC 8428, was made for this.=C2=A0 Can be serialized in XML, EXI, JS= ON, CBOR.

    I was using temperatures as an example to illustr= ate the fact that the general case for science data is that I have a bunch = of information describing the data set and a series of tables.

    If I am using SciKit-Learn to analyze= data, I am typically importing a bunch of data files containing different = tables and doing joins and merges on them. A lot of the context for the pro= cess is lost because a CSV file can only contain the table. So this morning= I was looking at a ZIP file that had the following file layout:

    descrip.txt=C2=A0 # this file
    =
    dataset.json # the m= etadata
    twitter= .csv # Twitter persona data
    facebook.csv # Facebook=C2=A0persona=C2=A0data
    tweetlog.csv # Posts to twitte= r
    fblog.csv # P= osts to Facebook

    Oh and they each have different layouts and syntax. I have= to pull them into Pandas, construct data frames, drop out features to SciK= it and then identify the fake news sources.

    I think it would be actually quite easy to just dump o= ut one file that has everything in JSON and for this to be engineered so th= at the relevant Pandas frames are constructed automagically.. But that is n= ot where the field is right now.


    --0000000000009eacfe058879f515-- From nobody Thu May 9 16:16: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 51EB11200EB for ; Thu, 9 May 2019 16:16:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-org.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 qa3pljgaonE1 for ; Thu, 9 May 2019 16:16:45 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 4F7DF1200DF for ; Thu, 9 May 2019 16:16:45 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id d12so5227347wrm.8 for ; Thu, 09 May 2019 16:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+HtQqS+Gb5DEePil7eDy+a0QH4ph2EVFv+yVVSepBTY=; b=gSqvnWavJ0TYn35ofDze7WvmeptO6pVaLB9iUT657WhFQ4OwRxtHU2eN1BovFL/c9u qD8bjLquoLEpz/3iTHMJPsXYNTZanQbBiQwcHUKn2eYXjlvmD+Vk5PgRH7AIOLB0ESV2 saDo1uCGWJqHoTpoBEMBPT4dbh4P23mcyYKj0glEZ0LAtvGrT0QDEfgX12gDk6Hos2Hc DXCr7Q/Kbo/Fq47/JB8ub7gWU15vKHqvLxE+cHH7RvrXElcF7Rtr58NWl5eiNjZyp0xi mcQyqF0E4qyaOZOznepREaXmUEFdLpPp0vunnRjM2D+AU8VB3oYFqjnB1YHWr8SU8IFV yDBg== 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=+HtQqS+Gb5DEePil7eDy+a0QH4ph2EVFv+yVVSepBTY=; b=tjGNh8twc+HWnrK0X01x8naW2zHR01phzw2fyK5zzHAFDmDx53hrWTuVpchz0j3CgJ 2DeSpamc1GN/V/Qq1+0/6w9+Bg25GMgbLHFJXEzjpquWmpWx29Bk1lUR9Bnqc+9dvV/s MhgoPy5Jo4BHHVIq0u6C00LTJiM4LRcJvrjnYHB/oiVrgVEWLgQR7Ajvt8vYogKIbe6c DYBrzUlqq69/WAZ96kqGTFnK99Z2wJhB3i49e8sjFYPhzgnMXOOjII1eHEZZUz85NiKt 0Xal0sEsaV1BoMw9AYIEKDTpLlEnYBnWaxUgOKcaCfL6QzXr/FUbFKY3AFJx2qQL0o7V o3EA== X-Gm-Message-State: APjAAAXzqJyM9QfntXOI2eIZMqqc8IZOwwnvcIbWUDILVA3JaBMlLpLi 1VeAc084WyD24ZJmP3K8siDyd2xq8/Dbgc+dcVhn1GDfOPs= X-Google-Smtp-Source: APXvYqyeWCvM4JxFXJgYwF8j4iSRv2AUOa08TWVBvADy7kA7bMpn9nZuzXP7I1osjAsdsmKBVT6fZn3kUbrvglV8Ntc= X-Received: by 2002:a05:6000:43:: with SMTP id k3mr5165242wrx.234.1557443803743; Thu, 09 May 2019 16:16:43 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> In-Reply-To: From: John Cowan Date: Thu, 9 May 2019 19:16:32 -0400 Message-ID: To: Phillip Hallam-Baker Cc: Carsten Bormann , Nico Williams , JSON WG Content-Type: multipart/alternative; boundary="000000000000ae1e7d05887ca449" Archived-At: Subject: Re: [Json] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 23:16:48 -0000 --000000000000ae1e7d05887ca449 Content-Type: text/plain; charset="UTF-8" On Thu, May 9, 2019 at 1:15 PM Phillip Hallam-Baker wrote: > * Allow compact encoding of table data without having to specify tags for > every data item. > If data is stored columnwise instead of row-wise, that's not a problem with as-is JSON. You could represent a table of observations like this: {"elapsedTime": [0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50], "waterTemperature": [25, 25, 33, 47, 60, 72, 88, 91, 100, 100, 100]} --000000000000ae1e7d05887ca449 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Thu, May 9, 2019 at 1:15 PM Phillip Hallam-Baker <ietf@hallambaker.com> wrote:
    =C2=A0
    * Allo= w compact encoding of table data without having to specify tags for every d= ata item.

    If data is = stored columnwise instead of row-wise, that's not a problem with as-is = JSON.=C2=A0 You could represent a table of observations like this:

    {"elapsedTime":=C2=A0 [0, 5, 10, 15, 20, 25, 30,= 35, 40, 45, 50],=C2=A0
    =C2=A0"waterTemperature": [25, = 25, 33, 47, 60, 72, 88, 91, 100, 100, 100]}
    =C2=A0
    --000000000000ae1e7d05887ca449-- From nobody Thu May 9 20:55:37 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 40E0012006F for ; Thu, 9 May 2019 20:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5tPsWi8JaUe for ; Thu, 9 May 2019 20:55:33 -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 226BF12004D for ; Thu, 9 May 2019 20:55:33 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id z4so3450437iol.0 for ; Thu, 09 May 2019 20:55:33 -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:content-transfer-encoding; bh=YWeoNUBJzBP4YyPXgFic3eZrZJBMwNo2iIy9n9OoVbw=; b=MAbPABc3d4eJyOS2YrmquIE6Zlwk8VbkjmQNVLQhhQcv2jASt+7cTBZAm9+/ROJ7zC qwHHT5EIpQk0C6uxJ5whIOIiozT0X405Y/HcEOahPM233r99LtXei3l7RptXUpl3XqIP mPqkDXSF/KM6MHMDnQTZCo36SHQq/7Rcbpfhg= 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=YWeoNUBJzBP4YyPXgFic3eZrZJBMwNo2iIy9n9OoVbw=; b=gqWs1/DzMnJvkqCRmK2ZUkglLCkMidPXUq3/K+Dp6nl8pzXgxUf1aAUgEFugDeBXVH 4XmwiJaOZ4/NFWLWZHhppS5pbB2pkHBhBOlQ01w/Gy1bcfDTqiY60Pdo2WUHYNhLzZGe irl9JlC2X20eAa1G3W6cbahBYRluKsYYVJ1g3Vva1sztrNylU5CplliVBOQhP/7zkNM6 +RTieWsA7PVSCsl1eMoYHaT2IcLg6qj1iG/PScn1Q7TqiSA6ALd5T9LRcIrEPso6CYB7 +g3U80Vze4DMThsmwA77Jg8lrh81/hLlXfLex6dk6lWHmezeXc0UJNJInOozhJmzxV85 1Lww== X-Gm-Message-State: APjAAAUFf4vdKsAbkRPk3RXJr8K7T/j8QImdQfWG0BaWn9BeeWg0wnnt FgJfJeWcR7OC8Nz4VFVe9+lpDNQrj5DF4qpE+y8wkMkia8c= X-Google-Smtp-Source: APXvYqzzyxvYBFJegXXMbSQOshXQ/RASd841EJePLvxQ8bfYF6WiFXSiVHqUo3nu6F0mldLL3/jp14J/KE+0C2C1z5Y= X-Received: by 2002:a5d:9b90:: with SMTP id r16mr5275232iom.217.1557460532323; Thu, 09 May 2019 20:55:32 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> In-Reply-To: <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> From: Ulysse Carion Date: Thu, 9 May 2019 20:55:21 -0700 Message-ID: To: Carsten Bormann Cc: JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 03:55:35 -0000 Carsten, Do you think that our difference in opinion on CDDL vs JSON Schema Language may be attributable to a difference in requirements? It seems to me that your use-case is centered around defining standards and other complex data requirements. CDDL is, in my view, unquestionably a better choice for this use-case. In my mind, CDDL is ABNF for CBOR, and that is undeniably what standards dealing with CBOR or its near-equivalents require. The existing references, from RFCs, to CDDL are testament to this. But I (and I suspect Tim) am more preoccupied solely with defining the mundane sorts of messages that come out of JSON event processing and repetitive JSON APIs. Tim has blogged (see link in my original email) about dealing with AWS's CloudWatch events. That's messages that look like this: https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html Tons of messages, and frequently being added and updated. But none of these messages are particularly exciting from a schema perspective. CDDL can do much more than is necessary for merely representing CloudWatch events. This may seem like a good thing, but such excess capability reduces the suitability of the solution. JSON Schema Language is intentionally small and scuttled in scope, so as to simplify code and UI generation. By being so limited in scope, JSON Schema Language fits more easily into the architecture of a system that would like to integrate it. Do you think this may be an explanation for our disagreement? If not, I may need to re-read the discussion, because I must have misunderstood you. On Wed, May 8, 2019 at 8:46 AM Carsten Bormann wrote: > > On May 8, 2019, at 15:48, Pete Cordell wrote: > > > > Writing XML Schema becomes more bearable if you have XML Schema aware e= ditors. Being XML aware alone isn't sufficient. > > Writing is not the main activity. Reading is. That is nearly unbearable= without tools. > > If I have to work on a W3C Schema(*), I convert it to Relax-NG compact fi= rst. True, I=E2=80=99ll lose some information, but as a net result I'll di= gest much more information out of the W3C Schema document than if I had dir= ectly looked at that. > > At the time when I was closer to the XML community, the hallway consensus= was that W3C Schema was *designed* to sell more tools. > > (Hence my short note yesterday giving the CDDL translations for JSL; that= would probably be the way I would be reading =E2=80=94 or writing =E2=80= =94 JSL.) > > Gr=C3=BC=C3=9Fe, Carsten > > (*) The data description spec that W3C called XML Schema > From nobody Thu May 9 23:40:27 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 3873412017D for ; Thu, 9 May 2019 23:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net 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 gxP1FOGd4pSf for ; Thu, 9 May 2019 23:40:24 -0700 (PDT) Received: from mail-it1-x142.google.com (mail-it1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (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 06251120169 for ; Thu, 9 May 2019 23:40:23 -0700 (PDT) Received: by mail-it1-x142.google.com with SMTP id l7so7447975ite.2 for ; Thu, 09 May 2019 23:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k7TKeRLEdmAhqtgxbEPxVir4IJVyIWKEPBovyYBVdfA=; b=jgwHoq0HifN4VuiVlE5NRrjSmqarMCwJAH3lyMHoTMtbO7RzznG/wOP7RfKivFBVjj 3a2wYhG0OrC6bZMEkbwFWhFjUBKVcCIgjKVXCqB1uu4q6IMC+6wsBv+AAsmJjrUWfk/6 dHbZeDwvH7T8SBlaWPQXE64RkgzP+IgWadBjg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k7TKeRLEdmAhqtgxbEPxVir4IJVyIWKEPBovyYBVdfA=; b=sTv9FgnnioAXwzu9KQM4wlBri6otZgqIf5Q1aEVR/fusH35bI+V9dky3NdQwlp8sOv yLpCE3lFInlPAzRwaV6ixj+bBxu9lZjdHXA1ZORs0SMm4AgU5R5vagxqL7YbI2bczE2b CoJvExDnCAV59TcTjOWd7T1+nwwt32CGI+w6wuTFoa4UkJBefBvz/Qu8fzgUyGqbaYo6 EG6/0y2UjxbXkDtJKMTsTuZGyS8Jc4j9fsSPUul1cFaZIZTGBIjRDeo8MCEreRIwnYuU 6v+nGfx/9Kk/vAsfmIISmFcD5lCGf/MIGp2AeFZp5fOmtRRvuFDh7Z4jOhuh29RUci/7 bwfg== X-Gm-Message-State: APjAAAV94bXdatJDqOtiKPSXcFPzicLS8RCoXcgFAZUNdp8lG/oYhUzA rPplP3q1Pi/C6bT3Vq6512Rhevjhi3w= X-Google-Smtp-Source: APXvYqzd3KwiFQF/nbmYnJ0w64sqPeQp+TTTj/riqc2FcXsI0gCLYo2WVzumWc2DhSQryCF+fcMkyQ== X-Received: by 2002:a24:248f:: with SMTP id f137mr5977516ita.112.1557470422992; Thu, 09 May 2019 23:40:22 -0700 (PDT) Received: from [172.20.1.233] ([4.71.40.243]) by smtp.gmail.com with ESMTPSA id y62sm2115199ita.15.2019.05.09.23.40.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 May 2019 23:40:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Austin Wright In-Reply-To: Date: Fri, 10 May 2019 00:40:21 -0600 Cc: JSON WG Content-Transfer-Encoding: quoted-printable Message-Id: <92D865C6-9990-46B1-961E-2DDD7D06617C@bzfx.net> References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> <02755092-1682-45E8-AB6C-0EDA7D35703A@bzfx.net> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Json] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 06:40:26 -0000 > On May 8, 2019, at 23:50, Carsten Bormann wrote: >=20 > On May 9, 2019, at 00:49, Austin Wright wrote: >>=20 >>> Now people did not want to accept that. >>> They wanted to extend the JSON data model with the distinction = between two number types. >>=20 >> Who=E2=80=99s =E2=80=9Cthey=E2=80=9D? >=20 > Those people who want 3 and 3.0 to mean different things in a JSON = document. >=20 >> Neither of these =E2=80=9Cextend" JSON, because JSON does not impose = any requirements on how implementations parse numbers. My reading of = RFC8259 allows implementations to differentiate between `3` vs `3.0` vs = `3.00`. >=20 > The language that Section 6 of RFC 8259 has inherited is not very = good. > I cannot achieve a reading, though, that would support the above. Well, JSON says that any number that fits the syntax is legal, and it = doesn=E2=80=99t proscribe a way to normalize the numbers. And some = software does keep track of significant figures. Why should those = applications interpret JSON any differently? >=20 >>> =E2=80=94 duplicate map keys for adding comments to JSON. Some = people believe: >>>=20 >>> { =E2=80=9Cpostcode=E2=80=9D: =E2=80=9CThis is a comment about the = post code 4711=E2=80=9D, >>> =E2=80=9Cpostcode=E2=80=9D: 4711 } >>>=20 >>> is a valid way to extend JSON with comments. (Because their = implementation happens to ignore map keys that are invalidly used again = later, which is not a given.) >>=20 >> Certainly, this is not interoperable. But it is legal: RFC8259 merely = says documents =E2=80=9CSHOULD NOT=E2=80=9D use multiple keys, >=20 > Please re-read RFC 2119. SHOULD is a normative statement. It is not = a MUST mainly because streaming implementations would have a hard time = properly implementing that prohibition, so they are allowed to = occasionally malfunction. But a malfunction it is. =E2=80=9CSHOULD" allows implementations to vary from the suggested = behavior if there=E2=80=99s a reason. RFC8259 specifically says the = reason is interoperability, and also says implementations might report = all of the key-value pairs, even repeated keys. So if two = implementations agree that repeated keys are meaningful, that seems = legal to me. I don=E2=80=99t see how the fact JSON can be streamed changes this. HTTP = says servers must produce errors on some headers if they=E2=80=99re = repeated; and HTTP is also parsed by streaming parsers. Now, if the vast majority of JSON implementations don=E2=80=99t = recognize excess precision, and don=E2=80=99t allow (or ignore) repeated = keys, then maybe JSON should be updated to reflect that. Look at HTTP as = an example, which is far more specific about how to handle these cases = (e.g. repeated Host header, repeated Content-Length, media type = q-values). Cheers, Austin. From nobody Fri May 10 00:16:32 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 C1BB4120198 for ; Fri, 10 May 2019 00:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 vYrnIrq-8RYT for ; Fri, 10 May 2019 00:16:25 -0700 (PDT) Received: from smtp.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 8412B12018F for ; Fri, 10 May 2019 00:16:25 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 450hMp6NG9zyVZ; Fri, 10 May 2019 09:16:22 +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: Fri, 10 May 2019 09:16:22 +0200 Cc: JSON WG X-Mao-Original-Outgoing-Id: 579165380.119637-6090981b72f3cdd0973785dd94d38664 Content-Transfer-Encoding: quoted-printable Message-Id: <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> To: Ulysse Carion X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 07:16:30 -0000 On May 10, 2019, at 05:55, Ulysse Carion wrote: >=20 > Carsten, >=20 > Do you think that our difference in opinion on CDDL vs JSON Schema > Language may be attributable to a difference in requirements? Hi Ulysse, I=E2=80=99m not even sure we disagree. That was why I became interested = in converting between JSL and CDDL. As I was trying to show, CDDL might = make a fine presentation language for JSL, and JSL might be a nice = =E2=80=9Cprofile=E2=80=9D for CDDL that is very simple to process. > It seems to me that your use-case is centered around defining > standards and other complex data requirements. CDDL is, in my view, > unquestionably a better choice for this use-case. In my mind, CDDL is > ABNF for CBOR, and that is undeniably what standards dealing with CBOR > or its near-equivalents require. The existing references, from RFCs, > to CDDL are testament to this. Yes, you are describing the intention correctly. I would add that CDDL = has proven as useful for describing pure JSON protocols as for CBOR. =20 Not all JSON/CBOR protocols need the full capabilities of CDDL. For = instance, the example in the CDDL spec for RFC 7071 could easily be = expressed in JSL, except for two details: reputation-object is not meant = to be extensible (reputon is), and there are some value constraints = (some values are integers). > But I (and I suspect Tim) am more preoccupied solely with defining the > mundane sorts of messages that come out of JSON event processing and > repetitive JSON APIs. Tim has blogged (see link in my original email) > about dealing with AWS's CloudWatch events. That's messages that look > like this: >=20 > = https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html= >=20 > Tons of messages, and frequently being added and updated. But none of > these messages are particularly exciting from a schema perspective. Well, I just had a look at (randomly selected) = https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html= #health-event-types You=E2=80=99d need to add enumerations to JSL. There are also = timestamps in the object (ironically in two different formats). There = is a table that maps language tags to messages in that language. (And = the second and third example have a missing bracket.) But I can=E2=80=99t= really say, because the description by example only just begins to = expose the actual intention. > CDDL can do much more than is necessary for merely representing > CloudWatch events. This may seem like a good thing, but such excess > capability reduces the suitability of the solution. JSON Schema > Language is intentionally small and scuttled in scope, so as to > simplify code and UI generation. By being so limited in scope, JSON > Schema Language fits more easily into the architecture of a system > that would like to integrate it. I=E2=80=99ve seen my share of developments that start simple. How much = functionality will be added to JSL before it becomes a standard? Also, = the law of extensibility tells us it will be extended even after = becoming a standard. Of course, in its domain, CDDL is incredibly simple. Compare to JCR: = JCR is about three times as complex as CDDL. This is because CDDL was = built from a few very simple building blocks, which combine nicely to = provide its functionality. JCR is more of an accretion of features, = which in sum can do most of what CDDL can do. But back to JSL and CDDL: What I=E2=80=99m interested in is what are the sweet spots on this = functionality vs. complexity continuum. I think we have found two of = these sweet spots (at least maybe after a little more calibration). Now = how do we handle the onslaught of applications that don=E2=80=99t quite = fit the sweet spots? =20 The question that intrigues me: Is it possible to define something that = is as simple as JSL when you need just that, but allows dipping into the = capabilities of something like CDDL where needed? By the way: You may not be aware of the WISHI activity we have in the = T2TRG (thing-to-thing research group) of the IRTF. Here we look at = modeling (not just for data) and at translating between different = modeling approaches. http://wishi.space if you want to have a look. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri May 10 00:33:06 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 16516120177 for ; Fri, 10 May 2019 00:33:05 -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_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 S6Mg6O_OP44x for ; Fri, 10 May 2019 00:33:03 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 C8606120125 for ; Fri, 10 May 2019 00:33:03 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id s3so7867768itk.1 for ; Fri, 10 May 2019 00:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hP2nPNrR3zUAe/GwvVR5qM0Xbns3QjGejPS/VgIhp1A=; b=JgbKeIIMITjH+WVzb3ayGC6PHj+ymMWDHSJMoi1o02QXsayjc0mI2tTLFi+gZwCoPT 8255Z9KNW5A3gl2AIxJp/Inn27seX6dRWWM1TvKNbKpLeo3CyvonM1oVjn+5zecNurot 6OVLxvIsTmr7zh13aEiAaint+AUYPs5cnZQkiAM8331mkSBkXSaCXqa0XqynXV/3IYRr 9Ybn8OO1RwShiPDFTxhp2Zt7k7W4CXUKEmV6uvZOlVvl0XXzL0TQQbSUNxLaCTzZaL7p Q0ImN+1g1SPyvTDtwe7r4lQZGcNCPkjizJ5YaJSpFmZlEKG2cfErJqgzc7X6bVVq7lPi RDbg== 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=hP2nPNrR3zUAe/GwvVR5qM0Xbns3QjGejPS/VgIhp1A=; b=MOCKmEyb9DlVx0GmyMdGw9vjtLZd6FWZStXAJbo6N5SwUCYV+AvGu264Gi6a3Zt1yo 749bGoS3CmFKXrGSWyVJOB9XfAJy8AE5Wu8gLYTFMzf+xdXm6YfwzOK5X1MaUgu6/5oV TWkgGHD+EUAjjVsAWi+kRz3La3qM8IEsmaO7lg2Rlcrn4VFtwqFhds3e0Kie0VLF64AB z90/IoK9iYF3ZA0Ecgt8QWCzDdlLNxLCDLQzs9X2Fdq8bWSD1+YfyZlAQSShEMOQ/IqF 73ZSBfxVX/WjqsohEC+0lJNPq25m/iqw/RznDq5AiYYnOGvArI1xE1Ip6rPyw8ffB+90 AlEg== X-Gm-Message-State: APjAAAWT3CnI7Vlu8nbwSY4Ec+M6rpB27kODRHZCSpx9pXFrMepG8UQt lry3Rsz+6hkKjNJduqBFzaic5TSpXYbWm0+6d/k= X-Google-Smtp-Source: APXvYqwMJ8a/X3l/Kz4S9BckgSsH6Pf87QaKA39d1phOj3OgPcSmfrwd3e+bxbcZnXfhMyXbcLy8FBqyXa2Qcm/KK5s= X-Received: by 2002:a24:c347:: with SMTP id s68mr6105417itg.140.1557473583053; Fri, 10 May 2019 00:33:03 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> In-Reply-To: From: Rob Sayre Date: Fri, 10 May 2019 00:32:51 -0700 Message-ID: To: Ulysse Carion Cc: Nico Williams , Phillip Hallam-Baker , Austin Wright , JSON WG , Tim Bray , Erik Wilde , Anders Rundgren Content-Type: multipart/alternative; boundary="000000000000aa4261058883930a" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 07:33:05 -0000 --000000000000aa4261058883930a Content-Type: text/plain; charset="UTF-8" On Tue, May 7, 2019 at 4:57 PM Ulysse Carion wrote: > Hi all, > > I'd like to offer a summary of what has been stated thus far, so as to > make a bit more sense of the conversation. I think there's no need to do this work. I know, because I replaced a large JSON-based analytics provider with a protobuf-based system that was cheaper with better correctness, and was an implementation detail of a product doing other things. - Rob --000000000000aa4261058883930a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Tue, May 7, 2019 at 4= :57 PM Ulysse Carion <ulysse@segme= nt.com> wrote:
    Hi all,

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

    = I think there's no need to do this work. I know, because I replaced a l= arge JSON-based analytics provider with a protobuf-based system that was ch= eaper with better correctness, and was an implementation detail of a produc= t doing other things.

    - Rob
    --000000000000aa4261058883930a-- From nobody Fri May 10 00:57:05 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 65022120194 for ; Fri, 10 May 2019 00:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 u0_Gqj2Eh9rE for ; Fri, 10 May 2019 00:57:01 -0700 (PDT) Received: from ipxdno.tcif.telstra.com.au (ipxdno.tcif.telstra.com.au [203.35.82.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 EB1D0120178 for ; Fri, 10 May 2019 00:56:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,452,1549890000"; d="scan'208";a="131554484" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipodni.tcif.telstra.com.au with ESMTP; 10 May 2019 17:56:56 +1000 Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcani.tcif.telstra.com.au with ESMTP; 10 May 2019 17:56:56 +1000 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsmsg3754.srv.dir.telstra.com (172.49.40.198) with Microsoft SMTP Server (TLS) id 8.3.485.1; Fri, 10 May 2019 17:56:56 +1000 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 10 May 2019 17:56:48 +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; Fri, 10 May 2019 17:56:48 +1000 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=yShu74r1T/+4Uvpnp+Wxmyat4QnrmxBsvc5Ij+skUeQ=; b=FdazfSJmg9UyNR73S2m3dEOpwh8K9LQrh/zHZU1XRGAMTH8cmuYeKS38lnGnddxurWPhN1VAz26+8VjEVJ8ZH45hgy5JGJuGAv7ab+24LqC2rJ0747N6jqO6Muaodfc1hD31NgaHIssZV6l8IPMU9jjfget4JLX9yuQnX1ls89s= Received: from MEXPR01MB0934.ausprd01.prod.outlook.com (10.169.161.142) by MEXPR01MB1447.ausprd01.prod.outlook.com (10.175.213.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Fri, 10 May 2019 07:56:47 +0000 Received: from MEXPR01MB0934.ausprd01.prod.outlook.com ([fe80::949c:37b:f402:9d3e]) by MEXPR01MB0934.ausprd01.prod.outlook.com ([fe80::949c:37b:f402:9d3e%4]) with mapi id 15.20.1878.022; Fri, 10 May 2019 07:56:47 +0000 From: "Manger, James" To: Austin Wright , Carsten Bormann CC: JSON WG Thread-Topic: [Json] Adding integers to JSON (Re: JSON Schema Language) Thread-Index: AQHVBb+KgK8JWxXYs02YvYkrY6zczqZh1QwAgACGbICAAY+DgIAABriQ Date: Fri, 10 May 2019 07:56:47 +0000 Message-ID: References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> <02755092-1682-45E8-AB6C-0EDA7D35703A@bzfx.net> <92D865C6-9990-46B1-961E-2DDD7D06617C@bzfx.net> In-Reply-To: <92D865C6-9990-46B1-961E-2DDD7D06617C@bzfx.net> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.500.19 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: c41c3457-16df-4ff1-e5d4-08d6d51d0d63 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MEXPR01MB1447; x-ms-traffictypediagnostic: MEXPR01MB1447: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0033AAD26D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(376002)(346002)(39860400002)(189003)(199004)(81166006)(81156014)(74316002)(8676002)(6436002)(14444005)(256004)(8936002)(102836004)(7736002)(86362001)(305945005)(66066001)(486006)(5660300002)(72206003)(229853002)(71190400001)(71200400001)(478600001)(76176011)(476003)(52536014)(110136005)(7696005)(186003)(99286004)(26005)(6506007)(316002)(446003)(25786009)(2906002)(4326008)(11346002)(6246003)(3846002)(6116002)(55016002)(73956011)(9686003)(76116006)(66946007)(66476007)(66556008)(64756008)(66446008)(68736007)(33656002)(53936002)(66574012)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:MEXPR01MB1447; H:MEXPR01MB0934.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: +MalQBpwRG9zrQGHAzCe4PWBTkbjOTwh6P+cWrIRpcukU81ZjSJMxmFqEaJlq8DTBD1MiNcLEbqyax5gbYA8jX1RDswgQ0e+vDdPj6nbUfehIsI3vcwTcUYmetkjHgtCdLn8A2vdAsjQSzLsffE4PgfcpW8hKac2j2X/4MFnx9a04D8PBTJjoVbPqBitnNx8s7BQmEOyN0KfuCOiOosPpL7Bdhf9tG0jGznTDdYDD8ngMTm3HWTU8UBJVb0+MJfG6PvrtoOmR3LMo3XxU+Hsn9RRdWpfsXOO85wKTbGKGP8L1bU94i0vT6wznAqf3dCnB5ne0QbnlNIwG9FLVNigu6MtWJoGpaRfqb9fzxPNVjMNwnrcny9Dcj29PRxCsdCveKgw20BkPOMTnmhrQg+v4+mQ3KyrY2XlD2YVdMB/c7E= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c41c3457-16df-4ff1-e5d4-08d6d51d0d63 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2019 07:56:47.3991 (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-Transport-CrossTenantHeadersStamped: MEXPR01MB1447 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [Json] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 07:57:04 -0000 PiDigJxTSE9VTEQiIGFsbG93cyBpbXBsZW1lbnRhdGlvbnMgdG8gdmFyeSBmcm9tIHRoZSBzdWdn ZXN0ZWQgYmVoYXZpb3IgaWYgdGhlcmXigJlzIGEgcmVhc29uLiBSRkM4MjU5IHNwZWNpZmljYWxs eSBzYXlzIHRoZSByZWFzb24gaXMgaW50ZXJvcGVyYWJpbGl0eSwgYW5kIGFsc28gc2F5cyBpbXBs ZW1lbnRhdGlvbnMgbWlnaHQgcmVwb3J0IGFsbCBvZiB0aGUga2V5LXZhbHVlIHBhaXJzLCBldmVu IHJlcGVhdGVkIGtleXMuIFNvIGlmIHR3byBpbXBsZW1lbnRhdGlvbnMgYWdyZWUgdGhhdCByZXBl YXRlZCBrZXlzIGFyZSBtZWFuaW5nZnVsLCB0aGF0IHNlZW1zIGxlZ2FsIHRvIG1lLg0KDQpOTyBX QVkhDQpSRkM4MjU5IEpTT04gZXhwbGljaXRseSBzYXlzIHdoZW4ga2V5cyBpbiBhbiBvYmplY3Qg YXJlIG5vdCB1bmlxdWUgdGhlIGJlaGF2aW91ciBvZiBwYXJzZXJzIGlzIHVucHJlZGljdGFibGUu IFNvIGl0IHlvdSBzcGVjaWZ5IGEgc3lzdGVtIHRoYXQgZ2l2ZXMgbWVhbmluZyB0byByZXBlYXRl ZCBrZXlzIHRoZW4gbG90cyBvZiBKU09OIHBhcnNlcnMgd2lsbCBiZSB1bnVzYWJsZSBpbiB0aGlz IGNhc2UuIEhlbmNlLCBpdCBpcyBoYXJtZnVsIHRvIGNhbGwgdGhhdCBKU09OLCBjYWxsIGl0ICJF Q01BIDQwNCBzeW50YXggd2l0aG91dCBub3JtYWwgSlNPTiBzZW1hbnRpY3MiLg0KDQo+IEkgZG9u 4oCZdCBzZWUgaG93IHRoZSBmYWN0IEpTT04gY2FuIGJlIHN0cmVhbWVkIGNoYW5nZXMgdGhpcy4g SFRUUCBzYXlzIHNlcnZlcnMgbXVzdCBwcm9kdWNlIGVycm9ycyBvbiBzb21lIGhlYWRlcnMgaWYg dGhleeKAmXJlIHJlcGVhdGVkOyBhbmQgSFRUUCBpcyBhbHNvIHBhcnNlZCBieSBzdHJlYW1pbmcg cGFyc2Vycy4NCg0KVGhlIG51bWJlciBvZiBlbGVtZW50cyBpbiBhIEpTT04gb2JqZWN0IGFuZCB0 aGUgbnVtYmVyIG9mIGhlYWRlcnMgaW4gYW4gSFRUUCBtZXNzYWdlIGFyZSBib3RoIHRoZW9yZXRp Y2FsbHkgdW5ib3VuZGVkLiBCdXQgdGhlcmUgaXMgYSBzdHJvbmcgYXNzdW1wdGlvbiB0aGF0IHRo ZSBsYXR0ZXIgKCNoZWFkZXJzKSBpcyBsaW1pdGVkOiB0eXBpY2FsbHkgMTBzLCBwZXJoYXBzIDEw MCwgbmV2ZXIgMTAwMHMuIFdlYiBzZXJ2ZXJzIGxpbWl0IHRvdGFsIGhlYWRlciBzaXplIHRvLCBz YXksIDhLQi4gVGhhdCBpcyBzbWFsbCBlbm91Z2ggdG8gYWx3YXlzIGhhbmRsZSByZXBlYXRzLiBX aGlsZSBtYW55IEpTT04gb2JqZWN0cyB3aWxsIGFsc28gYmUgc21hbGwsIEpTT04gaXMgc3VjaCBh IGdlbmVyaWMgZm9ybWF0IHRoYXQgeW91IGNhbm5vdCBtYWtlIGEgZ2xvYmFsIGFzc3VtcHRpb24g dGhhdCBKU09OIG9iamVjdHMgd2lsbCBhbHdheXMgYmUgc21hbGwgZW5vdWdoIHRvIGhvbGQgaW4g bWVtb3J5LiBIZW5jZSBzb21lIGFwcHMgd2lsbCBuZWVkIHN0cmVhbWluZyBKU09OIHByb2Nlc3Nv cnMgdGhhdCBjYW5ub3QgcmVhc29uYWJseSBkZXRlY3QgZHVwbGljYXRlIGtleXMgKHNvIHRoZSAi U0hPVUxEIiBpcyB0aGVyZSB0byBhY2NvbW1vZGF0ZSB0aGVzZSkuDQoNCg0KPiBOb3csIGlmIHRo ZSB2YXN0IG1ham9yaXR5IG9mIEpTT04gaW1wbGVtZW50YXRpb25zIGRvbuKAmXQgcmVjb2duaXpl IGV4Y2VzcyBwcmVjaXNpb24sIGFuZCBkb27igJl0IGFsbG93IChvciBpZ25vcmUpIHJlcGVhdGVk IGtleXMsIHRoZW4gbWF5YmUgSlNPTiBzaG91bGQgYmUgdXBkYXRlZCB0byByZWZsZWN0IHRoYXQu DQoNClJGQzgyNTkgSlNPTiBkb2VzIGhhdmUgdGhhdCB0ZXh0LiBGb3IgZXhhbXBsZSwgImdvb2Qg aW50ZXJvcGVyYWJpbGl0eSBjYW4gYmUgYWNoaWV2ZWQgYnkgaW1wbGVtZW50YXRpb25zIHRoYXQg ZXhwZWN0IG5vIG1vcmUgcHJlY2lzaW9uIG9yIHJhbmdlIHRoYW4gWzY0LWJpdCBmbG9hdHNdIHBy b3ZpZGUiOyAid2hlbiB0aGUgbmFtZXMgd2l0aGluIGFuIG9iamVjdCBhcmUgbm90IHVuaXF1ZSwg dGhlIGJlaGF2aW9yIFsuLi5dIGlzIHVucHJlZGljdGFibGUiLg0KDQpGb3IgbW9yZSBjb25jcmV0 ZSB0ZXh0LCB1c2UgUkZDNzQ5MyBJLUpTT04gKEludGVybmV0IEpTT04gaXMgYSByZXN0cmljdGVk IHByb2ZpbGUgb2YgSlNPTikuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From nobody Fri May 10 01:34:36 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 25B36120113 for ; Fri, 10 May 2019 01:34:35 -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_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 jhIivRxNv0yB for ; Fri, 10 May 2019 01:34:33 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 C975A120194 for ; Fri, 10 May 2019 01:34:32 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id h11so6409136wmb.5 for ; Fri, 10 May 2019 01:34:32 -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=Fs38wufHhoJvm1e9sRuqW3qY9+25E614Xdr6SUAqEoY=; b=Bc9bGfg/mTJ/5sO3yQALUYeHFzQ/sA/ng0fr4yCve6hy9ylaYFJ3cUyf7mNEM2Ya3U mcJDoakOkg7vUy1Cqec7ukpnbWBLZ+DcMPbJR44ajtDn818l6dKnv2dczaOEFrUJhknB AjU2OWn55Jq4f1esx6wPj+aLGbmkuV+IGfWTHXZSy+uSQksrZSzWVjyDYWkuJ8v6nIOn J/QiV8foQasEC3Vfx07eMEOVGQhZthAfFF3PkL61n89n4JsOw5pc5nN2YfXgW4r+R69v FLsQDGqCbsl83W1uUOAOOVGL2iWiZlvojJhaRPkskJM31R1RkrWSinIsC7yY2Cow81r5 lhsQ== 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=Fs38wufHhoJvm1e9sRuqW3qY9+25E614Xdr6SUAqEoY=; b=f3geuwodpKm2pbbSa43gA15XqSYJFpARy/PhF8tRjmRu1E+jo0gAp5FqFxlzVihXKq opv889ZwDgj8RcMjF3dCxihoQwjVeBqBZltVfLvGX8r+bcIl17S5nwh0w7alG8kTHkvq YTWZtZQneBnSKm1JES0tgJO+cIVnaDXfE0eaL74/BZOIFNqDGTsioBq1sV0SSlJLPC64 +y4lf1tFWiyGHEaWv+h99xsXFu1Kw+AWQfcITXcnlGxOcEA05ZLbqargDA04qgMfrBe/ 5tz3x1GasI2sf3ucTMhgOiKJIadT8cU65REBe0ZWteG1Qnw30iCICXviqnqFJUenOESR ro4Q== X-Gm-Message-State: APjAAAXhnYdAc7yWcoDmraTmTJ8BuYMoTLOAHxlyc5GguQyXfgQlS4kg Epl/aOneDWWoEt9C1mL94Qx/mIx2/cQ= X-Google-Smtp-Source: APXvYqxhRV+wVJWfM6rfrbJHTrplqvgHOwQfsoBgej0WuJ8IwzPlIwQXvO5+AgOH0U7IYiE2bgc1qQ== X-Received: by 2002:a1c:f901:: with SMTP id x1mr6284411wmh.136.1557477270922; Fri, 10 May 2019 01:34:30 -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 a128sm165777wma.23.2019.05.10.01.34.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 May 2019 01:34:30 -0700 (PDT) To: "Manger, James" , Austin Wright , Carsten Bormann Cc: JSON WG References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> <02755092-1682-45E8-AB6C-0EDA7D35703A@bzfx.net> <92D865C6-9990-46B1-961E-2DDD7D06617C@bzfx.net> From: Anders Rundgren Message-ID: <71a71f7a-128f-439f-e44f-fbb5cfc16ec3@gmail.com> Date: Fri, 10 May 2019 10:34:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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] Adding integers to JSON (Re: JSON Schema Language) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 08:34:35 -0000 On 2019-05-10 09:56, Manger, James wrote: >> “SHOULD" allows implementations to vary from the suggested behavior if there’s a reason. RFC8259 specifically says the reason is interoperability, and also says implementations might report all of the key-value pairs, even repeated keys. So if two implementations agree that repeated keys are meaningful, that seems legal to me. > > NO WAY! > RFC8259 JSON explicitly says when keys in an object are not unique the behaviour of parsers is unpredictable. So it you specify a system that gives meaning to repeated keys then lots of JSON parsers will be unusable in this case. Hence, it is harmful to call that JSON, call it "ECMA 404 syntax without normal JSON semantics". > >> I don’t see how the fact JSON can be streamed changes this. HTTP says servers must produce errors on some headers if they’re repeated; and HTTP is also parsed by streaming parsers. > > The number of elements in a JSON object and the number of headers in an HTTP message are both theoretically unbounded. But there is a strong assumption that the latter (#headers) is limited: typically 10s, perhaps 100, never 1000s. Web servers limit total header size to, say, 8KB. That is small enough to always handle repeats. While many JSON objects will also be small, JSON is such a generic format that you cannot make a global assumption that JSON objects will always be small enough to hold in memory. Hence some apps will need streaming JSON processors that cannot reasonably detect duplicate keys (so the "SHOULD" is there to accommodate these). > > >> Now, if the vast majority of JSON implementations don’t recognize excess precision, and don’t allow (or ignore) repeated keys, then maybe JSON should be updated to reflect that. > > RFC8259 JSON does have that text. For example, "good interoperability can be achieved by implementations that expect no more precision or range than [64-bit floats] provide"; "when the names within an object are not unique, the behavior [...] is unpredictable". > > For more concrete text, use RFC7493 I-JSON (Internet JSON is a restricted profile of JSON). Right on! I have "hammered" a bit on Oracle who interpreted I-JSON "literally" making small BigIntegers serialize as Number and big such as String which probably breaks most schemas. They now seem to have come to their senses: https://github.com/eclipse-ee4j/jsonp/issues/160 Oracle do not support duplicate keys either. If you want to use such you are probably not really a candidate for using a schema. JSON is slowly but surely getting better :) thanx Anders > > -- > James Manger > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Fri May 10 06:31:58 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 66F421201D6 for ; Fri, 10 May 2019 06:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 oAWL9FqkZJbZ for ; Fri, 10 May 2019 06:31:55 -0700 (PDT) Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) (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 F34A512016D for ; Fri, 10 May 2019 06:31:54 -0700 (PDT) Received: by mail-ot1-f65.google.com with SMTP id g24so1021956otq.2 for ; Fri, 10 May 2019 06:31:54 -0700 (PDT) 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=hdptncFEFntke7vhJwBSmpnGLB+vhtzw0MzyMCKxjZY=; b=SBaJvo27aBpAg2d6Dw8tlYLgz2Nu6J9zFKIccvmJwkOiLYosOgbEv4IZQXeg1M0D9C 983YeP9En0H3/9KVtrE7D0Xt2gARNFNmqWJ+TqfiPeduylrUP+GmQmHr0GTxl1Fg+5P8 3/+8kbPOHWaSU8PMxcIdf4qziLOaOCk0zruLt7tM2yB7DC705fvEQNGNKElU1YDPjAyp EFXZYdwyQNl2VD8vI40cBR/T/vj9W+2E3Nx53Z4NiCT2+rmJU2LbJOzGXd75Y6SttXk8 NGiUkHZQZVx6QLORxZr6RHrySLOgFWQyhdUpNfwNGz8tZMPKmAnWs/QPayTCyIDwJus6 UEyg== X-Gm-Message-State: APjAAAXlj6e/SjZTwP6benPWroh5s6Ta3/Wty8bU3c0oRbIvRmwevevn cpvhogg+V0CIfSaApYkjSvO57uA0GHI3QPrE3j4= X-Google-Smtp-Source: APXvYqzT8iFy26QwSWbgd8pqsh2Lua8/n++qPCsoh0UaMiiDfqjyZ3WXtbtNXiVyFpK78nlGfVWiCwMcJnksTQz805g= X-Received: by 2002:a9d:5a11:: with SMTP id v17mr6924930oth.150.1557495114208; Fri, 10 May 2019 06:31:54 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <5a592d14-9468-6420-8420-52fd84a588fd@dret.net> In-Reply-To: <5a592d14-9468-6420-8420-52fd84a588fd@dret.net> From: Phillip Hallam-Baker Date: Fri, 10 May 2019 09:31:44 -0400 Message-ID: To: Erik Wilde Cc: Carsten Bormann , Pete Cordell , Ulysse Carion , JSON WG Content-Type: multipart/alternative; boundary="000000000000059a5305888897a2" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 13:31:57 -0000 --000000000000059a5305888897a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 8, 2019 at 12:43 PM Erik Wilde wrote: > On 2019-05-08 08:46, Carsten Bormann wrote: > > If I have to work on a W3C Schema(*), I convert it to Relax-NG compact > first. True, I=E2=80=99ll lose some information, but as a net result I'l= l digest > much more information out of the W3C Schema document than if I had direct= ly > looked at that. > > At the time when I was closer to the XML community, the hallway > consensus was that W3C Schema was *designed* to sell more tools. > > that's one way to look at it. given the complexity of XSD's model (which > is a different discussion to have), it's hard to imagine how you could > easily work with it just using a generic underlying model (of any kind: > even the RNG compact syntax isn't easily revealing all relationships). > > it's probably fair to say that any sufficiently complex domain model > will require you to use tooling supporting it, instead of being able to > just work with a source file of any format. > > to me, the first discussion to have is how complex/powerful you want the > domain model to be (XSD went completely overboard there). *after* that > has been decided, and if it is of modest complexity, then it may make > sense to consider a syntax based on a generic model so that people can > directly read (and possibly even write) the source. > > for old times sake, at https://www.xml.com/pub/a/2003/08/27/xscs.html is > a specific XSD syntax we worked on to have a good "source file UX" for > XSD. of course it never caught on because people used tools anyways, and > this approach required specific code for reading and writing XSCS. > XSD was designed to be a replacement for SGML DDLs. It is a document markup, not a data markup. Document markup cares about the order in which fields are entered. Data markup really doesn't. XML has many features that are bogus. The distinction between elements and attributes for example. But they were in SGML and XML couldn't drop them. The decision to use SGML in the Web was purely driven by deployment/adoption concerns. We all hated it. There were many technical issues, the tooling was awful, the specification was broken. The only reason HTML used SGML was to get the publishing industry onside. XML was an attempt to get rid of as much of the stupid from SGML as possible. XSD was a necessary part of enabling XML. --000000000000059a5305888897a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Wed, May 8, 2019 at 12:43 PM Erik Wilde <erik.wilde@dret.net> wrote:
    On 2019-05-08 08:46, = Carsten Bormann wrote:
    > If I have to work on a W3C Schema(*), I convert it to Relax-NG compact= first.=C2=A0 True, I=E2=80=99ll lose some information, but as a net result= I'll digest much more information out of the W3C Schema document than = if I had directly looked at that.
    > At the time when I was closer to the XML community, the hallway consen= sus was that W3C Schema was *designed* to sell more tools.

    that's one way to look at it. given the complexity of XSD's model (= which
    is a different discussion to have), it's hard to imagine how you could =
    easily work with it just using a generic underlying model (of any kind: even the RNG compact syntax isn't easily revealing all relationships).<= br>
    it's probably fair to say that any sufficiently complex domain model will require you to use tooling supporting it, instead of being able to just work with a source file of any format.

    to me, the first discussion to have is how complex/powerful you want the domain model to be (XSD went completely overboard there). *after* that
    has been decided, and if it is of modest complexity, then it may make
    sense to consider a syntax based on a generic model so that people can
    directly read (and possibly even write) the source.

    for old times sake, at https://www.xml.com/pub/a/2003/= 08/27/xscs.html is
    a specific XSD syntax we worked on to have a good "source file UX"= ; for
    XSD. of course it never caught on because people used tools anyways, and this approach required specific code for reading and writing XSCS.

    XSD was designed to be a replacement for SGML DDLs. It is a documen= t markup, not a data markup.

    Document markup cares about the order in which fields are entered. Data= markup really doesn't.

    XML has many features that are bogus. The dist= inction between elements and attributes for example. But they were in SGML = and XML couldn't drop them.=C2=A0

    The decision to use SGML in the Web was purely driven by deplo= yment/adoption concerns. We all hated it. There were many technical issues,= the tooling was awful, the specification was broken. The only reason HTML = used SGML was to get the publishing industry onside.

    XML was an attempt to get rid of as much of the= stupid from SGML as possible. XSD was a necessary part of enabling XML.


    --000000000000059a5305888897a2-- From nobody Fri May 10 17:41: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 0951C1200E3 for ; Fri, 10 May 2019 17:41:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-org.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 Mq5SCiJV3vxh for ; Fri, 10 May 2019 17:41:03 -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 77AA3120043 for ; Fri, 10 May 2019 17:41:03 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id r7so8918853wrr.13 for ; Fri, 10 May 2019 17:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iUk9d0UWVFeG58zdCwKWGFNgPvfwQAFopCpN4KrnyNc=; b=gHun7Fvmss5ZOBFkkznY2DDMtM0geddPtH757YKjwm7sqTkqcxb/uCmhnL1dJl9OKM CkkBVxAJw3TdgudkDSRnPqKJ7/gyj5OjRRutuMmanYVwksp4wRr4XVpDyVXjHYOLUIdP rHBcse97xNWbAkhYQKGFcq5i55wLJ+HoYHDIZZXpFE6gxSGVJOYhab/Egxw6L3h5+Scs SaN2ItxcVD57p/+zkv4kQ/IGVv0p8xBuL5iFxh7acoECw1LYP4H8oE2YrP7sxt5dDzI3 Mht00xlQRVS6oKUzFVqhgx4fLQ3Lrfu8/Nn0WirQeTR/TNPzGH/Ywd8eYcYCxJvlCI9j oLUg== 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=iUk9d0UWVFeG58zdCwKWGFNgPvfwQAFopCpN4KrnyNc=; b=l4LWEa0P1RzhuSnq4MYNefBHuk5ddpkFB5BWzDIrAcVzYOoparmE9ypqHfgJGsgQAg HgRPnFQ6yh5xkPhuXyNjqxzysKeGlMmaE3DafwesArQtK2dv8DiPMxrfR1TIyb523WB/ 1FGFzMPptluk5CkbmtlZ+LsOKCMPFhnDLzhrN1KGdh70kf6Ag96VjG/9vQd7o7TLfVc6 sZliDSV0Kstt54MqchT3mCJdXghr1MvakJ/T16Vi6DWAJYFhjqBaJU1G9IYEoDKvlXAm Fvk0t6E4ZOIoou+io30h76FEswIcjAA49TcwPdZ1ylMYjEwsYejS59xCoKkIoDdCj2ng EhUQ== X-Gm-Message-State: APjAAAXRftWtMrZWl+MehEsYkxelx3eXcTiA/M4at7zCBIRntCR/a2Mj WajuXfi3gXTh+plLnPm8ogcYQNo31ifRr+QLMzi6DQ== X-Google-Smtp-Source: APXvYqxfFrxmpKUIUFGdpZ1EPCD53d7v/+Ko+pA34//rJXZ8zjdVxUKF2bumGZYf954Ylr+OR5Lxqajw4GHqKtyCOK8= X-Received: by 2002:a5d:5544:: with SMTP id g4mr2117872wrw.327.1557535261920; Fri, 10 May 2019 17:41:01 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <5a592d14-9468-6420-8420-52fd84a588fd@dret.net> In-Reply-To: From: John Cowan Date: Fri, 10 May 2019 20:40:49 -0400 Message-ID: To: Phillip Hallam-Baker Cc: Erik Wilde , Carsten Bormann , JSON WG , Pete Cordell , Ulysse Carion Content-Type: multipart/alternative; boundary="00000000000003299a058891f001" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 00:41:07 -0000 --00000000000003299a058891f001 Content-Type: text/plain; charset="UTF-8" On Fri, May 10, 2019 at 9:31 AM Phillip Hallam-Baker wrote: > XML has many features that are bogus. The distinction between elements and > attributes for example. But they were in SGML and XML couldn't drop them. > There were a *huge* number of things in SGML that XML dropped. Not enough, I agree. But the difference between elements and attributes is the difference between ordered content (which documents need) and not-so-ordered properties (which documents also need). Here are two approaches to simplifying XML that I like very much. MicroXML is a subset of XML, as XML is a subset of SGML. See < https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microxml.html>. The spec is 10 pages long including a data model. FtanML is syntactically different and semantically more flexible: it would make a good replacement for both XML and JSON. See < https://www.balisage.net/Proceedings/vol10/html/Kay01/BalisageVol10-Kay01.html>. ("Ftan" is a village in Switzerland where the language was developed, not an acronym.) The spec is 27 pages long, including a data model, a schema language, and a transformation language. > XML was an attempt to get rid of as much of the stupid from SGML as > possible. XSD was a necessary part of enabling XML. > I can't agree with you there. RELAX NG would have been just as usable for the purpose. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org At times of peril or dubitation, Perform swift circular ambulation, With loud and high-pitched ululation. --00000000000003299a058891f001 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Fri, May 10, 2019= at 9:31 AM Phillip Hallam-Baker <ietf@hallambaker.com> wrote:
    =C2=A0
    XML has many features that are bogus. The dist= inction between elements and attributes for example. But they were in SGML = and XML couldn't drop them.

    There were a *huge* number of things in SGML that XML dropped.=C2=A0= Not enough, I agree.=C2=A0 But the difference between elements and attribu= tes is the difference between ordered content (which documents need) and no= t-so-ordered properties (which documents also need).

    Here are two approaches to simplifying XML that I like very much.
    <= div>
    MicroXML is a subset of XML, as XML is a subset of SGML.= =C2=A0 See <https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microxml.= html>.=C2=A0 The spec is 10 pages long including a data model.
    =

    FtanML is syntactically different and semantically more= flexible: it would make a good replacement for both XML and JSON.=C2=A0 Se= e <https://www.balisage.net/Proceedings/vol10/html/Kay01= /BalisageVol10-Kay01.html>.=C2=A0 ("Ftan" is a village in = Switzerland where the language was developed, not an acronym.)=C2=A0 =C2=A0= The spec is 27 pages long, including a data model, a schema language, and a= transformation language.
    =C2=A0
    XML was an attempt to get rid of as much of the stupid from SG= ML as possible. XSD was a necessary part of enabling XML.
    =

    I can't agree with you there.=C2=A0 RE= LAX NG would have been just as usable for the purpose.

    =

    =

    --00000000000003299a058891f001-- From fangqq@gmail.com Mon May 13 16:52:21 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 AB52A1200C5 for ; Mon, 13 May 2019 16:52:21 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 dKferXKcisBQ for ; Mon, 13 May 2019 16:52:19 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 CD271120026 for ; Mon, 13 May 2019 16:52:18 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id k189so9234777qkc.0 for ; Mon, 13 May 2019 16:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=tGlHbrTXbWSUv9qeLmdIHBczicaByejVXIRJNBg45Q4=; b=scLnzDsYarWB/uTpskVJFvNxQi8LK17XYAdeUcz5+XsjzWmBbxut6AHbaeH5MA7rSk /B0jBc0ppA9Dl0DEH+rfOYMAmNQk8FtrpJ5L2myysyVVpnY72UGklUy/a5bdhwzt7hyV CVIwmQj/dmaIykDT44IRn22IDNtj6JuTxjjPpYEOVQINw8O0c9w2p0s0hOsDunNfQ9rl hM9nnCQKFjpUTS3Sarz18IjdkeKmgdW/qW1hOMv+GEfWKwbX2IMiWBXmNLxP7k6qYhAV oWFQyX+bNPJYzpuUBN7HToytygwvR+DVwrB8HJL4ru9h/hrxGPeek5MbWXQJ4XQ52PHU IEtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=tGlHbrTXbWSUv9qeLmdIHBczicaByejVXIRJNBg45Q4=; b=Id9jffC6on5xLu3ZyP9KsG7LHzMD6DLTcRmY57xDhnTD6VKOU+hRmpTUkVZn0+LwZ4 lHwI1Tc/xmLc7H0/6ZrqgzFfs47wHA3x8/PsD2JJj7ojt0wV7CtX0ntfQF82jnvtJOT3 wE6BvB7wk9ccRYNnB836ZEgzlBxARjHb9GaOxIJSr/Z1UP8rO5ET5pwnub6eg4JxEQgS jlqD89bCGtZn1Wnlvez0EfE0a1dZbOld6I8N/sXyJ5duq5s2HPxG6cdNrTOXIKo1srXb i+g8p4i6pkUvyh509BMwVYUjmoirQrxF3IWYK4Z+pPLa/nbqaA3L0zI8prHH2x6fr17Y KVXQ== X-Gm-Message-State: APjAAAUOsHOzxamGe7U+redDEklHws3faO4xmSo3yOabtVBek2cPNFsk DO6Aje1gQiAAS5gZqnqBpCocUnA9v2I= X-Google-Smtp-Source: APXvYqwmCi+gx0nh3N84dpLwJzYOZdKlMaPvE03pP/ZygxOKZZ9vYNgGGiSiziwCvq4e/0tszzr6Wg== X-Received: by 2002:a37:5945:: with SMTP id n66mr23936631qkb.295.1557791537372; Mon, 13 May 2019 16:52:17 -0700 (PDT) Received: from [129.10.224.37] ([129.10.224.37]) by smtp.gmail.com with ESMTPSA id f129sm7659142qkj.47.2019.05.13.16.52.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 16:52:16 -0700 (PDT) To: json@ietf.org From: Qianqian Fang Message-ID: <72cccaa7-d2d6-e7ce-57ee-a86a98626d36@gmail.com> Date: Mon, 13 May 2019 19:52:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F45B8BDF3CDC299842F1ADB0" Content-Language: en-US Archived-At: Subject: [Json] JData: A general-purpose data storage and interchange format 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, 14 May 2019 15:15:04 -0000 This is a multi-part message in MIME format. --------------F45B8BDF3CDC299842F1ADB0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear list, (I am new to this mailing list, apologize if this is not the right place to post proposals of new JSON-based specifications - in that case, I am appreciated if you can point me to the right direction). I am a researcher/professor working in a university. A big part of my work, aside from teaching, involves writing computing software and processing medical image data. Over the past 10 years, I gradually migrated the software I wrote, most of them are open-source, some funded by the NIH, to use JSON as the input/output - I really love this format because it is human readable, easy to manipulate, compact, with parsers widely available. In 2011, I wrote a JSON encoder/decoder MATLAB toolbox , called JSONLab , and the toolbox has grown a small user community since. In 2013, I added support for UBJSON (http://ubjson.org), a simple binary JSON format, into my toolbox. Around 2015, I felt strongly that a combination of text and binary JSON is well capable in handling a wide variety of scientific data that I, and many of my colleagues, handle on a daily basis. Compared to the more "advanced" and "feature-rich" data formats such as HDF5, CDF and NetCDF, JSON/UBJSON has clear advantage of being so simple, excellently readable and requiring much low programming overhead to implement. Many other less complicated but still somewhat "opaque" imaging data formats such as DICOM, Analyze7.5 and NifTi, can also benefit from a more human-readable version if one can find a data mapping to JSON/UBJSON. So I started a project called "JData" to use JSON constructs to map common data structures, such as N-D arrays, hashes, tables, trees, graphs etc, as the foundation to store/interchange scientific data in a more readable and easy-to-operate fashion (many of these are already supported in JSONLab). After much procrastination, I finally finished the first draft of this specification, and would like your thoughts. The current draft of the specification can be found here https://github.com/fangq/jdata/blob/master/JData_specification.md the repository dedicated to the development and maintenance this specification is https://github.com/fangq/jdata The overall idea is to define complex data structures using a set of dedicated "name" tags in JSON/UBJSON without changing the syntax of the format. This makes the generated file JSON/UBJSON compatible and can be readily parsed by most existing parsers. Currently, this specification supports the following major features: 1. N-D arrays with and without data compression 2. Trees, tables, hashes, graphs, linked lists 3. Inline metadata and metadata node append-able to all elements 4. Data grouping tags similar to HDF5 5. Indexing and query interface 6. Referencing and link support 7. dual interface text <-> binary The keyword names were choose to minimize conflict with other JSON features that are under development (such as JSON-LD, JSON schema). I am sure there are typos and minor issues that I overlooked as an early draft. What I would like to hear from this community are 1. well, what do you think? is this a project that you would consider useful (in general and for the research community)? 2. any major loopholes in the design of the specification? I am new to writing a specification from scratch, I don't want to miss anything important from the start 3. if there is a value to continue developing this specification/file format, what is the typical path way for such development? what are the appropriate community/group to discuss ideas and get suggestions? again, I have no experience writing an RFC or specification from scratch, so, please be gentle, and I appreciate your guidance and pointers. Qianqian --------------F45B8BDF3CDC299842F1ADB0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

    Dear list,

    (I am new to this mailing list, apologize if this is not the right place to post proposals of new JSON-based specifications - in that case, I am appreciated if you can point me to the right direction).

    I am a researcher/professor working in a university. A big part of my work, aside from teaching, involves writing computing software and processing medical image data. Over the past 10 years, I gradually migrated the software I wrote, most of them are open-source, some funded by the NIH, to use JSON as the input/output - I really love this format because it is human readable, easy to manipulate, compact, with parsers widely available.

    In 2011, I wrote a JSON encoder/decoder MATLAB toolbox, called JSONLab, and the toolbox has grown a small user community since. In 2013, I added support for UBJSON (http://ubjson.org), a simple binary JSON format, into my toolbox. Around 2015, I felt strongly that a combination of text and binary JSON is well capable in handling a wide variety of scientific data that I, and many of my colleagues, handle on a daily basis. Compared to the more "advanced" and "feature-rich" data formats such as HDF5, CDF and NetCDF, JSON/UBJSON has clear advantage of being so simple, excellently readable and requiring much low programming overhead to implement. Many other less complicated but still somewhat "opaque" imaging data formats such as DICOM, Analyze7.5 and NifTi, can also benefit from a more human-readable version if one can find a data mapping to JSON/UBJSON.

    So I started a project called "JData" to use JSON constructs to map common data structures, such as N-D arrays, hashes, tables, trees, graphs etc, as the foundation to store/interchange scientific data in a more readable and easy-to-operate fashion (many of these are already supported in JSONLab). After much procrastination, I finally finished the first draft of this specification, and would like your thoughts.

    The current draft of the specification can be found here

    https://github.com/fangq/jdata/blob/master/JData_specification.md

    the repository dedicated to the development and maintenance this specification is

    https://github.com/fangq/jdata

    The overall idea is to define complex data structures using a set of dedicated "name" tags in JSON/UBJSON without changing the syntax of the format. This makes the generated file JSON/UBJSON compatible and can be readily parsed by most existing parsers.

    Currently, this specification supports the following major features:

    1. N-D arrays with and without data compression
    2. Trees, tables, hashes, graphs, linked lists
    3. Inline metadata and metadata node append-able to all elements
    4. Data grouping tags similar to HDF5
    5. Indexing and query interface
    6. Referencing and link support
    7. dual interface text <-> binary

    The keyword names were choose to minimize conflict with other JSON features that are under development (such as JSON-LD, JSON schema).

    I am sure there are typos and minor issues that I overlooked as an early draft. What I would like to hear from this community are

    1. well, what do you think? is this a project that you would consider useful (in general and for the research community)?
    2. any major loopholes in the design of the specification? I am new to writing a specification from scratch, I don't want to miss anything important from the start
    3. if there is a value to continue developing this specification/file format, what is the typical path way for such development? what are the appropriate community/group to discuss ideas and get suggestions?

    again, I have no experience writing an RFC or specification from scratch, so, please be gentle, and I appreciate your guidance and pointers.

    Qianqian

    --------------F45B8BDF3CDC299842F1ADB0-- From nobody Tue May 28 19:41:00 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 E9A781200F8 for ; Tue, 28 May 2019 19:40:58 -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, HTML_MESSAGE=0.001, 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=textuality-com.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 js-p3O-jwgAt for ; Tue, 28 May 2019 19:40:56 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 52D32120099 for ; Tue, 28 May 2019 19:40:56 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id u13so539789iop.0 for ; Tue, 28 May 2019 19:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lttWZsRbojDzH/cXFQRyUe/ho8c419lZ+VAPfPEw9PQ=; b=RG3AqETNGXpuAvTevxC90OlMyeyoXLsaYWzTPKkUhafYh0l+CSAYU8kSPgAKI0AvjC ZIWmN4JxgEQL6wEM1LMhRgrBJSjwRA5OyTI2TTQmg9KGcG5gtPYJhlShleHU7nTsDp59 N0rGwd3uni0oKBM6jUeE2S0IQPTLcZLaW/m4+xExxNh7h+mpD2kDVl0lMVFW0/q8ellE bhuAmX9VmKqK3FdsAoJXfXxEeHYz9fyDW1xFrC2pA9At9Axspu9urfmY+TbJx60XXezw rB1G2xIMnH+A4i3WleyL6YD9cii+fspOFdfMsIFOjMR3QRHOsXbfkuTMEJ/L/WbKOwBH LV3g== 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=lttWZsRbojDzH/cXFQRyUe/ho8c419lZ+VAPfPEw9PQ=; b=XmRRu4JZsp3st/CdVer6LsC031Cwp+HjAU+vzHQiKBCLsAsTch1aXH7OxXExctC6q5 9S71AA9AcjrQWszfDPldRTrSTQljMQ2aQtYBWg9oj9h5Ih0Fv82XPKe1vsosHMMzUPkf Af+UAe3SaJaIjKSxXoNgR3SjrYYSRDJPf007IE4TD62iNt31a4WfzLRlOuBc3ufnXv/q e23dPUZfWYjnpmymD5H2Vykj2+VUkVhMt/mgJ1YPVk6exz+ty9/QHMqhi3vqCYmkXf7i MGRMCVkoFYgQgAWDXDHvLH0zmmihjXfRcV9d4PGH1awgSQwSbi+wZt2Xj4tsybL9A3/c JyCw== X-Gm-Message-State: APjAAAUlEP1iQk1T65GKliSTZyImcY9fjRIEbh1e3/Hk440t87hmjSlK G24nqOghPQulbyUpKGYzjn6THvrSKH7VLgybIAL0Qw== X-Google-Smtp-Source: APXvYqzoqbyXw7mP4DOS1LqTqWI/mzFaK0xXtxQGtO4TLss7w8lEqfvhTFjPhub1UWIYiZtr2fLNj9gkNuh4vzT54J8= X-Received: by 2002:a05:6602:211a:: with SMTP id x26mr1130054iox.202.1559097655482; Tue, 28 May 2019 19:40:55 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> In-Reply-To: <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> From: Tim Bray Date: Tue, 28 May 2019 19:40:44 -0700 Message-ID: To: Carsten Bormann Cc: Ulysse Carion , JSON WG Content-Type: multipart/alternative; boundary="000000000000ece1ab0589fdb575" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 02:40:59 -0000 --000000000000ece1ab0589fdb575 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So Carsten, I am a person who would benefit from a super-simple JSON schema langauge; in effect, something like JSL + enums + timestamps. Furthermore, as I've said, I'm willing to invest some IETF-work cycles to get such a thing, in the event we could interest the community. Do you think that doing such a JSL and defining it using established CDDL semantics might be a good idea? Alternately, might we retain CDDL syntax and define a profile/subset which would be appropriate for us JSON-only simpletons? I'm not terribly fussy about mechanisms. On Fri, May 10, 2019 at 12:16 AM Carsten Bormann wrote: > On May 10, 2019, at 05:55, Ulysse Carion wrote: > > > > Carsten, > > > > Do you think that our difference in opinion on CDDL vs JSON Schema > > Language may be attributable to a difference in requirements? > > Hi Ulysse, > > I=E2=80=99m not even sure we disagree. That was why I became interested = in > converting between JSL and CDDL. As I was trying to show, CDDL might mak= e > a fine presentation language for JSL, and JSL might be a nice =E2=80=9Cpr= ofile=E2=80=9D for > CDDL that is very simple to process. > > > It seems to me that your use-case is centered around defining > > standards and other complex data requirements. CDDL is, in my view, > > unquestionably a better choice for this use-case. In my mind, CDDL is > > ABNF for CBOR, and that is undeniably what standards dealing with CBOR > > or its near-equivalents require. The existing references, from RFCs, > > to CDDL are testament to this. > > Yes, you are describing the intention correctly. I would add that CDDL > has proven as useful for describing pure JSON protocols as for CBOR. > > Not all JSON/CBOR protocols need the full capabilities of CDDL. For > instance, the example in the CDDL spec for RFC 7071 could easily be > expressed in JSL, except for two details: reputation-object is not meant = to > be extensible (reputon is), and there are some value constraints (some > values are integers). > > > But I (and I suspect Tim) am more preoccupied solely with defining the > > mundane sorts of messages that come out of JSON event processing and > > repetitive JSON APIs. Tim has blogged (see link in my original email) > > about dealing with AWS's CloudWatch events. That's messages that look > > like this: > > > > > https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.htm= l > > > > Tons of messages, and frequently being added and updated. But none of > > these messages are particularly exciting from a schema perspective. > > Well, I just had a look at (randomly selected) > > https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.htm= l#health-event-types > You=E2=80=99d need to add enumerations to JSL. There are also timestamps= in the > object (ironically in two different formats). There is a table that maps > language tags to messages in that language. (And the second and third > example have a missing bracket.) But I can=E2=80=99t really say, because= the > description by example only just begins to expose the actual intention. > > > CDDL can do much more than is necessary for merely representing > > CloudWatch events. This may seem like a good thing, but such excess > > capability reduces the suitability of the solution. JSON Schema > > Language is intentionally small and scuttled in scope, so as to > > simplify code and UI generation. By being so limited in scope, JSON > > Schema Language fits more easily into the architecture of a system > > that would like to integrate it. > > I=E2=80=99ve seen my share of developments that start simple. How much > functionality will be added to JSL before it becomes a standard? Also, t= he > law of extensibility tells us it will be extended even after becoming a > standard. > > Of course, in its domain, CDDL is incredibly simple. Compare to JCR: JCR > is about three times as complex as CDDL. This is because CDDL was built > from a few very simple building blocks, which combine nicely to provide i= ts > functionality. JCR is more of an accretion of features, which in sum can > do most of what CDDL can do. > > But back to JSL and CDDL: > What I=E2=80=99m interested in is what are the sweet spots on this functi= onality > vs. complexity continuum. I think we have found two of these sweet spots > (at least maybe after a little more calibration). Now how do we handle t= he > onslaught of applications that don=E2=80=99t quite fit the sweet spots? > > The question that intrigues me: Is it possible to define something that i= s > as simple as JSL when you need just that, but allows dipping into the > capabilities of something like CDDL where needed? > > By the way: You may not be aware of the WISHI activity we have in the > T2TRG (thing-to-thing research group) of the IRTF. Here we look at > modeling (not just for data) and at translating between different modelin= g > approaches. http://wishi.space if you want to have a look. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --000000000000ece1ab0589fdb575 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    So = Carsten, I am a person who would benefit from a super-simple JSON schema la= ngauge; in effect, something like JSL=C2=A0+ enums=C2=A0+ timestamps.=C2=A0= Furthermore, as I've said, I'm willing to invest some IETF-work cy= cles to get such a thing, in the event we could interest the community.=C2= =A0 Do you think that doing such a JSL and defining it using established CD= DL semantics might be a good idea?=C2=A0=C2=A0

    Alternately, might we retain CDDL syntax and define a= profile/subset which would be appropriate for us JSON-only simpletons?

    I'm not terribly fussy a= bout mechanisms.



    On Fri, May 10, 2019 at 12:16 AM Carsten Bormann <cabo@tzi.org> wrote:
    On May 10, 2019, at 05:55, Ulysse Carion <ulysse@segment.com>= ; wrote:
    >
    > Carsten,
    >
    > Do you think that our difference in opinion on CDDL vs JSON Schema
    > Language may be attributable to a difference in requirements?

    Hi Ulysse,

    I=E2=80=99m not even sure we disagree.=C2=A0 That was why I became interest= ed in converting between JSL and CDDL.=C2=A0 As I was trying to show, CDDL = might make a fine presentation language for JSL, and JSL might be a nice = =E2=80=9Cprofile=E2=80=9D for CDDL that is very simple to process.

    > It seems to me that your use-case is centered around defining
    > standards and other complex data requirements. CDDL is, in my view, > unquestionably a better choice for this use-case. In my mind, CDDL is<= br> > ABNF for CBOR, and that is undeniably what standards dealing with CBOR=
    > or its near-equivalents require. The existing references, from RFCs, > to CDDL are testament to this.

    Yes, you are describing the intention correctly.=C2=A0 I would add that CDD= L has proven as useful for describing pure JSON protocols as for CBOR.=C2= =A0

    Not all JSON/CBOR protocols need the full capabilities of CDDL.=C2=A0 For i= nstance, the example in the CDDL spec for RFC 7071 could easily be expresse= d in JSL, except for two details: reputation-object is not meant to be exte= nsible (reputon is), and there are some value constraints (some values are = integers).

    > But I (and I suspect Tim) am more preoccupied solely with defining the=
    > mundane sorts of messages that come out of JSON event processing and > repetitive JSON APIs. Tim has blogged (see link in my original email)<= br> > about dealing with AWS's CloudWatch events. That's messages th= at look
    > like this:
    >
    > https://docs.aws.amaz= on.com/AmazonCloudWatch/latest/events/EventTypes.html
    >
    > Tons of messages, and frequently being added and updated. But none of<= br> > these messages are particularly exciting from a schema perspective.
    Well, I just had a look at (randomly selected)
    https:/= /docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#health-= event-types
    You=E2=80=99d need to add enumerations to JSL.=C2=A0 There are also timesta= mps in the object (ironically in two different formats).=C2=A0 There is a t= able that maps language tags to messages in that language.=C2=A0 (And the s= econd and third example have a missing bracket.)=C2=A0 But I can=E2=80=99t = really say, because the description by example only just begins to expose t= he actual intention.

    > CDDL can do much more than is necessary for merely representing
    > CloudWatch events. This may seem like a good thing, but such excess > capability reduces the suitability of the solution. JSON Schema
    > Language is intentionally small and scuttled in scope, so as to
    > simplify code and UI generation. By being so limited in scope, JSON > Schema Language fits more easily into the architecture of a system
    > that would like to integrate it.

    I=E2=80=99ve seen my share of developments that start simple.=C2=A0 How muc= h functionality will be added to JSL before it becomes a standard?=C2=A0 Al= so, the law of extensibility tells us it will be extended even after becomi= ng a standard.

    Of course, in its domain, CDDL is incredibly simple.=C2=A0 Compare to JCR: = JCR is about three times as complex as CDDL.=C2=A0 This is because CDDL was= built from a few very simple building blocks, which combine nicely to prov= ide its functionality.=C2=A0 JCR is more of an accretion of features, which= in sum can do most of what CDDL can do.

    But back to JSL and CDDL:
    What I=E2=80=99m interested in is what are the sweet spots on this function= ality vs. complexity continuum.=C2=A0 I think we have found two of these sw= eet spots (at least maybe after a little more calibration).=C2=A0 Now how d= o we handle the onslaught of applications that don=E2=80=99t quite fit the = sweet spots?=C2=A0

    The question that intrigues me: Is it possible to define something that is = as simple as JSL when you need just that, but allows dipping into the capab= ilities of something like CDDL where needed?

    By the way: You may not be aware of the WISHI activity we have in the T2TRG= (thing-to-thing research group) of the IRTF.=C2=A0 Here we look at modelin= g (not just for data) and at translating between different modeling approac= hes.=C2=A0 http://wishi.space if you want to have a look.

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

    _______________________________________________
    json mailing list
    json@ietf.org
    https://www.ietf.org/mailman/listinfo/json
    --000000000000ece1ab0589fdb575-- From nobody Tue May 28 20:01:10 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 574311200FB for ; Tue, 28 May 2019 20:01: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=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 LTXLBPnBp8r7 for ; Tue, 28 May 2019 20:01:05 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 3F6D91200C5 for ; Tue, 28 May 2019 20:01:05 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id f22so514182iol.11 for ; Tue, 28 May 2019 20:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CbxfKvQSqjtCwVFiaydbMUz3LNPWLln+jjjlvZOGq5o=; b=EKJTJMy9msaMlx8CmyKFLEIsZVyeaIz/6ap17HeHwa9490QV74YqsC6FChempoWkNt QR2RRL+PQu2SfbO6KALDtoGaSvNRCrFvfIa5OFMwf+1B3CQ8SuBeWXTw6UsZJKM+MP8U EvQuxjDGUWKGVhIbDxEP2PfHesh56Y6ORjaZtQKLTjHK6X0CsPqG6S5QijKJtzHaU/kc NLDjGTV7svqmnH7ZlWztd/beYCA1DJ8n58O41bg9k6tqktFSqEXPQHVTjyIcj9r3XR8k STkUwGs6AAu17Zp3HeesWyTYmjUnXFTeZwGjiIKSoAGUgcqm+hrHSxoU8yyOhv/q+2nh /Oxg== 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=CbxfKvQSqjtCwVFiaydbMUz3LNPWLln+jjjlvZOGq5o=; b=q6ZjSj/kphV3e7oqv/TQMTK8NpwZXsDw4U1AEZ+A1r72E8yWlTnu5vEUMtN/dZejih LXkDVwnpdtYiZbuTuocPbNNGlwJcvOLdhoN9yvTAmEEIy47GZbhpqNpg4cOld3j4KdZl kbmAANV5OFbVJHKDuxFbp5GgPTJ0PLLiWmnKlcQgYb4aLb+R9atJmfM/IrFOB5t3NB0A D9A1v9QZtW0Z4hyVTaiqtBsTdqv9SzLDRHsvKeHgaVfWbDUYGRZU6ZKI7rLI6f5UN6DV VY5/DUnmGp9D9ebTa6dhK6DyJhQlH92ItHnF/Uk6htlWaeFjZ6ij7o+F50xdxaEayoJX NvHQ== X-Gm-Message-State: APjAAAWi6B/zSr3XxnZR+4X+oRDWcJ2PmmBh4oXGAzpVkk30DKPcKv+g qxB65UXGqe05I9iV6Pf/ZLFhA5F54jBpczI5POE= X-Google-Smtp-Source: APXvYqzJEk55VomS57dfC1qH9hbtEEI6FQvPQFSfQK4rugiky46csrLxu+FRv1yGXT36ZcgQuTI8YZljMHwjvceBH9s= X-Received: by 2002:a5d:804f:: with SMTP id b15mr8579601ior.189.1559098864326; Tue, 28 May 2019 20:01:04 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> In-Reply-To: From: Rob Sayre Date: Tue, 28 May 2019 20:00:52 -0700 Message-ID: To: Tim Bray Cc: Carsten Bormann , JSON WG , Ulysse Carion Content-Type: multipart/alternative; boundary="000000000000fa62c80589fdfdf5" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 03:01:08 -0000 --000000000000fa62c80589fdfdf5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not sure this schema language will be productive as a source format in the long term, but I don't think it will be harmful. So, it's not worth an objection. The worst case would be that servers claim to conform to this schema language, but fail to serve schema-conformant JSON in practice. This seems like the likely outcome, in the absence of an output specification. I have to say, I think I am uniquely qualified to raise this point. I objected to the original JSON Stringify specification, which was something pretty close to string concatenation, and got it corrected to something close to its current form. If a schema language doesn't provide an output specification, it's probably not going to work in practice. Best case, it's a standards checkbox. - Rob On Tue, May 28, 2019 at 7:41 PM Tim Bray wrote: > So Carsten, I am a person who would benefit from a super-simple JSON > schema langauge; in effect, something like JSL + enums + timestamps. > Furthermore, as I've said, I'm willing to invest some IETF-work cycles to > get such a thing, in the event we could interest the community. Do you > think that doing such a JSL and defining it using established CDDL > semantics might be a good idea? > > Alternately, might we retain CDDL syntax and define a profile/subset whic= h > would be appropriate for us JSON-only simpletons? > > I'm not terribly fussy about mechanisms. > > > > On Fri, May 10, 2019 at 12:16 AM Carsten Bormann wrote: > >> On May 10, 2019, at 05:55, Ulysse Carion wrote: >> > >> > Carsten, >> > >> > Do you think that our difference in opinion on CDDL vs JSON Schema >> > Language may be attributable to a difference in requirements? >> >> Hi Ulysse, >> >> I=E2=80=99m not even sure we disagree. That was why I became interested= in >> converting between JSL and CDDL. As I was trying to show, CDDL might ma= ke >> a fine presentation language for JSL, and JSL might be a nice =E2=80=9Cp= rofile=E2=80=9D for >> CDDL that is very simple to process. >> >> > It seems to me that your use-case is centered around defining >> > standards and other complex data requirements. CDDL is, in my view, >> > unquestionably a better choice for this use-case. In my mind, CDDL is >> > ABNF for CBOR, and that is undeniably what standards dealing with CBOR >> > or its near-equivalents require. The existing references, from RFCs, >> > to CDDL are testament to this. >> >> Yes, you are describing the intention correctly. I would add that CDDL >> has proven as useful for describing pure JSON protocols as for CBOR. >> >> Not all JSON/CBOR protocols need the full capabilities of CDDL. For >> instance, the example in the CDDL spec for RFC 7071 could easily be >> expressed in JSL, except for two details: reputation-object is not meant= to >> be extensible (reputon is), and there are some value constraints (some >> values are integers). >> >> > But I (and I suspect Tim) am more preoccupied solely with defining the >> > mundane sorts of messages that come out of JSON event processing and >> > repetitive JSON APIs. Tim has blogged (see link in my original email) >> > about dealing with AWS's CloudWatch events. That's messages that look >> > like this: >> > >> > >> https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.ht= ml >> > >> > Tons of messages, and frequently being added and updated. But none of >> > these messages are particularly exciting from a schema perspective. >> >> Well, I just had a look at (randomly selected) >> >> https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.ht= ml#health-event-types >> You=E2=80=99d need to add enumerations to JSL. There are also timestamp= s in the >> object (ironically in two different formats). There is a table that map= s >> language tags to messages in that language. (And the second and third >> example have a missing bracket.) But I can=E2=80=99t really say, becaus= e the >> description by example only just begins to expose the actual intention. >> >> > CDDL can do much more than is necessary for merely representing >> > CloudWatch events. This may seem like a good thing, but such excess >> > capability reduces the suitability of the solution. JSON Schema >> > Language is intentionally small and scuttled in scope, so as to >> > simplify code and UI generation. By being so limited in scope, JSON >> > Schema Language fits more easily into the architecture of a system >> > that would like to integrate it. >> >> I=E2=80=99ve seen my share of developments that start simple. How much >> functionality will be added to JSL before it becomes a standard? Also, = the >> law of extensibility tells us it will be extended even after becoming a >> standard. >> >> Of course, in its domain, CDDL is incredibly simple. Compare to JCR: JC= R >> is about three times as complex as CDDL. This is because CDDL was built >> from a few very simple building blocks, which combine nicely to provide = its >> functionality. JCR is more of an accretion of features, which in sum ca= n >> do most of what CDDL can do. >> >> But back to JSL and CDDL: >> What I=E2=80=99m interested in is what are the sweet spots on this funct= ionality >> vs. complexity continuum. I think we have found two of these sweet spot= s >> (at least maybe after a little more calibration). Now how do we handle = the >> onslaught of applications that don=E2=80=99t quite fit the sweet spots? >> >> The question that intrigues me: Is it possible to define something that >> is as simple as JSL when you need just that, but allows dipping into the >> capabilities of something like CDDL where needed? >> >> By the way: You may not be aware of the WISHI activity we have in the >> T2TRG (thing-to-thing research group) of the IRTF. Here we look at >> modeling (not just for data) and at translating between different modeli= ng >> approaches. http://wishi.space if you want to have a look. >> >> 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 > --000000000000fa62c80589fdfdf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'm not sure this schema language will be product= ive as a source format in the long term, but I don't think it will be h= armful. So, it's not worth an objection. The worst case would be that s= ervers claim to conform to this schema language, but fail to serve schema-c= onformant JSON in practice. This seems like the likely outcome, in the abse= nce of an output specification.

    I have to say, I t= hink I am uniquely qualified to raise this point. I objected to the origina= l JSON Stringify specification, which was something pretty close to string = concatenation, and got it corrected to something close to its current form.=

    If a schema language doesn't provide an outpu= t specification, it's probably not going to work in practice. Best case= , it's a standards checkbox.

    - Rob
    <= br>

    On Tue, May 28, 2019 at 7:41 PM Tim Bray <tbray@textuality.com> wrote:
    So Carsten, I am a person who would ben= efit from a super-simple JSON schema langauge; in effect, something like JS= L=C2=A0+ enums=C2=A0+ timestamps.=C2=A0 Furthermore, as I've said, I= 9;m willing to invest some IETF-work cycles to get such a thing, in the eve= nt we could interest the community.=C2=A0 Do you think that doing such a JS= L and defining it using established CDDL semantics might be a good idea?=C2= =A0=C2=A0

    <= /div>
    Alternately, mi= ght we retain CDDL syntax and define a profile/subset which would be approp= riate for us JSON-only simpletons?

    I'm not terribly fussy about mechanisms.



    On Fri, May 10, 2019 at 12:16 AM C= arsten Bormann <cabo@t= zi.org> wrote:
    On May 10, 2019, at 05:55, Ulysse Carion <ulysse@segment.com> wrote:
    >
    > Carsten,
    >
    > Do you think that our difference in opinion on CDDL vs JSON Schema
    > Language may be attributable to a difference in requirements?

    Hi Ulysse,

    I=E2=80=99m not even sure we disagree.=C2=A0 That was why I became interest= ed in converting between JSL and CDDL.=C2=A0 As I was trying to show, CDDL = might make a fine presentation language for JSL, and JSL might be a nice = =E2=80=9Cprofile=E2=80=9D for CDDL that is very simple to process.

    > It seems to me that your use-case is centered around defining
    > standards and other complex data requirements. CDDL is, in my view, > unquestionably a better choice for this use-case. In my mind, CDDL is<= br> > ABNF for CBOR, and that is undeniably what standards dealing with CBOR=
    > or its near-equivalents require. The existing references, from RFCs, > to CDDL are testament to this.

    Yes, you are describing the intention correctly.=C2=A0 I would add that CDD= L has proven as useful for describing pure JSON protocols as for CBOR.=C2= =A0

    Not all JSON/CBOR protocols need the full capabilities of CDDL.=C2=A0 For i= nstance, the example in the CDDL spec for RFC 7071 could easily be expresse= d in JSL, except for two details: reputation-object is not meant to be exte= nsible (reputon is), and there are some value constraints (some values are = integers).

    > But I (and I suspect Tim) am more preoccupied solely with defining the=
    > mundane sorts of messages that come out of JSON event processing and > repetitive JSON APIs. Tim has blogged (see link in my original email)<= br> > about dealing with AWS's CloudWatch events. That's messages th= at look
    > like this:
    >
    > https://docs.aws.amaz= on.com/AmazonCloudWatch/latest/events/EventTypes.html
    >
    > Tons of messages, and frequently being added and updated. But none of<= br> > these messages are particularly exciting from a schema perspective.
    Well, I just had a look at (randomly selected)
    https:/= /docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#health-= event-types
    You=E2=80=99d need to add enumerations to JSL.=C2=A0 There are also timesta= mps in the object (ironically in two different formats).=C2=A0 There is a t= able that maps language tags to messages in that language.=C2=A0 (And the s= econd and third example have a missing bracket.)=C2=A0 But I can=E2=80=99t = really say, because the description by example only just begins to expose t= he actual intention.

    > CDDL can do much more than is necessary for merely representing
    > CloudWatch events. This may seem like a good thing, but such excess > capability reduces the suitability of the solution. JSON Schema
    > Language is intentionally small and scuttled in scope, so as to
    > simplify code and UI generation. By being so limited in scope, JSON > Schema Language fits more easily into the architecture of a system
    > that would like to integrate it.

    I=E2=80=99ve seen my share of developments that start simple.=C2=A0 How muc= h functionality will be added to JSL before it becomes a standard?=C2=A0 Al= so, the law of extensibility tells us it will be extended even after becomi= ng a standard.

    Of course, in its domain, CDDL is incredibly simple.=C2=A0 Compare to JCR: = JCR is about three times as complex as CDDL.=C2=A0 This is because CDDL was= built from a few very simple building blocks, which combine nicely to prov= ide its functionality.=C2=A0 JCR is more of an accretion of features, which= in sum can do most of what CDDL can do.

    But back to JSL and CDDL:
    What I=E2=80=99m interested in is what are the sweet spots on this function= ality vs. complexity continuum.=C2=A0 I think we have found two of these sw= eet spots (at least maybe after a little more calibration).=C2=A0 Now how d= o we handle the onslaught of applications that don=E2=80=99t quite fit the = sweet spots?=C2=A0

    The question that intrigues me: Is it possible to define something that is = as simple as JSL when you need just that, but allows dipping into the capab= ilities of something like CDDL where needed?

    By the way: You may not be aware of the WISHI activity we have in the T2TRG= (thing-to-thing research group) of the IRTF.=C2=A0 Here we look at modelin= g (not just for data) and at translating between different modeling approac= hes.=C2=A0 http://wishi.space if you want to have a look.

    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
    --000000000000fa62c80589fdfdf5-- From nobody Tue May 28 20:23: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 86DBA120075 for ; Tue, 28 May 2019 20:23:45 -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, HTML_MESSAGE=0.001, 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=textuality-com.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 o0W3atG85ayn for ; Tue, 28 May 2019 20:23:42 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 16BAE1200F6 for ; Tue, 28 May 2019 20:23:41 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id t184so1315309itf.2 for ; Tue, 28 May 2019 20:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WUBACIUKZ9FqYdcyrk1tGtNPX+IYvuQp8Gl8xlWCsb8=; b=Ugd0A6Q//58hMjf3mJms28OYQcpvD2qkCyX1dhANtVMx91MdLUb2GE2lNJXZKXDRC6 z05z9mDqcoEnTsWOoiLf7MyjtFvv435V0wvg3D3EM2rhm7mYQ42ZpIYX5JXOgH1yyzaA LhpKcPFn1WzdFBA2/b8hnT36mIuyB7ry6YTDg1O9qpb14Uzzy4KGx7B8ezrGvflTn0Ad 4GuoD7/jOxupeTGOyJm8y8FY2MjzdgYHabEsGAji4q8TRF4kf6yHYvEVVnDFA04TG5Rt VsFnpHaXOFL2Ccu4TTht4UEFu32vDXdmvhN16eJoFO0ddz1c1b2naGb/lGw+I/h8y/ip DTqg== 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=WUBACIUKZ9FqYdcyrk1tGtNPX+IYvuQp8Gl8xlWCsb8=; b=mkx37B8iUyyV+PDFGmmuM+1bF99E5Z9Bs8EeOzkYjT0YD3ydODUKo0m1SgZvs8UQqk I0c8m8ebttwneppV8BXairBtVgFTvJBb6+zUS57KBrOk03y9jPQKZ4uTcG7WAAwM3chj Lgqivsln8UktsDKWFljtj/xC/qkX8bIkuaWiPl3nalmPFR99JtlGFvPx10vOl7NiboKt 8et0mRGnW7LXrSngSOVy8DHW6Z3d3VBqvpNoIj6VeHxZlKfd4ZO7W0sogMQtFzSRs5ci B3VZoWuq4Y4TlrYPTdsPFYa02Ir7Wx/NEZiVHVGi53o/Pzs4TqujysfiBjWZiH9P/UVG fHWg== X-Gm-Message-State: APjAAAW6cwquPCDwzjTY5if4MXoHjMN71MDurqorlIlfS64Ip0ZhoJoj GM5JM4y1BlD/W6MWiMbjZHgtiG2n1A+pFuBebyu3FA== X-Google-Smtp-Source: APXvYqwL1fK0uacVEzVMPW5hyvQujIIrqk15Gpml0VMMOHrMxxEbTrZjnN4s4uypPVabPKB/cvi7NeJ88A3qrK/vA5s= X-Received: by 2002:a24:7b11:: with SMTP id q17mr5658984itc.49.1559100221134; Tue, 28 May 2019 20:23:41 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> In-Reply-To: From: Tim Bray Date: Tue, 28 May 2019 20:23:29 -0700 Message-ID: To: Rob Sayre Cc: Carsten Bormann , JSON WG , Ulysse Carion Content-Type: multipart/alternative; boundary="000000000000d9afe30589fe4eed" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 03:23:46 -0000 --000000000000d9afe30589fe4eed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What do you mean by =E2=80=9COutput specification=E2=80=9D? On Tue, May 28, 2019 at 8:01 PM Rob Sayre wrote: > I'm not sure this schema language will be productive as a source format i= n > the long term, but I don't think it will be harmful. So, it's not worth a= n > objection. The worst case would be that servers claim to conform to this > schema language, but fail to serve schema-conformant JSON in practice. Th= is > seems like the likely outcome, in the absence of an output specification. > > I have to say, I think I am uniquely qualified to raise this point. I > objected to the original JSON Stringify specification, which was somethin= g > pretty close to string concatenation, and got it corrected to something > close to its current form. > > If a schema language doesn't provide an output specification, it's > probably not going to work in practice. Best case, it's a standards > checkbox. > > - Rob > > > On Tue, May 28, 2019 at 7:41 PM Tim Bray wrote: > >> So Carsten, I am a person who would benefit from a super-simple JSON >> schema langauge; in effect, something like JSL + enums + timestamps. >> Furthermore, as I've said, I'm willing to invest some IETF-work cycles t= o >> get such a thing, in the event we could interest the community. Do you >> think that doing such a JSL and defining it using established CDDL >> semantics might be a good idea? >> >> Alternately, might we retain CDDL syntax and define a profile/subset >> which would be appropriate for us JSON-only simpletons? >> >> I'm not terribly fussy about mechanisms. >> >> >> >> On Fri, May 10, 2019 at 12:16 AM Carsten Bormann wrote: >> >>> On May 10, 2019, at 05:55, Ulysse Carion wrote: >>> > >>> > Carsten, >>> > >>> > Do you think that our difference in opinion on CDDL vs JSON Schema >>> > Language may be attributable to a difference in requirements? >>> >>> Hi Ulysse, >>> >>> I=E2=80=99m not even sure we disagree. That was why I became intereste= d in >>> converting between JSL and CDDL. As I was trying to show, CDDL might m= ake >>> a fine presentation language for JSL, and JSL might be a nice =E2=80=9C= profile=E2=80=9D for >>> CDDL that is very simple to process. >>> >>> > It seems to me that your use-case is centered around defining >>> > standards and other complex data requirements. CDDL is, in my view, >>> > unquestionably a better choice for this use-case. In my mind, CDDL is >>> > ABNF for CBOR, and that is undeniably what standards dealing with CBO= R >>> > or its near-equivalents require. The existing references, from RFCs, >>> > to CDDL are testament to this. >>> >>> Yes, you are describing the intention correctly. I would add that CDDL >>> has proven as useful for describing pure JSON protocols as for CBOR. >>> >>> Not all JSON/CBOR protocols need the full capabilities of CDDL. For >>> instance, the example in the CDDL spec for RFC 7071 could easily be >>> expressed in JSL, except for two details: reputation-object is not mean= t to >>> be extensible (reputon is), and there are some value constraints (some >>> values are integers). >>> >>> > But I (and I suspect Tim) am more preoccupied solely with defining th= e >>> > mundane sorts of messages that come out of JSON event processing and >>> > repetitive JSON APIs. Tim has blogged (see link in my original email) >>> > about dealing with AWS's CloudWatch events. That's messages that look >>> > like this: >>> > >>> > >>> https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.h= tml >>> > >>> > Tons of messages, and frequently being added and updated. But none of >>> > these messages are particularly exciting from a schema perspective. >>> >>> Well, I just had a look at (randomly selected) >>> >>> https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.h= tml#health-event-types >>> You=E2=80=99d need to add enumerations to JSL. There are also timestam= ps in the >>> object (ironically in two different formats). There is a table that ma= ps >>> language tags to messages in that language. (And the second and third >>> example have a missing bracket.) But I can=E2=80=99t really say, becau= se the >>> description by example only just begins to expose the actual intention. >>> >>> > CDDL can do much more than is necessary for merely representing >>> > CloudWatch events. This may seem like a good thing, but such excess >>> > capability reduces the suitability of the solution. JSON Schema >>> > Language is intentionally small and scuttled in scope, so as to >>> > simplify code and UI generation. By being so limited in scope, JSON >>> > Schema Language fits more easily into the architecture of a system >>> > that would like to integrate it. >>> >>> I=E2=80=99ve seen my share of developments that start simple. How much >>> functionality will be added to JSL before it becomes a standard? Also,= the >>> law of extensibility tells us it will be extended even after becoming a >>> standard. >>> >>> Of course, in its domain, CDDL is incredibly simple. Compare to JCR: >>> JCR is about three times as complex as CDDL. This is because CDDL was >>> built from a few very simple building blocks, which combine nicely to >>> provide its functionality. JCR is more of an accretion of features, wh= ich >>> in sum can do most of what CDDL can do. >>> >>> But back to JSL and CDDL: >>> What I=E2=80=99m interested in is what are the sweet spots on this func= tionality >>> vs. complexity continuum. I think we have found two of these sweet spo= ts >>> (at least maybe after a little more calibration). Now how do we handle= the >>> onslaught of applications that don=E2=80=99t quite fit the sweet spots? >>> >>> The question that intrigues me: Is it possible to define something that >>> is as simple as JSL when you need just that, but allows dipping into th= e >>> capabilities of something like CDDL where needed? >>> >>> By the way: You may not be aware of the WISHI activity we have in the >>> T2TRG (thing-to-thing research group) of the IRTF. Here we look at >>> modeling (not just for data) and at translating between different model= ing >>> approaches. http://wishi.space if you want to have a look. >>> >>> 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 >> > --000000000000d9afe30589fe4eed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Wha= t do you mean by =E2=80=9COutput specification=E2=80=9D?

    On Tue, May 2= 8, 2019 at 8:01 PM Rob Sayre <sayrer= @gmail.com> wrote:
    I'm not sure this schema language will= be productive as a source format in the long term, but I don't think i= t will be harmful. So, it's not worth an objection. The worst case woul= d be that servers claim to conform to this schema language, but fail to ser= ve schema-conformant JSON in practice. This seems like the likely outcome, = in the absence of an output specification.

    I have = to say, I think I am uniquely qualified to raise this point. I objected to = the original JSON Stringify specification, which was something pretty close= to string concatenation, and got it corrected to something close to its cu= rrent form.

    If a schema language doesn't provi= de an output specification, it's probably not going to work in practice= . Best case, it's a standards checkbox.

    - Rob<= /div>


    On Tue, May 28, 2019 at 7:41 PM Tim Bray <tbray@textuality.com>= ; wrote:
    So Carsten= , I am a person who would benefit from a super-simple JSON schema langauge;= in effect, something like JSL=C2=A0+ enums=C2=A0+ timestamps.=C2=A0 Furthe= rmore, as I've said, I'm willing to invest some IETF-work cycles to= get such a thing, in the event we could interest the community.=C2=A0 Do y= ou think that doing such a JSL and defining it using established CDDL seman= tics might be a good idea?=C2=A0=C2=A0

    Alternately, might we retain CDDL syntax and define a profile= /subset which would be appropriate for us JSON-only simpletons?

    I'm not terribly fussy about mec= hanisms.


    =
    On Fri= , May 10, 2019 at 12:16 AM Carsten Bormann <cabo@tzi.org> wrote:
    On May 10, 2019, at 05:55, Ulysse Carion = <ulysse@segment.= com> wrote:
    >
    > Carsten,
    >
    > Do you think that our difference in opinion on CDDL vs JSON Schema
    > Language may be attributable to a difference in requirements?

    Hi Ulysse,

    I=E2=80=99m not even sure we disagree.=C2=A0 That was why I became interest= ed in converting between JSL and CDDL.=C2=A0 As I was trying to show, CDDL = might make a fine presentation language for JSL, and JSL might be a nice = =E2=80=9Cprofile=E2=80=9D for CDDL that is very simple to process.

    > It seems to me that your use-case is centered around defining
    > standards and other complex data requirements. CDDL is, in my view, > unquestionably a better choice for this use-case. In my mind, CDDL is<= br> > ABNF for CBOR, and that is undeniably what standards dealing with CBOR=
    > or its near-equivalents require. The existing references, from RFCs, > to CDDL are testament to this.

    Yes, you are describing the intention correctly.=C2=A0 I would add that CDD= L has proven as useful for describing pure JSON protocols as for CBOR.=C2= =A0

    Not all JSON/CBOR protocols need the full capabilities of CDDL.=C2=A0 For i= nstance, the example in the CDDL spec for RFC 7071 could easily be expresse= d in JSL, except for two details: reputation-object is not meant to be exte= nsible (reputon is), and there are some value constraints (some values are = integers).

    > But I (and I suspect Tim) am more preoccupied solely with defining the=
    > mundane sorts of messages that come out of JSON event processing and > repetitive JSON APIs. Tim has blogged (see link in my original email)<= br> > about dealing with AWS's CloudWatch events. That's messages th= at look
    > like this:
    >
    > https://docs.aws.amaz= on.com/AmazonCloudWatch/latest/events/EventTypes.html
    >
    > Tons of messages, and frequently being added and updated. But none of<= br> > these messages are particularly exciting from a schema perspective.
    Well, I just had a look at (randomly selected)
    https:/= /docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#health-= event-types
    You=E2=80=99d need to add enumerations to JSL.=C2=A0 There are also timesta= mps in the object (ironically in two different formats).=C2=A0 There is a t= able that maps language tags to messages in that language.=C2=A0 (And the s= econd and third example have a missing bracket.)=C2=A0 But I can=E2=80=99t = really say, because the description by example only just begins to expose t= he actual intention.

    > CDDL can do much more than is necessary for merely representing
    > CloudWatch events. This may seem like a good thing, but such excess > capability reduces the suitability of the solution. JSON Schema
    > Language is intentionally small and scuttled in scope, so as to
    > simplify code and UI generation. By being so limited in scope, JSON > Schema Language fits more easily into the architecture of a system
    > that would like to integrate it.

    I=E2=80=99ve seen my share of developments that start simple.=C2=A0 How muc= h functionality will be added to JSL before it becomes a standard?=C2=A0 Al= so, the law of extensibility tells us it will be extended even after becomi= ng a standard.

    Of course, in its domain, CDDL is incredibly simple.=C2=A0 Compare to JCR: = JCR is about three times as complex as CDDL.=C2=A0 This is because CDDL was= built from a few very simple building blocks, which combine nicely to prov= ide its functionality.=C2=A0 JCR is more of an accretion of features, which= in sum can do most of what CDDL can do.

    But back to JSL and CDDL:
    What I=E2=80=99m interested in is what are the sweet spots on this function= ality vs. complexity continuum.=C2=A0 I think we have found two of these sw= eet spots (at least maybe after a little more calibration).=C2=A0 Now how d= o we handle the onslaught of applications that don=E2=80=99t quite fit the = sweet spots?=C2=A0

    The question that intrigues me: Is it possible to define something that is = as simple as JSL when you need just that, but allows dipping into the capab= ilities of something like CDDL where needed?

    By the way: You may not be aware of the WISHI activity we have in the T2TRG= (thing-to-thing research group) of the IRTF.=C2=A0 Here we look at modelin= g (not just for data) and at translating between different modeling approac= hes.=C2=A0 http://wishi.space if you want to have a look.

    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
    --000000000000d9afe30589fe4eed-- From nobody Tue May 28 20:40: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 A7EF21200FE for ; Tue, 28 May 2019 20:40:46 -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=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 sIWcfRar3TBc for ; Tue, 28 May 2019 20:40:43 -0700 (PDT) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 5D113120044 for ; Tue, 28 May 2019 20:40:43 -0700 (PDT) Received: by mail-it1-x134.google.com with SMTP id h11so1295936itf.5 for ; Tue, 28 May 2019 20:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IQ2bl1l8H8nIOcii+KhIHK6VKsi6iRkNneeNwoRLfqg=; b=FqT7KsTYF94UhqUHBOD6bqy+cEW3v4/eFcGknuEHFvWCZaFQgOsBW4hWk5LkabZlWN XtEmZoSd2t5xdqnyr1N/MHZAwwNOaolcEGEFRpGpywO3MD+JerKnePwAg8lLhzmXqCFa XsEo+pMPqZ3LUMKfDhBJuPsjCmwqarpbNMovqWBMhkRiFrMs92W/CxMr2g9gClKN2XrH woZDZ30gX1uiDMp3vQ8pCCf19rLg5gD44CU0usR5aYyDdGH1GAZJakYDcYQBsrheN7CH 7kaukgPZBaN6gTX3ZA8Tdjyv6O+GYcBBOEkQKDcsubF6k4YTs+zPJFhlnxvlUVxoqoId tHrQ== 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=IQ2bl1l8H8nIOcii+KhIHK6VKsi6iRkNneeNwoRLfqg=; b=W5ZJuTThZhdJfb2T8+jh4pSKZz+mJgidJ3wBfmY77g3iXbWRnQZVJWUYk5PDsQIyRS JcTOdPiTIkk9MeMJLGy8bb3cducwFAYxMT0hyOXX1cBlaBhzHghskALWaLTCnQC+iC8e ZfnSMc1ohXkWZ2jxqw4/xGsYhWTCoqNIKbcqoW3BPsR5edIVM4ohGCmW0A5ZdhjSlWN2 Loaq2nePP9raqN0t8jDtZT+uDejXCI05MQ8KADwGWmksLaokCHsB4LPHB61Ke6V/XCS4 /xqFks3JXKu0NnbKT+3xRozU4l7unEK7JJ1WlgPgIt2bTZlr3lJ+RoIOB09CbBf3dfYd yWtA== X-Gm-Message-State: APjAAAWn1q3JwTwOxjqACGhBpmTQyz16Tk8W0FPkgcCqwraXELNsuEGf QmPGeGT8QEBBIO1bORd2OM6v/Ji0kJ47W+pQIBg= X-Google-Smtp-Source: APXvYqx/yvJ7uEy/67Zpz8gtRJSbI9fVEEfuRdtkjJvP/jetMLHB30NPVNHErr2VUDJvFvK5bZH80T56NhQCzEfhg/o= X-Received: by 2002:a05:660c:392:: with SMTP id x18mr5416177itj.89.1559101242404; Tue, 28 May 2019 20:40:42 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> In-Reply-To: From: Rob Sayre Date: Tue, 28 May 2019 20:40:30 -0700 Message-ID: To: Tim Bray Cc: Carsten Bormann , JSON WG , Ulysse Carion Content-Type: multipart/alternative; boundary="000000000000b8f2ca0589fe8bbc" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 03:40:47 -0000 --000000000000b8f2ca0589fe8bbc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 28, 2019 at 8:23 PM Tim Bray wrote: > What do you mean by =E2=80=9COutput specification=E2=80=9D? > Fair question. I'd say a good example might be the objects transferable across postMessage() in browser JavaScript. https://html.spec.whatwg.org/multipage/structured-data.html#transferable-ob= jects It seems like a deep problem at first, but it isn't. Those message formats add Date objects and a few other things, but not that much. - Rob > On Tue, May 28, 2019 at 8:01 PM Rob Sayre wrote: > >> I'm not sure this schema language will be productive as a source format >> in the long term, but I don't think it will be harmful. So, it's not wor= th >> an objection. The worst case would be that servers claim to conform to t= his >> schema language, but fail to serve schema-conformant JSON in practice. T= his >> seems like the likely outcome, in the absence of an output specification= . >> >> I have to say, I think I am uniquely qualified to raise this point. I >> objected to the original JSON Stringify specification, which was somethi= ng >> pretty close to string concatenation, and got it corrected to something >> close to its current form. >> >> If a schema language doesn't provide an output specification, it's >> probably not going to work in practice. Best case, it's a standards >> checkbox. >> >> - Rob >> >> >> On Tue, May 28, 2019 at 7:41 PM Tim Bray wrote: >> >>> So Carsten, I am a person who would benefit from a super-simple JSON >>> schema langauge; in effect, something like JSL + enums + timestamps. >>> Furthermore, as I've said, I'm willing to invest some IETF-work cycles = to >>> get such a thing, in the event we could interest the community. Do you >>> think that doing such a JSL and defining it using established CDDL >>> semantics might be a good idea? >>> >>> Alternately, might we retain CDDL syntax and define a profile/subset >>> which would be appropriate for us JSON-only simpletons? >>> >>> I'm not terribly fussy about mechanisms. >>> >>> >>> >>> On Fri, May 10, 2019 at 12:16 AM Carsten Bormann wrote: >>> >>>> On May 10, 2019, at 05:55, Ulysse Carion wrote: >>>> > >>>> > Carsten, >>>> > >>>> > Do you think that our difference in opinion on CDDL vs JSON Schema >>>> > Language may be attributable to a difference in requirements? >>>> >>>> Hi Ulysse, >>>> >>>> I=E2=80=99m not even sure we disagree. That was why I became interest= ed in >>>> converting between JSL and CDDL. As I was trying to show, CDDL might = make >>>> a fine presentation language for JSL, and JSL might be a nice =E2=80= =9Cprofile=E2=80=9D for >>>> CDDL that is very simple to process. >>>> >>>> > It seems to me that your use-case is centered around defining >>>> > standards and other complex data requirements. CDDL is, in my view, >>>> > unquestionably a better choice for this use-case. In my mind, CDDL i= s >>>> > ABNF for CBOR, and that is undeniably what standards dealing with CB= OR >>>> > or its near-equivalents require. The existing references, from RFCs, >>>> > to CDDL are testament to this. >>>> >>>> Yes, you are describing the intention correctly. I would add that CDD= L >>>> has proven as useful for describing pure JSON protocols as for CBOR. >>>> >>>> Not all JSON/CBOR protocols need the full capabilities of CDDL. For >>>> instance, the example in the CDDL spec for RFC 7071 could easily be >>>> expressed in JSL, except for two details: reputation-object is not mea= nt to >>>> be extensible (reputon is), and there are some value constraints (some >>>> values are integers). >>>> >>>> > But I (and I suspect Tim) am more preoccupied solely with defining t= he >>>> > mundane sorts of messages that come out of JSON event processing and >>>> > repetitive JSON APIs. Tim has blogged (see link in my original email= ) >>>> > about dealing with AWS's CloudWatch events. That's messages that loo= k >>>> > like this: >>>> > >>>> > >>>> https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.= html >>>> > >>>> > Tons of messages, and frequently being added and updated. But none o= f >>>> > these messages are particularly exciting from a schema perspective. >>>> >>>> Well, I just had a look at (randomly selected) >>>> >>>> https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.= html#health-event-types >>>> You=E2=80=99d need to add enumerations to JSL. There are also timesta= mps in >>>> the object (ironically in two different formats). There is a table th= at >>>> maps language tags to messages in that language. (And the second and = third >>>> example have a missing bracket.) But I can=E2=80=99t really say, beca= use the >>>> description by example only just begins to expose the actual intention= . >>>> >>>> > CDDL can do much more than is necessary for merely representing >>>> > CloudWatch events. This may seem like a good thing, but such excess >>>> > capability reduces the suitability of the solution. JSON Schema >>>> > Language is intentionally small and scuttled in scope, so as to >>>> > simplify code and UI generation. By being so limited in scope, JSON >>>> > Schema Language fits more easily into the architecture of a system >>>> > that would like to integrate it. >>>> >>>> I=E2=80=99ve seen my share of developments that start simple. How muc= h >>>> functionality will be added to JSL before it becomes a standard? Also= , the >>>> law of extensibility tells us it will be extended even after becoming = a >>>> standard. >>>> >>>> Of course, in its domain, CDDL is incredibly simple. Compare to JCR: >>>> JCR is about three times as complex as CDDL. This is because CDDL was >>>> built from a few very simple building blocks, which combine nicely to >>>> provide its functionality. JCR is more of an accretion of features, w= hich >>>> in sum can do most of what CDDL can do. >>>> >>>> But back to JSL and CDDL: >>>> What I=E2=80=99m interested in is what are the sweet spots on this >>>> functionality vs. complexity continuum. I think we have found two of = these >>>> sweet spots (at least maybe after a little more calibration). Now how= do >>>> we handle the onslaught of applications that don=E2=80=99t quite fit t= he sweet >>>> spots? >>>> >>>> The question that intrigues me: Is it possible to define something tha= t >>>> is as simple as JSL when you need just that, but allows dipping into t= he >>>> capabilities of something like CDDL where needed? >>>> >>>> By the way: You may not be aware of the WISHI activity we have in the >>>> T2TRG (thing-to-thing research group) of the IRTF. Here we look at >>>> modeling (not just for data) and at translating between different mode= ling >>>> approaches. http://wishi.space if you want to have a look. >>>> >>>> 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 >>> >> --000000000000b8f2ca0589fe8bbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Tue, May 28, 2019 at 8:23 PM Tim Bray = <tbray@textuality.com> wr= ote:
    What do you= mean by =E2=80=9COutput specification=E2=80=9D?

    Fair question. I'd say a good example might be the ob= jects transferable across postMessage() in browser JavaScript.

    It se= ems like a deep problem at first, but it isn't. Those message formats a= dd Date objects and a few other things, but not that much.

    - Rob



    =C2= =A0
    On Tue, May 28, 2019 at 8:= 01 PM Rob Sayre <s= ayrer@gmail.com> wrote:
    I'm not sure this schema language = will be productive as a source format in the long term, but I don't thi= nk it will be harmful. So, it's not worth an objection. The worst case = would be that servers claim to conform to this schema language, but fail to= serve schema-conformant JSON in practice. This seems like the likely outco= me, in the absence of an output specification.

    I h= ave to say, I think I am uniquely qualified to raise this point. I objected= to the original JSON Stringify specification, which was something pretty c= lose to string concatenation, and got it corrected to something close to it= s current form.

    If a schema language doesn't p= rovide an output specification, it's probably not going to work in prac= tice. Best case, it's a standards checkbox.

    - = Rob


    On Tue, May 28, 2019 at 7:41 PM Tim Bray <tbray@textuality.com> wrote:
    So Carsten, I am a person who = would benefit from a super-simple JSON schema langauge; in effect, somethin= g like JSL=C2=A0+ enums=C2=A0+ timestamps.=C2=A0 Furthermore, as I've s= aid, I'm willing to invest some IETF-work cycles to get such a thing, i= n the event we could interest the community.=C2=A0 Do you think that doing = such a JSL and defining it using established CDDL semantics might be a good= idea?=C2=A0=C2=A0

    Alternately, might we retain CDDL syntax and define a = profile/subset which would be appropriate for us JSON-only simpletons?

    I&= #39;m not terribly fussy about mechanisms.



    On Fri, May 10, 2019= at 12:16 AM Carsten Bormann <cabo@tzi.org> wrote:
    On May 10, 2019, at 05:55, Ulysse Carion <ulysse@segment.com> wr= ote:
    >
    > Carsten,
    >
    > Do you think that our difference in opinion on CDDL vs JSON Schema
    > Language may be attributable to a difference in requirements?

    Hi Ulysse,

    I=E2=80=99m not even sure we disagree.=C2=A0 That was why I became interest= ed in converting between JSL and CDDL.=C2=A0 As I was trying to show, CDDL = might make a fine presentation language for JSL, and JSL might be a nice = =E2=80=9Cprofile=E2=80=9D for CDDL that is very simple to process.

    > It seems to me that your use-case is centered around defining
    > standards and other complex data requirements. CDDL is, in my view, > unquestionably a better choice for this use-case. In my mind, CDDL is<= br> > ABNF for CBOR, and that is undeniably what standards dealing with CBOR=
    > or its near-equivalents require. The existing references, from RFCs, > to CDDL are testament to this.

    Yes, you are describing the intention correctly.=C2=A0 I would add that CDD= L has proven as useful for describing pure JSON protocols as for CBOR.=C2= =A0

    Not all JSON/CBOR protocols need the full capabilities of CDDL.=C2=A0 For i= nstance, the example in the CDDL spec for RFC 7071 could easily be expresse= d in JSL, except for two details: reputation-object is not meant to be exte= nsible (reputon is), and there are some value constraints (some values are = integers).

    > But I (and I suspect Tim) am more preoccupied solely with defining the=
    > mundane sorts of messages that come out of JSON event processing and > repetitive JSON APIs. Tim has blogged (see link in my original email)<= br> > about dealing with AWS's CloudWatch events. That's messages th= at look
    > like this:
    >
    > https://docs.aws.amaz= on.com/AmazonCloudWatch/latest/events/EventTypes.html
    >
    > Tons of messages, and frequently being added and updated. But none of<= br> > these messages are particularly exciting from a schema perspective.
    Well, I just had a look at (randomly selected)
    https:/= /docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#health-= event-types
    You=E2=80=99d need to add enumerations to JSL.=C2=A0 There are also timesta= mps in the object (ironically in two different formats).=C2=A0 There is a t= able that maps language tags to messages in that language.=C2=A0 (And the s= econd and third example have a missing bracket.)=C2=A0 But I can=E2=80=99t = really say, because the description by example only just begins to expose t= he actual intention.

    > CDDL can do much more than is necessary for merely representing
    > CloudWatch events. This may seem like a good thing, but such excess > capability reduces the suitability of the solution. JSON Schema
    > Language is intentionally small and scuttled in scope, so as to
    > simplify code and UI generation. By being so limited in scope, JSON > Schema Language fits more easily into the architecture of a system
    > that would like to integrate it.

    I=E2=80=99ve seen my share of developments that start simple.=C2=A0 How muc= h functionality will be added to JSL before it becomes a standard?=C2=A0 Al= so, the law of extensibility tells us it will be extended even after becomi= ng a standard.

    Of course, in its domain, CDDL is incredibly simple.=C2=A0 Compare to JCR: = JCR is about three times as complex as CDDL.=C2=A0 This is because CDDL was= built from a few very simple building blocks, which combine nicely to prov= ide its functionality.=C2=A0 JCR is more of an accretion of features, which= in sum can do most of what CDDL can do.

    But back to JSL and CDDL:
    What I=E2=80=99m interested in is what are the sweet spots on this function= ality vs. complexity continuum.=C2=A0 I think we have found two of these sw= eet spots (at least maybe after a little more calibration).=C2=A0 Now how d= o we handle the onslaught of applications that don=E2=80=99t quite fit the = sweet spots?=C2=A0

    The question that intrigues me: Is it possible to define something that is = as simple as JSL when you need just that, but allows dipping into the capab= ilities of something like CDDL where needed?

    By the way: You may not be aware of the WISHI activity we have in the T2TRG= (thing-to-thing research group) of the IRTF.=C2=A0 Here we look at modelin= g (not just for data) and at translating between different modeling approac= hes.=C2=A0 http://wishi.space if you want to have a look.

    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
    --000000000000b8f2ca0589fe8bbc-- From nobody Tue May 28 20:47:35 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 CA5791200FE for ; Tue, 28 May 2019 20:47:33 -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, HTML_MESSAGE=0.001, 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=textuality-com.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 cELrPAoIvXTy for ; Tue, 28 May 2019 20:47:29 -0700 (PDT) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (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 32F13120075 for ; Tue, 28 May 2019 20:47:29 -0700 (PDT) Received: by mail-io1-xd41.google.com with SMTP id w25so594452ioc.8 for ; Tue, 28 May 2019 20:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZyUIuDQjaGcLHv1v3I91M806/jjzOpRRBvrXk9q6FJI=; b=IilZ75OBQE+hIDjJv6/H7zza5VSbm74iQFrldkIAdCVD6VY7G13/8ZT5rqNtSofoyf x3qk06uEQrE/pJCtHaCwaY4rieMIBOGkWVHKbIwHt15w7a7RC5cNjI5BusSzEvnxg94O r5e9NQsKFgUjzNsHBtSHisCZbQo3YZpyOP06uBJIz1TRcn8achl8ENl6sUIc1jGDXeYi V7LyoAIQa8onB8JxwmoP2Px/SpDCIyzpCfbTyEzxJsnVvce+1HFWuVf+eJybCChMLgtO ayf7/GhhlMx78J+E7iq0tK/ptfn8w3H9PgWUX+QC00AvLfqHVrYMq/h6K8YcpMxsIlP+ Hy6Q== 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=ZyUIuDQjaGcLHv1v3I91M806/jjzOpRRBvrXk9q6FJI=; b=ciWEEEoAkAlnqeFO0tYC67vHUA4QblDB45HJ+LRBxG9XTiHs5G59lr0HX55jeCYNoi gmMWiTSBzzAbTFq+Sf1D8KqTSiiah5hQBVSAKI/FOk4fXp1xle7Gmm5T9rwP/snS3l6A OD8LnxNgxkY0ST1tgaBc4z4vIYDOl8VtMi/Bht5s05Ig+SeHbyuSRJEJuvRlJ+0Bobfs mhXEiIYT6my+L+/nh75Jy4hOSxDAybXY5QWefg3IaREHYwVEPRHdhQJRj6JxbxcaKIaF l8kjFvMX9kCUK1zWANb4We32kEEt4tP3FI3IsaxT08C4uyOcfdWFiJ5I+B0KoJvgqAK9 ETDA== X-Gm-Message-State: APjAAAVZiQ6/5ve+H0Q7aIZ19YoRHLE14GAEzW01TgOaRVIZhCbScrr3 5lmCU6wvKE7CJZhymwqO8bFqxSKhG3esMl9YDH2J2w== X-Google-Smtp-Source: APXvYqxpDvf9I0dxxq7aRqX6R3srYNCzDXStaCxLjM9qFpWgmWaFO/P5uRpJuJkS66YIIhYFX+YGL8EtKrVm1yREino= X-Received: by 2002:a05:6602:211a:: with SMTP id x26mr1250259iox.202.1559101648332; Tue, 28 May 2019 20:47:28 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> In-Reply-To: From: Tim Bray Date: Tue, 28 May 2019 20:47:16 -0700 Message-ID: To: Rob Sayre Cc: Carsten Bormann , JSON WG , Ulysse Carion Content-Type: multipart/alternative; boundary="000000000000eafee40589fea364" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 03:47:34 -0000 --000000000000eafee40589fea364 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable TBH, what I want from a schema system is (a) useful error messages and (b) ability to drive code generation, classes and serializer/deserializers and so on. On Tue, May 28, 2019 at 8:40 PM Rob Sayre wrote: > On Tue, May 28, 2019 at 8:23 PM Tim Bray wrote: > >> What do you mean by =E2=80=9COutput specification=E2=80=9D? >> > > Fair question. I'd say a good example might be the objects transferable > across postMessage() in browser JavaScript. > > > https://html.spec.whatwg.org/multipage/structured-data.html#transferable-= objects > > It seems like a deep problem at first, but it isn't. Those message format= s > add Date objects and a few other things, but not that much. > > - Rob > > > > > >> On Tue, May 28, 2019 at 8:01 PM Rob Sayre wrote: >> >>> I'm not sure this schema language will be productive as a source format >>> in the long term, but I don't think it will be harmful. So, it's not wo= rth >>> an objection. The worst case would be that servers claim to conform to = this >>> schema language, but fail to serve schema-conformant JSON in practice. = This >>> seems like the likely outcome, in the absence of an output specificatio= n. >>> >>> I have to say, I think I am uniquely qualified to raise this point. I >>> objected to the original JSON Stringify specification, which was someth= ing >>> pretty close to string concatenation, and got it corrected to something >>> close to its current form. >>> >>> If a schema language doesn't provide an output specification, it's >>> probably not going to work in practice. Best case, it's a standards >>> checkbox. >>> >>> - Rob >>> >>> >>> On Tue, May 28, 2019 at 7:41 PM Tim Bray wrote: >>> >>>> So Carsten, I am a person who would benefit from a super-simple JSON >>>> schema langauge; in effect, something like JSL + enums + timestamps. >>>> Furthermore, as I've said, I'm willing to invest some IETF-work cycles= to >>>> get such a thing, in the event we could interest the community. Do yo= u >>>> think that doing such a JSL and defining it using established CDDL >>>> semantics might be a good idea? >>>> >>>> Alternately, might we retain CDDL syntax and define a profile/subset >>>> which would be appropriate for us JSON-only simpletons? >>>> >>>> I'm not terribly fussy about mechanisms. >>>> >>>> >>>> >>>> On Fri, May 10, 2019 at 12:16 AM Carsten Bormann wrote: >>>> >>>>> On May 10, 2019, at 05:55, Ulysse Carion wrote: >>>>> > >>>>> > Carsten, >>>>> > >>>>> > Do you think that our difference in opinion on CDDL vs JSON Schema >>>>> > Language may be attributable to a difference in requirements? >>>>> >>>>> Hi Ulysse, >>>>> >>>>> I=E2=80=99m not even sure we disagree. That was why I became interes= ted in >>>>> converting between JSL and CDDL. As I was trying to show, CDDL might= make >>>>> a fine presentation language for JSL, and JSL might be a nice =E2=80= =9Cprofile=E2=80=9D for >>>>> CDDL that is very simple to process. >>>>> >>>>> > It seems to me that your use-case is centered around defining >>>>> > standards and other complex data requirements. CDDL is, in my view, >>>>> > unquestionably a better choice for this use-case. In my mind, CDDL = is >>>>> > ABNF for CBOR, and that is undeniably what standards dealing with >>>>> CBOR >>>>> > or its near-equivalents require. The existing references, from RFCs= , >>>>> > to CDDL are testament to this. >>>>> >>>>> Yes, you are describing the intention correctly. I would add that >>>>> CDDL has proven as useful for describing pure JSON protocols as for C= BOR. >>>>> >>>>> Not all JSON/CBOR protocols need the full capabilities of CDDL. For >>>>> instance, the example in the CDDL spec for RFC 7071 could easily be >>>>> expressed in JSL, except for two details: reputation-object is not me= ant to >>>>> be extensible (reputon is), and there are some value constraints (som= e >>>>> values are integers). >>>>> >>>>> > But I (and I suspect Tim) am more preoccupied solely with defining >>>>> the >>>>> > mundane sorts of messages that come out of JSON event processing an= d >>>>> > repetitive JSON APIs. Tim has blogged (see link in my original emai= l) >>>>> > about dealing with AWS's CloudWatch events. That's messages that lo= ok >>>>> > like this: >>>>> > >>>>> > >>>>> https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes= .html >>>>> > >>>>> > Tons of messages, and frequently being added and updated. But none = of >>>>> > these messages are particularly exciting from a schema perspective. >>>>> >>>>> Well, I just had a look at (randomly selected) >>>>> >>>>> https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes= .html#health-event-types >>>>> You=E2=80=99d need to add enumerations to JSL. There are also timest= amps in >>>>> the object (ironically in two different formats). There is a table t= hat >>>>> maps language tags to messages in that language. (And the second and= third >>>>> example have a missing bracket.) But I can=E2=80=99t really say, bec= ause the >>>>> description by example only just begins to expose the actual intentio= n. >>>>> >>>>> > CDDL can do much more than is necessary for merely representing >>>>> > CloudWatch events. This may seem like a good thing, but such excess >>>>> > capability reduces the suitability of the solution. JSON Schema >>>>> > Language is intentionally small and scuttled in scope, so as to >>>>> > simplify code and UI generation. By being so limited in scope, JSON >>>>> > Schema Language fits more easily into the architecture of a system >>>>> > that would like to integrate it. >>>>> >>>>> I=E2=80=99ve seen my share of developments that start simple. How mu= ch >>>>> functionality will be added to JSL before it becomes a standard? Als= o, the >>>>> law of extensibility tells us it will be extended even after becoming= a >>>>> standard. >>>>> >>>>> Of course, in its domain, CDDL is incredibly simple. Compare to JCR: >>>>> JCR is about three times as complex as CDDL. This is because CDDL wa= s >>>>> built from a few very simple building blocks, which combine nicely to >>>>> provide its functionality. JCR is more of an accretion of features, = which >>>>> in sum can do most of what CDDL can do. >>>>> >>>>> But back to JSL and CDDL: >>>>> What I=E2=80=99m interested in is what are the sweet spots on this >>>>> functionality vs. complexity continuum. I think we have found two of= these >>>>> sweet spots (at least maybe after a little more calibration). Now ho= w do >>>>> we handle the onslaught of applications that don=E2=80=99t quite fit = the sweet >>>>> spots? >>>>> >>>>> The question that intrigues me: Is it possible to define something >>>>> that is as simple as JSL when you need just that, but allows dipping = into >>>>> the capabilities of something like CDDL where needed? >>>>> >>>>> By the way: You may not be aware of the WISHI activity we have in the >>>>> T2TRG (thing-to-thing research group) of the IRTF. Here we look at >>>>> modeling (not just for data) and at translating between different mod= eling >>>>> approaches. http://wishi.space if you want to have a look. >>>>> >>>>> 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 >>>> >>> --000000000000eafee40589fea364 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    TBH= , what I want from a schema system is (a) useful error messages and (b) abi= lity to drive code generation, classes and serializer/deserializers and so = on.=C2=A0=C2=A0

    On Tue, May 28, 2019 at 8:40 PM Rob Sayre <sayrer@gmail.com> wrote:
    On Tue, May 28, 2019 at 8:23 PM Tim Bray <tbray@textuality.com> wrote:
    What do you mean by =E2= =80=9COutput specification=E2=80=9D?

    Fair question. I'd say a good example might be the objects transf= erable across postMessage() in browser JavaScript.

    https://html.spec.whatwg.org/multipage= /structured-data.html#transferable-objects

    It seems like a deep problem at first, but it isn't. Those message for= mats add Date objects and a few other things, but not that much.
    =
    - Rob



    =C2=A0
    On Tue, May 28, 2019= at 8:01 PM Rob Sayre <sayrer@gmail.com> wrote:
    I'm not sure this schema lan= guage will be productive as a source format in the long term, but I don'= ;t think it will be harmful. So, it's not worth an objection. The worst= case would be that servers claim to conform to this schema language, but f= ail to serve schema-conformant JSON in practice. This seems like the likely= outcome, in the absence of an output specification.

    I have to say, I think I am uniquely qualified to raise this point. I ob= jected to the original JSON Stringify specification, which was something pr= etty close to string concatenation, and got it corrected to something close= to its current form.

    If a schema language doesn&#= 39;t provide an output specification, it's probably not going to work i= n practice. Best case, it's a standards checkbox.

    <= div>- Rob


    On Tue, May 28, 2019 at 7:41 PM Tim Bray <= tbray@textuality.= com> wrote:
    So Carsten, I am a perso= n who would benefit from a super-simple JSON schema langauge; in effect, so= mething like JSL=C2=A0+ enums=C2=A0+ timestamps.=C2=A0 Furthermore, as I= 9;ve said, I'm willing to invest some IETF-work cycles to get such a th= ing, in the event we could interest the community.=C2=A0 Do you think that = doing such a JSL and defining it using established CDDL semantics might be = a good idea?=C2=A0=C2=A0

    Alternately, might we retain CDDL syntax and def= ine a profile/subset which would be appropriate for us JSON-only simpletons= ?

    I'm not terribly fussy about mechanisms.



    On Fri, May 10= , 2019 at 12:16 AM Carsten Bormann <cabo@tzi.org> wrote:
    On May 10, 2019, at 05:55, Ulysse Carion <ulysse@segment.com&= gt; wrote:
    >
    > Carsten,
    >
    > Do you think that our difference in opinion on CDDL vs JSON Schema
    > Language may be attributable to a difference in requirements?

    Hi Ulysse,

    I=E2=80=99m not even sure we disagree.=C2=A0 That was why I became interest= ed in converting between JSL and CDDL.=C2=A0 As I was trying to show, CDDL = might make a fine presentation language for JSL, and JSL might be a nice = =E2=80=9Cprofile=E2=80=9D for CDDL that is very simple to process.

    > It seems to me that your use-case is centered around defining
    > standards and other complex data requirements. CDDL is, in my view, > unquestionably a better choice for this use-case. In my mind, CDDL is<= br> > ABNF for CBOR, and that is undeniably what standards dealing with CBOR=
    > or its near-equivalents require. The existing references, from RFCs, > to CDDL are testament to this.

    Yes, you are describing the intention correctly.=C2=A0 I would add that CDD= L has proven as useful for describing pure JSON protocols as for CBOR.=C2= =A0

    Not all JSON/CBOR protocols need the full capabilities of CDDL.=C2=A0 For i= nstance, the example in the CDDL spec for RFC 7071 could easily be expresse= d in JSL, except for two details: reputation-object is not meant to be exte= nsible (reputon is), and there are some value constraints (some values are = integers).

    > But I (and I suspect Tim) am more preoccupied solely with defining the=
    > mundane sorts of messages that come out of JSON event processing and > repetitive JSON APIs. Tim has blogged (see link in my original email)<= br> > about dealing with AWS's CloudWatch events. That's messages th= at look
    > like this:
    >
    > https://docs.aws.amaz= on.com/AmazonCloudWatch/latest/events/EventTypes.html
    >
    > Tons of messages, and frequently being added and updated. But none of<= br> > these messages are particularly exciting from a schema perspective.
    Well, I just had a look at (randomly selected)
    https:/= /docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#health-= event-types
    You=E2=80=99d need to add enumerations to JSL.=C2=A0 There are also timesta= mps in the object (ironically in two different formats).=C2=A0 There is a t= able that maps language tags to messages in that language.=C2=A0 (And the s= econd and third example have a missing bracket.)=C2=A0 But I can=E2=80=99t = really say, because the description by example only just begins to expose t= he actual intention.

    > CDDL can do much more than is necessary for merely representing
    > CloudWatch events. This may seem like a good thing, but such excess > capability reduces the suitability of the solution. JSON Schema
    > Language is intentionally small and scuttled in scope, so as to
    > simplify code and UI generation. By being so limited in scope, JSON > Schema Language fits more easily into the architecture of a system
    > that would like to integrate it.

    I=E2=80=99ve seen my share of developments that start simple.=C2=A0 How muc= h functionality will be added to JSL before it becomes a standard?=C2=A0 Al= so, the law of extensibility tells us it will be extended even after becomi= ng a standard.

    Of course, in its domain, CDDL is incredibly simple.=C2=A0 Compare to JCR: = JCR is about three times as complex as CDDL.=C2=A0 This is because CDDL was= built from a few very simple building blocks, which combine nicely to prov= ide its functionality.=C2=A0 JCR is more of an accretion of features, which= in sum can do most of what CDDL can do.

    But back to JSL and CDDL:
    What I=E2=80=99m interested in is what are the sweet spots on this function= ality vs. complexity continuum.=C2=A0 I think we have found two of these sw= eet spots (at least maybe after a little more calibration).=C2=A0 Now how d= o we handle the onslaught of applications that don=E2=80=99t quite fit the = sweet spots?=C2=A0

    The question that intrigues me: Is it possible to define something that is = as simple as JSL when you need just that, but allows dipping into the capab= ilities of something like CDDL where needed?

    By the way: You may not be aware of the WISHI activity we have in the T2TRG= (thing-to-thing research group) of the IRTF.=C2=A0 Here we look at modelin= g (not just for data) and at translating between different modeling approac= hes.=C2=A0 http://wishi.space if you want to have a look.

    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
    --000000000000eafee40589fea364-- From nobody Tue May 28 20:54: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 221D61200FE for ; Tue, 28 May 2019 20:54:47 -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=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 G79AVeYvinNK for ; Tue, 28 May 2019 20:54:43 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F52B120090 for ; Tue, 28 May 2019 20:54:43 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id m3so1413675itl.1 for ; Tue, 28 May 2019 20:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p57yF5BM+YdWIOlY3HJLumYcio4YXBobgMW+U6nXBWc=; b=MJP2tPEEysSoyZ0SLCm8AcTaz1R2a4WI/Img+gYEOG9pFXtRP3bvAi2lwWOK9DovaH Np87ZCodUwkgv0s/dQzxFJ8dvMBLhFgRKMQ/NGhmmAFM5uTnikwJ6Nr/qsPMaH51JWAC v0Y+XxtPedkM9nKPSTtO/j7BbqcV0tLo09nNgxWaLU7Cfh0vdyRx5+wmOm3SFyN6dhrB R+xTkz2SWStOgfOpgNtgeRyHQomN6/P/wG3m0CepqbbmQ04fVXt4dnqLDDmvFQtXp15C n7UiXIdZuqi109HUfsflOhEAwvqv9Pw3sCWglPe+BfuPYmBCHgpXf/9tFLFWLUUtPyNx RMGw== 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=p57yF5BM+YdWIOlY3HJLumYcio4YXBobgMW+U6nXBWc=; b=oWPM8uKHR6LV7PqqxFTgktqaMN+qAVlF8qrwtL5dRvNZkLEnRbWRFtgi85/dD3Zbqm RubfTNhqBKVLvCtLT2S9ZCszr4GQHMw7TcmCMLEKoWucBhLqVI3nrwvvRh0BMYOlkGFx K+hf2PHrtBbXIvRF+7nS4v2jECs66mR4nHKMJ5FC1rMgptEM/1dW71E5LWq0ngmXGJvI cnBB2GoqbhTSY9y+WnzJC34pPaBza/x4nkikUIKwLsBKa5mb3CIsGolMvo3lkcW1Gtjp FpnXYFAzlUmrhCN83H1a+lsb3SNt3/o6PvN9JAn8lg+sgOCPOHpTiS20YqC3xBA9Fmyh eexw== X-Gm-Message-State: APjAAAXZAl21a8TlH3GILoDMDymTPqLfXz7CRiukFLCnKcpn+v8xFaUg clb0dNxqD3ql09269fgG56K8E4LyAEVtRgczjhM= X-Google-Smtp-Source: APXvYqyD+wMPPI2J8fuh2Q/ZQa2Wp9cwqK0wKREW8hsmh5+fd1tKULhsB2w0+a8Ke17WWyLnkV6WTn8TXSM3+USkOcM= X-Received: by 2002:a05:660c:392:: with SMTP id x18mr5439294itj.89.1559102082245; Tue, 28 May 2019 20:54:42 -0700 (PDT) MIME-Version: 1.0 References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> In-Reply-To: From: Rob Sayre Date: Tue, 28 May 2019 20:54:30 -0700 Message-ID: To: Tim Bray Cc: Carsten Bormann , JSON WG , Ulysse Carion Content-Type: multipart/alternative; boundary="000000000000c7f60d0589febd92" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 03:54:47 -0000 --000000000000c7f60d0589febd92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 28, 2019 at 8:47 PM Tim Bray wrote: > TBH, what I want from a schema system is (a) useful error messages and (b= ) > ability to drive code generation, classes and serializer/deserializers an= d > so on. > No problem. If it can drive serializer/deserializers, let's spec out some conformance tests. - Rob > On Tue, May 28, 2019 at 8:40 PM Rob Sayre wrote: > >> On Tue, May 28, 2019 at 8:23 PM Tim Bray wrote: >> >>> What do you mean by =E2=80=9COutput specification=E2=80=9D? >>> >> >> Fair question. I'd say a good example might be the objects transferable >> across postMessage() in browser JavaScript. >> >> >> https://html.spec.whatwg.org/multipage/structured-data.html#transferable= -objects >> >> It seems like a deep problem at first, but it isn't. Those message >> formats add Date objects and a few other things, but not that much. >> >> - Rob >> >> >> >> >> >>> On Tue, May 28, 2019 at 8:01 PM Rob Sayre wrote: >>> >>>> I'm not sure this schema language will be productive as a source forma= t >>>> in the long term, but I don't think it will be harmful. So, it's not w= orth >>>> an objection. The worst case would be that servers claim to conform to= this >>>> schema language, but fail to serve schema-conformant JSON in practice.= This >>>> seems like the likely outcome, in the absence of an output specificati= on. >>>> >>>> I have to say, I think I am uniquely qualified to raise this point. I >>>> objected to the original JSON Stringify specification, which was somet= hing >>>> pretty close to string concatenation, and got it corrected to somethin= g >>>> close to its current form. >>>> >>>> If a schema language doesn't provide an output specification, it's >>>> probably not going to work in practice. Best case, it's a standards >>>> checkbox. >>>> >>>> - Rob >>>> >>>> >>>> On Tue, May 28, 2019 at 7:41 PM Tim Bray wrote: >>>> >>>>> So Carsten, I am a person who would benefit from a super-simple JSON >>>>> schema langauge; in effect, something like JSL + enums + timestamps. >>>>> Furthermore, as I've said, I'm willing to invest some IETF-work cycle= s to >>>>> get such a thing, in the event we could interest the community. Do y= ou >>>>> think that doing such a JSL and defining it using established CDDL >>>>> semantics might be a good idea? >>>>> >>>>> Alternately, might we retain CDDL syntax and define a profile/subset >>>>> which would be appropriate for us JSON-only simpletons? >>>>> >>>>> I'm not terribly fussy about mechanisms. >>>>> >>>>> >>>>> >>>>> On Fri, May 10, 2019 at 12:16 AM Carsten Bormann wrote= : >>>>> >>>>>> On May 10, 2019, at 05:55, Ulysse Carion wrote: >>>>>> > >>>>>> > Carsten, >>>>>> > >>>>>> > Do you think that our difference in opinion on CDDL vs JSON Schema >>>>>> > Language may be attributable to a difference in requirements? >>>>>> >>>>>> Hi Ulysse, >>>>>> >>>>>> I=E2=80=99m not even sure we disagree. That was why I became intere= sted in >>>>>> converting between JSL and CDDL. As I was trying to show, CDDL migh= t make >>>>>> a fine presentation language for JSL, and JSL might be a nice =E2=80= =9Cprofile=E2=80=9D for >>>>>> CDDL that is very simple to process. >>>>>> >>>>>> > It seems to me that your use-case is centered around defining >>>>>> > standards and other complex data requirements. CDDL is, in my view= , >>>>>> > unquestionably a better choice for this use-case. In my mind, CDDL >>>>>> is >>>>>> > ABNF for CBOR, and that is undeniably what standards dealing with >>>>>> CBOR >>>>>> > or its near-equivalents require. The existing references, from RFC= s, >>>>>> > to CDDL are testament to this. >>>>>> >>>>>> Yes, you are describing the intention correctly. I would add that >>>>>> CDDL has proven as useful for describing pure JSON protocols as for = CBOR. >>>>>> >>>>>> Not all JSON/CBOR protocols need the full capabilities of CDDL. For >>>>>> instance, the example in the CDDL spec for RFC 7071 could easily be >>>>>> expressed in JSL, except for two details: reputation-object is not m= eant to >>>>>> be extensible (reputon is), and there are some value constraints (so= me >>>>>> values are integers). >>>>>> >>>>>> > But I (and I suspect Tim) am more preoccupied solely with defining >>>>>> the >>>>>> > mundane sorts of messages that come out of JSON event processing a= nd >>>>>> > repetitive JSON APIs. Tim has blogged (see link in my original >>>>>> email) >>>>>> > about dealing with AWS's CloudWatch events. That's messages that >>>>>> look >>>>>> > like this: >>>>>> > >>>>>> > >>>>>> https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventType= s.html >>>>>> > >>>>>> > Tons of messages, and frequently being added and updated. But none >>>>>> of >>>>>> > these messages are particularly exciting from a schema perspective= . >>>>>> >>>>>> Well, I just had a look at (randomly selected) >>>>>> >>>>>> https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventType= s.html#health-event-types >>>>>> You=E2=80=99d need to add enumerations to JSL. There are also times= tamps in >>>>>> the object (ironically in two different formats). There is a table = that >>>>>> maps language tags to messages in that language. (And the second an= d third >>>>>> example have a missing bracket.) But I can=E2=80=99t really say, be= cause the >>>>>> description by example only just begins to expose the actual intenti= on. >>>>>> >>>>>> > CDDL can do much more than is necessary for merely representing >>>>>> > CloudWatch events. This may seem like a good thing, but such exces= s >>>>>> > capability reduces the suitability of the solution. JSON Schema >>>>>> > Language is intentionally small and scuttled in scope, so as to >>>>>> > simplify code and UI generation. By being so limited in scope, JSO= N >>>>>> > Schema Language fits more easily into the architecture of a system >>>>>> > that would like to integrate it. >>>>>> >>>>>> I=E2=80=99ve seen my share of developments that start simple. How m= uch >>>>>> functionality will be added to JSL before it becomes a standard? Al= so, the >>>>>> law of extensibility tells us it will be extended even after becomin= g a >>>>>> standard. >>>>>> >>>>>> Of course, in its domain, CDDL is incredibly simple. Compare to JCR= : >>>>>> JCR is about three times as complex as CDDL. This is because CDDL w= as >>>>>> built from a few very simple building blocks, which combine nicely t= o >>>>>> provide its functionality. JCR is more of an accretion of features,= which >>>>>> in sum can do most of what CDDL can do. >>>>>> >>>>>> But back to JSL and CDDL: >>>>>> What I=E2=80=99m interested in is what are the sweet spots on this >>>>>> functionality vs. complexity continuum. I think we have found two o= f these >>>>>> sweet spots (at least maybe after a little more calibration). Now h= ow do >>>>>> we handle the onslaught of applications that don=E2=80=99t quite fit= the sweet >>>>>> spots? >>>>>> >>>>>> The question that intrigues me: Is it possible to define something >>>>>> that is as simple as JSL when you need just that, but allows dipping= into >>>>>> the capabilities of something like CDDL where needed? >>>>>> >>>>>> By the way: You may not be aware of the WISHI activity we have in th= e >>>>>> T2TRG (thing-to-thing research group) of the IRTF. Here we look at >>>>>> modeling (not just for data) and at translating between different mo= deling >>>>>> approaches. http://wishi.space if you want to have a look. >>>>>> >>>>>> 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 >>>>> >>>> --000000000000c7f60d0589febd92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Tue, May 28, 2019 at 8:47 PM Tim Bray = <tbray@textuality.com> wr= ote:
    TBH, what I= want from a schema system is (a) useful error messages and (b) ability to = drive code generation, classes and serializer/deserializers and so on.=C2= =A0=C2=A0

    No problem. If it can= drive=C2=A0serializer/deserializers, let's spec out some conformance t= ests.

    - Rob
    =C2=A0
    On Tue, May 28, 2019 at 8:40 PM Rob Sayre <sayrer@gmail.com> w= rote:
    On Tue, May 28, 2019 at 8:23 PM Tim Bray <tbray@textuality.com<= /a>> wrote:

    Fair question. I'd say a good example might= be the objects transferable across postMessage() in browser JavaScript.

    https://html.spe= c.whatwg.org/multipage/structured-data.html#transferable-objects

    It seems like a deep problem at first, but it isn= 9;t. Those message formats add Date objects and a few other things, but not= that much.

    - Rob



    =C2=A0
    On Tue, May 28, 2019 at 8:01 PM Rob Sayre <sayrer@gmail.com> wrote:
    I'm not= sure this schema language will be productive as a source format in the lon= g term, but I don't think it will be harmful. So, it's not worth an= objection. The worst case would be that servers claim to conform to this s= chema language, but fail to serve schema-conformant JSON in practice. This = seems like the likely outcome, in the absence of an output specification.

    I have to say, I think I am uniquely qualified to r= aise this point. I objected to the original JSON Stringify specification, w= hich was something pretty close to string concatenation, and got it correct= ed to something close to its current form.

    If a sc= hema language doesn't provide an output specification, it's probabl= y not going to work in practice. Best case, it's a standards checkbox.<= /div>

    - Rob


    On Tue, May 28, 2019 at = 7:41 PM Tim Bray <tbray@textuality.com> wrote:
    So = Carsten, I am a person who would benefit from a super-simple JSON schema la= ngauge; in effect, something like JSL=C2=A0+ enums=C2=A0+ timestamps.=C2=A0= Furthermore, as I've said, I'm willing to invest some IETF-work cy= cles to get such a thing, in the event we could interest the community.=C2= =A0 Do you think that doing such a JSL and defining it using established CD= DL semantics might be a good idea?=C2=A0=C2=A0

    Alternately, might we reta= in CDDL syntax and define a profile/subset which would be appropriate for u= s JSON-only simpletons?

    I'm not terribly fussy about mechanisms.


    On Fri, May 10, 2019 at 12:16 AM Carsten Bormann <cabo@tzi.org> wrote:
    On May 10, 2019, at 05:55, = Ulysse Carion <u= lysse@segment.com> wrote:
    >
    > Carsten,
    >
    > Do you think that our difference in opinion on CDDL vs JSON Schema
    > Language may be attributable to a difference in requirements?

    Hi Ulysse,

    I=E2=80=99m not even sure we disagree.=C2=A0 That was why I became interest= ed in converting between JSL and CDDL.=C2=A0 As I was trying to show, CDDL = might make a fine presentation language for JSL, and JSL might be a nice = =E2=80=9Cprofile=E2=80=9D for CDDL that is very simple to process.

    > It seems to me that your use-case is centered around defining
    > standards and other complex data requirements. CDDL is, in my view, > unquestionably a better choice for this use-case. In my mind, CDDL is<= br> > ABNF for CBOR, and that is undeniably what standards dealing with CBOR=
    > or its near-equivalents require. The existing references, from RFCs, > to CDDL are testament to this.

    Yes, you are describing the intention correctly.=C2=A0 I would add that CDD= L has proven as useful for describing pure JSON protocols as for CBOR.=C2= =A0

    Not all JSON/CBOR protocols need the full capabilities of CDDL.=C2=A0 For i= nstance, the example in the CDDL spec for RFC 7071 could easily be expresse= d in JSL, except for two details: reputation-object is not meant to be exte= nsible (reputon is), and there are some value constraints (some values are = integers).

    > But I (and I suspect Tim) am more preoccupied solely with defining the=
    > mundane sorts of messages that come out of JSON event processing and > repetitive JSON APIs. Tim has blogged (see link in my original email)<= br> > about dealing with AWS's CloudWatch events. That's messages th= at look
    > like this:
    >
    > https://docs.aws.amaz= on.com/AmazonCloudWatch/latest/events/EventTypes.html
    >
    > Tons of messages, and frequently being added and updated. But none of<= br> > these messages are particularly exciting from a schema perspective.
    Well, I just had a look at (randomly selected)
    https:/= /docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#health-= event-types
    You=E2=80=99d need to add enumerations to JSL.=C2=A0 There are also timesta= mps in the object (ironically in two different formats).=C2=A0 There is a t= able that maps language tags to messages in that language.=C2=A0 (And the s= econd and third example have a missing bracket.)=C2=A0 But I can=E2=80=99t = really say, because the description by example only just begins to expose t= he actual intention.

    > CDDL can do much more than is necessary for merely representing
    > CloudWatch events. This may seem like a good thing, but such excess > capability reduces the suitability of the solution. JSON Schema
    > Language is intentionally small and scuttled in scope, so as to
    > simplify code and UI generation. By being so limited in scope, JSON > Schema Language fits more easily into the architecture of a system
    > that would like to integrate it.

    I=E2=80=99ve seen my share of developments that start simple.=C2=A0 How muc= h functionality will be added to JSL before it becomes a standard?=C2=A0 Al= so, the law of extensibility tells us it will be extended even after becomi= ng a standard.

    Of course, in its domain, CDDL is incredibly simple.=C2=A0 Compare to JCR: = JCR is about three times as complex as CDDL.=C2=A0 This is because CDDL was= built from a few very simple building blocks, which combine nicely to prov= ide its functionality.=C2=A0 JCR is more of an accretion of features, which= in sum can do most of what CDDL can do.

    But back to JSL and CDDL:
    What I=E2=80=99m interested in is what are the sweet spots on this function= ality vs. complexity continuum.=C2=A0 I think we have found two of these sw= eet spots (at least maybe after a little more calibration).=C2=A0 Now how d= o we handle the onslaught of applications that don=E2=80=99t quite fit the = sweet spots?=C2=A0

    The question that intrigues me: Is it possible to define something that is = as simple as JSL when you need just that, but allows dipping into the capab= ilities of something like CDDL where needed?

    By the way: You may not be aware of the WISHI activity we have in the T2TRG= (thing-to-thing research group) of the IRTF.=C2=A0 Here we look at modelin= g (not just for data) and at translating between different modeling approac= hes.=C2=A0 http://wishi.space if you want to have a look.

    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
    --000000000000c7f60d0589febd92-- From nobody Wed May 29 02:40:51 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 CD018120148 for ; Wed, 29 May 2019 02:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 3oS4fnS1SsWs for ; Wed, 29 May 2019 02:40:47 -0700 (PDT) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39FF1200EF for ; Wed, 29 May 2019 02:40:46 -0700 (PDT) Received: (qmail 2462 invoked from network); 29 May 2019 10:38:45 +0100 Received: from host86-174-116-175.range86-174.btcentralplus.com (HELO ?192.168.1.72?) (86.174.116.175) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 29 May 2019 10:38:44 +0100 To: Tim Bray , Carsten Bormann Cc: JSON WG , Ulysse Carion References: <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> From: Pete Cordell Message-ID: <4fda0427-8d61-60b5-4a30-12a39ce0aad9@codalogic.com> Date: Wed, 29 May 2019 10:40:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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 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, 29 May 2019 09:40:50 -0000 On 29/05/2019 03:40, Tim Bray wrote: > So Carsten, I am a person who would benefit from a super-simple JSON > schema langauge; in effect, something like JSL + enums + timestamps. > Furthermore, as I've said, I'm willing to invest some IETF-work cycles > to get such a thing, in the event we could interest the community.  Do > you think that doing such a JSL and defining it using established CDDL > semantics might be a good idea? > > Alternately, might we retain CDDL syntax and define a profile/subset > which would be appropriate for us JSON-only simpletons? > > I'm not terribly fussy about mechanisms. Hi Tim, Could you show some simple examples of: - what you're thinking a JSL with established CDDL semantics would look like - what you're hoping for in terms of useful error messages? Thanks, Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Wed May 29 07:59:27 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 3D081120140 for ; Wed, 29 May 2019 07:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=cryptonector.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 5qWJzq_e104B for ; Wed, 29 May 2019 07:59:24 -0700 (PDT) Received: from goldenrod.birch.relay.mailchannels.net (goldenrod.birch.relay.mailchannels.net [23.83.209.74]) (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 55705120120 for ; Wed, 29 May 2019 07:59:24 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 563C1502951; Wed, 29 May 2019 14:59:23 +0000 (UTC) Received: from pdx1-sub0-mail-a68.g.dreamhost.com (100-96-11-129.trex.outbound.svc.cluster.local [100.96.11.129]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C2FC05026D6; Wed, 29 May 2019 14:59:22 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a68.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 29 May 2019 14:59:23 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Spot-Inform: 003f6ac4702e2e25_1559141963162_1521059498 X-MC-Loop-Signature: 1559141963162:178036559 X-MC-Ingress-Time: 1559141963161 Received: from pdx1-sub0-mail-a68.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a68.g.dreamhost.com (Postfix) with ESMTP id DBDE77FB2D; Wed, 29 May 2019 07:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=faA4hPb53LNXNU 4Gvnj+SkYZUl4=; b=BSEzhsbzFhnlQdqA4TfkYyYr9qmkb+arfSN9vmHQ70b5/A 59+pLBPCLpKMujazHrTC+3O7luJWebF+LVWbt+KOxEKI69jns+ka7cB4pmCblYxK jzt45WlwktdEzZiIuGjVOzTZc7M9/bh3j3AVjRkkUtsWL7Os7tlwQbiKnAGkQ= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a68.g.dreamhost.com (Postfix) with ESMTPSA id 827FA7FB2E; Wed, 29 May 2019 07:59:19 -0700 (PDT) Date: Wed, 29 May 2019 09:40:07 -0500 X-DH-BACKEND: pdx1-sub0-mail-a68 From: Nico Williams To: Tim Bray Cc: Rob Sayre , Carsten Bormann , Ulysse Carion , JSON WG Message-ID: <20190529144005.GC11773@localhost> References: <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddvjedgkeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 14:59:26 -0000 On Tue, May 28, 2019 at 08:47:16PM -0700, Tim Bray wrote: > TBH, what I want from a schema system is (a) useful error messages and (b) > ability to drive code generation, classes and serializer/deserializers and > so on. This is all I want as well. Validation and codegen. From nobody Wed May 29 12:15:00 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 F215A120163 for ; Wed, 29 May 2019 12:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ccil-org.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 mji4cO14lypn for ; Wed, 29 May 2019 12:14:55 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 67139120113 for ; Wed, 29 May 2019 12:14:55 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id r10so3189835otd.4 for ; Wed, 29 May 2019 12:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sT9yYv3xuu53+Q8u5JF5W79cmKyvWAlpw6A5VFYf86Y=; b=hlWDxOnTbH000/y1ALo/ilJ0NpRnRRAJDEAFa9kn2uKLs9sMWpD+BW7Wmk9vheph2h 9URvags4J0l+Rf2CIC2PD8ausqY4Yjyu5V9YQBic9X2Zrb1qYd6KGZLt+MvPHzKNrsAs mK32IAurlnxvfQimb3R4IAL/Dw9/9wu/Kb8Uf47Vkq8OcnpZ1r0uiAWU+PrnpgIV1xkt gGK1oqYi0uO8rQLY+txK2HJ8HbJUXQPTWLvXVzI+S06pk5iU6c92lDnskjnLCx8l+2eV /hxoFM3DJM3VsNhrx8tZk6gbhkXen63zgwFFKIGGj95vgYEab7S0CeYQmVr6EE3vFK7D of6w== 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=sT9yYv3xuu53+Q8u5JF5W79cmKyvWAlpw6A5VFYf86Y=; b=B588IYtU9CZ2UzA321cX2tfUPB8VMGjjTzkf3DX3KZea/Ucy0AaWHprOlt6ULb66Rx Vo+PcisE5sSo0FQWAiSWUTz844cV/DeN9xdSJ5zq7jrt4w7ui6LwFmHiKM554lMO9IYr rLs8VPMjZpeU+w+mXgAkNBZPM4jWg1A+/BjVtMEziZjlaEDGc6/PZLJ35tgTA2a5WjjY tGQKQ383USN06DGs5PMaiJKF6XBTsMipllx5gle5anm+GG2IzMREWi9F+mO88sdwwjjZ 1Bc1Xt4Edy0GPk+9fVgj8x01ZZIF13+pxLaowQg0L8V55PkTDb/o74b9p6vqH3SO2Siv HeLA== X-Gm-Message-State: APjAAAXAZkz4TSa0dB1VNxsc7g7R8pFA+ODQmSnvWXuFdrHGjPOCMfXm BNqI7rC1i+Fq/XMZXWUIfoXBtKkX/oEd56JiHciPKQ== X-Google-Smtp-Source: APXvYqyr7ENOAy5BzSmM7jb1vUdGu6XHDM7SXv4iYGW0mA1+kFFdXGT2blxTzN9WPTJC++AvW5D4zDzpzQN2a8HHHEQ= X-Received: by 2002:a9d:6287:: with SMTP id x7mr32566558otk.287.1559157294471; Wed, 29 May 2019 12:14:54 -0700 (PDT) MIME-Version: 1.0 References: <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> <20190529144005.GC11773@localhost> In-Reply-To: <20190529144005.GC11773@localhost> From: John Cowan Date: Wed, 29 May 2019 15:14:43 -0400 Message-ID: To: Nico Williams Cc: Tim Bray , JSON WG , Carsten Bormann , Ulysse Carion , Rob Sayre Content-Type: multipart/alternative; boundary="000000000000afb594058a0b9865" Archived-At: Subject: [Json] A minimal examplotron-style JSON validation language. 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, 29 May 2019 19:14:58 -0000 --000000000000afb594058a0b9865 Content-Type: text/plain; charset="UTF-8" The trouble is that "validation" is a very vague term. I would be happy with a language that can only express simple type validation, minimally as follows: 0) JSON values are divided into types, namely null, numbers, strings, booleans, object types, and arrays of any of these. 1) An object type specifies what attributes the corresponding object has and what the types of the corresponding values are, or else specifies that it may have arbitrary keys and values. It may have a name in the schema language 2) When an array is expected, the validator will check that all its contents have the same specified type. 3) There is a way to specify for a given object type whether it must contain exactly the specified keys, may contain a superset of the specified keys where the additional keys are not checked, or may contain a subset of the specified keys. This language leaves validation of the values of strings and numbers to lpost-validation code. It just makes sure that for a statically typed language a proper combination of records/structs/classes that can be generated in advance can represent any JSON value that is valid against the schema. Here is a very simple examplotron language: Sample document from json.org: {"menu": { "id": "file", "value": "File", "popup": { "menuitem": [ {"value": "New", "onclick": "CreateNewDoc()"}, {"value": "Open", "onclick": "OpenDoc()"}, {"value": "Close", "onclick": "CloseDoc()"} ] } }} Corresponding schema (constructed by hand, may have errors): { "root": {"menu", "menu"}, "menu": { "id": "", "value": "", "popup": "popup", }, "popup": {"menuitem": ["menuitem"]}, "menuitem": { "value": "", "onclick": "" } "__whole__": {"menu": "root"}, "__strictness__": {"menu": "superset"} } A schema is a JSON object whose keys are the names of object types, and whose values are the corresponding definitions. Object type names are meaningful only within the schema. In addition, the key "__whole__" (mandatory) is the type of the whole document. If the key "__strictness__" is present, its keys are object types and its values are one of the strings "exact", "subset", or "superset". Object types without names, or those not mentioned in "__strictness__", are always exact. An object type definition is an object whose keys are the keys of objects that are valid against it and whose values are the corresponding types. Alternatively, an empty object designates an object with arbitrary keys (in effect, a dictionary). An object type's designator can be its name (as a string), or an in-place object type definition. A null type's designator is the null value. Designators for a number, string, or boolean type are specified by any number, the empty string "", or any boolean respectively. An array type's designator is an array with one value, a designator for the type of the elements of the array. The schema for schemas is not very useful: it is simply {"__whole__": {}}, because the top-level keys have unpredictable names. On Wed, May 29, 2019 at 10:59 AM Nico Williams wrote: > On Tue, May 28, 2019 at 08:47:16PM -0700, Tim Bray wrote: > > TBH, what I want from a schema system is (a) useful error messages and > (b) > > ability to drive code generation, classes and serializer/deserializers > and > > so on. > > This is all I want as well. Validation and codegen. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --000000000000afb594058a0b9865 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    The trouble is that "validation"= ; is a very vague term.=C2=A0 I would be happy with a language that can onl= y express simple type validation, minimally as follows:

    = 0) JSON values are divided into types, namely null, numbers, strings, boole= ans, object types, and arrays of any of these.

    1) An= object type specifies what attributes the corresponding object has and wha= t the types of the corresponding values are, or else specifies that it may = have arbitrary keys and values.=C2=A0 =C2=A0It may have a name in the schem= a language=C2=A0=C2=A0=C2=A0

    2) When an array is exp= ected, the validator will check that all its contents have the same specifi= ed type.

    3) There is a way to specify = for a given object type whether it must contain exactly the specified keys,= may contain a superset of the specified keys where the additional keys are= not checked, or may contain a subset of the specified keys.

    =
    This language leaves validation of the values of strings and num= bers to lpost-validation code.=C2=A0 It just makes sure that for a statical= ly typed language a proper combination of records/structs/classes that can = be generated in advance can represent any JSON value that is valid against = the schema.

    Here is a very simple examplotron lang= uage:

    Sample document from json.org:
    {"menu": {
  "id": "file",
  "value": "File",
  "popup": {
    "menuitem": [
      {"value": "New", "onclick": "Creat=
eNewDoc()"},
      {"value": "Open", "onclick": "Open=
Doc()"},
      {"value": "Close", "onclick": "Clo=
seDoc()"}
    ]
  }
}}
    Corresponding schema (constructed by hand, may have errors):=

    {
    =C2=A0 "root": {&qu= ot;menu", "menu"},
    =C2=A0 "menu": {
    =C2=A0 =C2=A0 "id": "",
    =C2=A0 =C2=A0 "value"= ;: "",
    =C2= =A0 =C2=A0 "popup": "popup",
    =C2=A0 },
    =C2=A0 "popup":=C2=A0 {"menuitem": [= "menuitem"]},
    =C2=A0 "menuitem": {
    =C2=A0 =C2=A0 "value": "",
    <= div>=C2=A0 =C2=A0 "onclick"= : ""
    =C2= =A0 }
    =C2=A0 "_= _whole__": {"menu": "root"},
    =C2=A0 "__strictness__": {"= ;menu": "superset"}
    }

    A schema is a JSON object = whose keys are the names of object types, and whose values are the correspo= nding definitions.=C2=A0 Object type names are meaningful only within the s= chema.=C2=A0 In addition, the key "__whole__" (mandatory) is the = type of the whole document. If the key "__strictness__" is presen= t, its keys are object types and its values are one of the strings "ex= act", "subset", or "superset".=C2=A0 Object types = without names, or those not mentioned in "__strictness__", are al= ways exact.

    An object type definition is an object= whose keys are the keys of objects that are valid against it and whose val= ues are the corresponding types.=C2=A0 Alternatively, an empty object desig= nates an object with arbitrary keys (in effect, a dictionary).
    An object type's designator can be its name (as a string),= or an in-place object type definition.=C2=A0 A null type's designator = is the null value.=C2=A0 Designators for a number, string, or boolean type = are specified by any number, the empty string "", or any boolean = respectively. An array type's designator is an array with one value, a = designator for the type of the elements of the array.

    <= div>The schema for schemas is not very useful: it is simply {"__whole__": {}}, because the top-level keys have unpredictable names.


    On Wed, May 29, 2019 at 10:59 AM Nico Williams <nico@cryptonector.com> wrote:=
    On Tue, May 28,= 2019 at 08:47:16PM -0700, Tim Bray wrote:
    > TBH, what I want from a schema system is (a) useful error messages and= (b)
    > ability to drive code generation, classes and serializer/deserializers= and
    > so on.

    This is all I want as well.=C2=A0 Validation and codegen.

    _______________________________________________
    json mailing list
    json@ietf.org
    https://www.ietf.org/mailman/listinfo/json
    --000000000000afb594058a0b9865-- From nobody Wed May 29 13:24: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 AFAB5120150 for ; Wed, 29 May 2019 13:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=cryptonector.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 dq-tH_2MSOr6 for ; Wed, 29 May 2019 13:24:01 -0700 (PDT) Received: from purple.birch.relay.mailchannels.net (purple.birch.relay.mailchannels.net [23.83.209.150]) (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 790FE12001B for ; Wed, 29 May 2019 13:24:00 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 590562C250A; Wed, 29 May 2019 20:23:59 +0000 (UTC) Received: from pdx1-sub0-mail-a68.g.dreamhost.com (100-96-89-88.trex.outbound.svc.cluster.local [100.96.89.88]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id CCFB22C2C42; Wed, 29 May 2019 20:23:57 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a68.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 29 May 2019 20:23:59 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Daffy-White: 0939173d6d9a9800_1559161438326_635740150 X-MC-Loop-Signature: 1559161438326:3919572260 X-MC-Ingress-Time: 1559161438325 Received: from pdx1-sub0-mail-a68.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a68.g.dreamhost.com (Postfix) with ESMTP id AB0F27FB90; Wed, 29 May 2019 13:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=jwNU0Z0t+9zXTD ip5YL23EROnzo=; b=xm5+nCBNbs7pbTCPHXZ6jxl/qU/EusmkWdQrmyPawMH9m/ KHxjfIhgx/WAdbWUrsoJA7TH6l84CSETjOdh/O39YwG9JxlUxYAdPHvs7nf5wOsi Zv0SILd5adFLBddf5AKdQxBnqtS/qSqKb+Daz8+R3Fi+vGgQl++ggy8W4xKAU= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a68.g.dreamhost.com (Postfix) with ESMTPSA id F25397FB89; Wed, 29 May 2019 13:23:52 -0700 (PDT) Date: Wed, 29 May 2019 15:17:17 -0500 X-DH-BACKEND: pdx1-sub0-mail-a68 From: Nico Williams To: John Cowan Cc: Tim Bray , JSON WG , Carsten Bormann , Ulysse Carion , Rob Sayre Message-ID: <20190529201716.GD11773@localhost> References: <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> <20190529144005.GC11773@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddvjedgudehudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuffhomhgrihhnpehjshhonhdrohhrghenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Json] A minimal examplotron-style JSON validation language. 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, 29 May 2019 20:24:03 -0000 On Wed, May 29, 2019 at 03:14:43PM -0400, John Cowan wrote: > The trouble is that "validation" is a very vague term. I would be happy > with a language that can only express simple type validation, minimally as > follows: Validation, to me, means making sure that the "shape" of a value adheres to the "shape" given by the schema. Examples: - if, where you expect an array you see a boolean, that's an error - where you expect a numeric value you might have some constraints (e.g., range constraints) that, again, should raise an error if not met - ditto strings ('must be bas64', 'must be one of these (enum)', 'must match some regexp', etc.). That's it for validation. Now, validation mostly should only happen at decode time. In a language like JS (or jq) you might first parse the whole JSON text and then validate its "shape". > 0) JSON values are divided into types, namely null, numbers, strings, > booleans, object types, and arrays of any of these. > > 1) An object type specifies what attributes the corresponding object has > and what the types of the corresponding values are, or else specifies that > it may have arbitrary keys and values. It may have a name in the schema > language > > 2) When an array is expected, the validator will check that all its > contents have the same specified type. > > 3) There is a way to specify for a given object type whether it must > contain exactly the specified keys, may contain a superset of the specified > keys where the additional keys are not checked, or may contain a subset of > the specified keys. So far it sounds a lot like ASN.1. > Here is a very simple examplotron language: > > Sample document from json.org: > > {"menu": { > "id": "file", > "value": "File", > "popup": { > "menuitem": [ > {"value": "New", "onclick": "CreateNewDoc()"}, > {"value": "Open", "onclick": "OpenDoc()"}, > {"value": "Close", "onclick": "CloseDoc()"} > ] > } > }} > > Corresponding schema (constructed by hand, may have errors): I would prefer a schema language built around defining types, where user-defined types have to be a) JSON types with b) optional constraints. Regarding (a), we're going to need a discriminated union, something JSON doesn't have as such, but obviously is trivial to build by convention. Also, using JSON itself as the language for the schema is nice because you don't need to build a partser for the schema. But it's not very nice for users, so I'd prefer to have some non-JSON syntax for the schema. My counter: top_level : choice(file_menu, edit_menu); file_menu : object{"menu"->file_menu_contents}; edit_menu : object{"edit_menu"->edit_menu_contents}; file_menu_contents := object{ "id":"file", /* this means this must be present with this value */ "value":"File", "popup": object { ... } }; You can see the above has a hint of ASN.1 flavor, greatly simplified and somewhat transformed to be sure. I don't care one bit about the specifics of the syntax other than: it should be easy to build parsers for it. But I do very much like the idea of a schema language built around defining types. Nico -- From nobody Wed May 29 13:54:35 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 937DE1201E2 for ; Wed, 29 May 2019 13:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 e2rz818baHNU for ; Wed, 29 May 2019 13:54:32 -0700 (PDT) Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (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 B2E461201E0 for ; Wed, 29 May 2019 13:54:32 -0700 (PDT) Received: by mail-ot1-f54.google.com with SMTP id i8so3456837oth.10 for ; Wed, 29 May 2019 13:54:32 -0700 (PDT) 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=mR0yORgt8M8e8Vq1ORdFV49b8Zwq8gsE3MizIZSN4dw=; b=n/srzzPF+A0jCQhl/tAxxbNiGA1Ln/Z0XqDu4C4PCplLPn86Rrm4BhOxSDMYGZgjlo W+RCVJ2ib2/xOgCRpanwvi3t9My1d3+tuNkPra4hBF/TfKLBRC87wB3tWLjTN+ghxQ5s HQGVOog1ZTGsMv9nqKslBx18ckys7MAdhlU9iKAbiYnkz0VDoWSJqD67yG13DURDTKBl cgmj9kBPZZFSMOeuwwB8GDhWguleiaqWq93CPe2nn0ig12Wkh0VEGnrYHfKvFw1GrmBq eCO7zCoEP42ROuCHtplxLxjApMmQALd/GL3hvMGCEr9lMXRK4AV3OKnrOc6lIceNoQ1H 6LCw== X-Gm-Message-State: APjAAAVWMrX1aS2HjEOj/2vmQpF8R91dw5cVgvVF7Ft5uh2HMDmDuTvI KBH24ZFmVlWdmWM/Vhj5QW7yX3Y1tVR8Pk1uQDI= X-Google-Smtp-Source: APXvYqzthYVFu/2CBEroNHZ1NyE8d+s0s30ydvJ90Ex3Zpo2H8bxBnkOIeuNudnKXrMygbR+jFrcg2IvHyi5i4Ro0Ho= X-Received: by 2002:a9d:3442:: with SMTP id v60mr5286061otb.112.1559163271985; Wed, 29 May 2019 13:54:31 -0700 (PDT) MIME-Version: 1.0 References: <646abf11-496b-c120-45d6-2a1aeab051a8@codalogic.com> <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> <20190529144005.GC11773@localhost> In-Reply-To: <20190529144005.GC11773@localhost> From: Phillip Hallam-Baker Date: Wed, 29 May 2019 16:54:11 -0400 Message-ID: To: Nico Williams Cc: Tim Bray , JSON WG , Carsten Bormann , Ulysse Carion , Rob Sayre Content-Type: multipart/alternative; boundary="000000000000f93f41058a0cfcc9" Archived-At: Subject: Re: [Json] JSON Schema Language X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 20:54:34 -0000 --000000000000f93f41058a0cfcc9 Content-Type: text/plain; charset="UTF-8" On Wed, May 29, 2019 at 10:59 AM Nico Williams wrote: > On Tue, May 28, 2019 at 08:47:16PM -0700, Tim Bray wrote: > > TBH, what I want from a schema system is (a) useful error messages and > (b) > > ability to drive code generation, classes and serializer/deserializers > and > > so on. > > This is all I want as well. Validation and codegen. > I use mine for code generation and for document generation. The drafts are produced by the same source that generates the code used to create the examples. Validation is another issue entirely. I don't think it is actually useful beyond 'can the data be deserialized'. It is problematic if someone sends a string in a field where I really need an integer, but additional fields I will simply ignore unless they are in some SAML Conditions like structure which MUST be understood. But the only reason to use that approach is when you require a means of signalling a breaking change. The tools I am currently using are on Github and they work on Windows, OSX and Linux. This is not the approach I would use if I was going to propose a standard. There are a half dozen different schema systems that vary by small degrees for different purposes that I think could be merged. https://github.com/hallambaker/PHB-Build-Tools --000000000000f93f41058a0cfcc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Wed, May 29, 2019 at 10:59 AM Nico Williams <nico@cryptonector.com> wrote:
    On Tue, May 28, 2019 at 08:47:16PM -0700, Tim Bray wrote:
    > TBH, what I want from a schema system is (a) useful error messages and= (b)
    > ability to drive code generation, classes and serializer/deserializers= and
    > so on.

    This is all I want as well.=C2=A0 Validation and codegen.
    <= div>

    I use mine for code generation and for document generation. The dr= afts are produced by the same source that generates the code used to create= the examples.
    =
    Validation= is another issue entirely. I don't think it is actually useful beyond = 'can the data be deserialized'. It is problematic if someone sends = a string in a field where I really need an integer, but additional fields I= will simply ignore unless they are in some SAML Conditions like structure = which MUST be understood. But the only reason to use that approach is when = you require a means of signalling a breaking change.

    The tools I am currently using are on Github an= d they work on Windows, OSX and Linux.

    This is not the approach I would use if I was going to propos= e a standard. There are a half dozen different schema systems that vary by = small degrees for different purposes that I think could be merged.


    https://github.com/hallambaker/PHB-Build-Tools=C2=A0=C2= =A0
    --000000000000f93f41058a0cfcc9-- From nobody Wed May 29 14:14:26 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 D703F1201E2 for ; Wed, 29 May 2019 14:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 7u1XXqxAl6uu for ; Wed, 29 May 2019 14:14:21 -0700 (PDT) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013E41201E3 for ; Wed, 29 May 2019 14:14:20 -0700 (PDT) Received: (qmail 11621 invoked from network); 29 May 2019 22:12:19 +0100 Received: from host86-174-116-175.range86-174.btcentralplus.com (HELO ?192.168.1.72?) (86.174.116.175) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 29 May 2019 22:12:18 +0100 To: Nico Williams , John Cowan Cc: JSON WG References: <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> <20190529144005.GC11773@localhost> <20190529201716.GD11773@localhost> From: Pete Cordell Message-ID: Date: Wed, 29 May 2019 22:14:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190529201716.GD11773@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] A minimal examplotron-style JSON validation language. 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, 29 May 2019 21:14:24 -0000 On 29/05/2019 21:17, Nico Williams wrote: > On Wed, May 29, 2019 at 03:14:43PM -0400, John Cowan wrote: >> Here is a very simple examplotron language: >> >> Sample document from json.org: >> >> {"menu": { >> "id": "file", >> "value": "File", >> "popup": { >> "menuitem": [ >> {"value": "New", "onclick": "CreateNewDoc()"}, >> {"value": "Open", "onclick": "OpenDoc()"}, >> {"value": "Close", "onclick": "CloseDoc()"} >> ] >> } >> }} >> >... > > My counter: > > top_level : choice(file_menu, edit_menu); > file_menu : object{"menu"->file_menu_contents}; > edit_menu : object{"edit_menu"->edit_menu_contents}; > file_menu_contents := object{ > "id":"file", /* this means this must be present with this value */ > "value":"File", > "popup": object { ... } > }; For a quick taste of JCR, see: http://json-content-rules.org/tutorial For a more examplotron feel, JCR could define a #inferred-types directive so, for example, string values are treated as generic string rather than a specific string. e.g.: #inferred-types { "Image": { "Width": 800, "Height": 600, "Title": "View from 15th Floor", "Thumbnail": { "Url": "http://www.example.com/image/481989943", "Height": 125, "Width": 100 }, "Animated" : false, "IDs": [116, 943, 234, 38793] } } gets treated as: { "Image": { "Width": integer, "Height": integer, "Title": string, "Thumbnail": { "Url": string, "Height": integer, "Width": integer }, "Animated" : boolean, "IDs": [integer *] } } Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Wed May 29 14:15:17 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 17CCE1201E2 for ; Wed, 29 May 2019 14:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 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] 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 RT_TO-Uzl28c for ; Wed, 29 May 2019 14:15:12 -0700 (PDT) Received: from smtp.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 7ED41120041 for ; Wed, 29 May 2019 14:15:12 -0700 (PDT) Received: from [192.168.217.119] (p54A6C998.dip0.t-ipconnect.de [84.166.201.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45Dk4t15XGzyV4; Wed, 29 May 2019 23:15:10 +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: <20190529201716.GD11773@localhost> Date: Wed, 29 May 2019 23:15:09 +0200 Cc: John Cowan , Tim Bray , JSON WG , Ulysse Carion , Rob Sayre X-Mao-Original-Outgoing-Id: 580857305.2885571-526104fd52d79713ef4b9b70ce148e6d Content-Transfer-Encoding: quoted-printable Message-Id: References: <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> <20190529144005.GC11773@localhost> <20190529201716.GD11773@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] A minimal examplotron-style JSON validation language. 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, 29 May 2019 21:15:15 -0000 On May 29, 2019, at 22:17, Nico Williams wrote: >=20 > top_level : choice(file_menu, edit_menu); > file_menu : object{"menu"->file_menu_contents}; > edit_menu : object{"edit_menu"->edit_menu_contents}; > file_menu_contents :=3D object{ > "id":"file", /* this means this must be present with this value */ > "value":"File", > "popup": object { ... } > }; While it is certainly enjoyable to design another language, I=E2=80=99m = not sure why this should not be done in an ABNF-like syntax such as CDDL = (which, by the way, is in AUTH48 and will soon be RFC 8610). =20 Keeping your names (even the snake case, where I=E2=80=99d be using = kebab case): top_level =3D file_menu / edit_menu file_menu =3D { menu: file_menu_contents } edit_menu =3D { edit_menu: edit_menu_contents } file_menu_contents =3D { id: text ; assuming here this is your examplotron content value: text popup: { } } edit_menu_contents =3D { } I didn=E2=80=99t put in the ignore-unknown stuff; that would be 12 = characters in CDDL unless you define something to make this shorter. Put the above into a menus.cddl and try cddl menus.cddl g 10 you get 10 examples: {"menu": {"id": "gray", "value": "commixt", "popup": {}}} {"menu": {"id": "proctoplasty", "value": "compunctious", "popup": {}}} {"menu": {"id": "taglike", "value": "valvulate", "popup": {}}} {"edit_menu": {}} {"menu": {"id": "uninundated", "value": "unworthily", "popup": {}}} {"edit_menu": {}} {"edit_menu": {}} {"menu": {"id": "Orangeist", "value": "imperialin", "popup": {}}} {"edit_menu": {}} {=E2=80=9Cedit_menu": {}} This is a bit boring as there is only one choice and two non-singleton = types. Sorry if I didn=E2=80=99t get the intent of your example right. Gr=C3=BC=C3=9Fe, Carsten PS.: OK, with ignore-unknown: top_level =3D file_menu / edit_menu file_menu =3D { menu: file_menu_contents _..._ } edit_menu =3D { edit_menu: edit_menu_contents _..._ } file_menu_contents =3D { id: text ; I'm assuming here this is your examplotron content value: text popup: { _..._ } _..._ } edit_menu_contents =3D { _..._ } _..._ =3D ( * text =3D> any ) =E2=9E=94=20 {"menu": {"id": "fahlerz", "value": "unshocked", "popup": = {"astrophotometry": "perdurance"}, "foolship": "pentacosane", = "larrikin": "myoglobin"}} {"edit_menu": {"priggery": "cordaitean", "jackpudding": "righten", = "unconfidence": "photolitho", "reviling": "ewe"}, "allophylic": = "compound", "teacupful": "allergen"} {"menu": {"id": "amazement", "value": "condylomatous", "popup": = {"cosounding": "share", "contribute": "gabblement", "gunpaper": = "dividualism", "undersociety": "noration"}}} {"edit_menu": {"glareole": "clicket", "madling": "dizain"}, "scrimpily": = "gypsywort", "neurofibrilla": "discolor"} {"edit_menu": {"unpermissive": "cockneity"}, "caudillism": "visa", = "interloop": "anthracnose"} {"menu": {"id": "blankite", "value": "puffery", "popup": {"katuka": = "Gnathostomata", "effeteness": "unspelt"}}, "Chaldaic": = "extrafoliaceous", "trimesic": "dwindlement", "successful": "fluctuant", = "nevadite": "aggradational"} {"menu": {"id": "acrostolion", "value": "devocalize", "popup": {}}, = "cymation": "premanufacturer", "mysticete": "analyst", "ethnocentric": = "Myrtales"} {"edit_menu": {"glycerolize": "blastoid", "undisputedness": = "propheticly"}, "orchiotomy": "illiquidity"} {"menu": {"id": "tenebriously", "value": "guardo", "popup": {"abeigh": = "fibrillar", "Sminthurus": "disnosed", "accessibility": "autem"}}} {"edit_menu": {"stableman": "erosional"}} From nobody Wed May 29 17:07: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 BD4621200B7 for ; Wed, 29 May 2019 17:07:45 -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=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 1PL3gyndUSev for ; Wed, 29 May 2019 17:07:43 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 5E311120020 for ; Wed, 29 May 2019 17:07:43 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id m141so7082192ita.3 for ; Wed, 29 May 2019 17:07:43 -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=8jsPfGBBh6+24E2g/yyYAb2HxfJQ/yzec5rCpzyJ4pg=; b=ZXBfnOfz/7OKUu5ZetDXrTVc0hkZKVEZumw4bRg1wJApG+6a3BHPr465gZdnrYci4n 5CUvrmt3XPuhn5jy05fFQqAKRZme5rQtANTd4XCftJi2YVZorDC3ZWWyntjWbq3SxJbP VvlzkwgNYnfworV7a3HIKxgq063XFiyX5j/2s= 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=8jsPfGBBh6+24E2g/yyYAb2HxfJQ/yzec5rCpzyJ4pg=; b=KEL6pQIma5mWhfhp7ng/r7Ztqy17uGaBxbpboHznPx37geiIswqfkf8gQZx4kqb5Zm I14p0WuotiEhmp6QaD+KjLvdJVSZAct+dWRWmQIGZ9dULfYiuJjwTmXYyOxWqGBv0+M+ P52ITxfDnIAnJAaNV+r7BxIf7xDng5gdBqKYvHfftlmjLKr3XTunyMTAxtNYEt6cSTtZ o55Di7fMc0EMUUVuNKwOj77hoC0AO8VrN1OLFFtU4JNyZLoqLKiIoUcGvRe+QzAyyNFi PSacVajtsslcooJWOBJ60t6OP2SzRliS5YhAFhToUILhJtmrgFWMKAELk7Sr2YNn9NoF O5Yg== X-Gm-Message-State: APjAAAUlnjudzYVwl1eg3Z/5AWkhtLx9qNef0giY8bI0Dxv8MkuzAG8c 0I9OK0bjREvk7dZNI08IcwINiAMRBMzgIjX/NhOYvA== X-Google-Smtp-Source: APXvYqz/1ed8j9r+LG/3qOO0Cx/wPKSNta2iBpCIb+uzHRqdok8klONcx5w7X81wQb4OeSQTid6u78KccwQBgt31fdY= X-Received: by 2002:a24:1416:: with SMTP id 22mr822400itg.144.1559174862346; Wed, 29 May 2019 17:07:42 -0700 (PDT) MIME-Version: 1.0 References: <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> <20190529144005.GC11773@localhost> <20190529201716.GD11773@localhost> In-Reply-To: From: Ulysse Carion Date: Wed, 29 May 2019 17:07:31 -0700 Message-ID: To: Carsten Bormann Cc: Nico Williams , John Cowan , Tim Bray , JSON WG , Rob Sayre Content-Type: multipart/alternative; boundary="000000000000d03aff058a0faf55" Archived-At: Subject: Re: [Json] A minimal examplotron-style JSON validation language. 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, 30 May 2019 00:07:46 -0000 --000000000000d03aff058a0faf55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carsten, Any thoughts on Tim Bray's suggestion? Regarding something akin to JSL (+ enums + timestamps), but perhaps built atop the foundations of CDDL? - Ulysse On Wed, May 29, 2019 at 2:15 PM Carsten Bormann wrote: > On May 29, 2019, at 22:17, Nico Williams wrote: > > > > top_level : choice(file_menu, edit_menu); > > file_menu : object{"menu"->file_menu_contents}; > > edit_menu : object{"edit_menu"->edit_menu_contents}; > > file_menu_contents :=3D object{ > > "id":"file", /* this means this must be present with this value */ > > "value":"File", > > "popup": object { ... } > > }; > > While it is certainly enjoyable to design another language, I=E2=80=99m n= ot sure > why this should not be done in an ABNF-like syntax such as CDDL (which, b= y > the way, is in AUTH48 and will soon be RFC 8610). > Keeping your names (even the snake case, where I=E2=80=99d be using kebab= case): > > top_level =3D file_menu / edit_menu > file_menu =3D { menu: file_menu_contents } > edit_menu =3D { edit_menu: edit_menu_contents } > file_menu_contents =3D { > id: text ; assuming here this is your examplotron content > value: text > popup: { } > } > edit_menu_contents =3D { } > > I didn=E2=80=99t put in the ignore-unknown stuff; that would be 12 charac= ters in > CDDL unless you define something to make this shorter. > > Put the above into a menus.cddl and try > > cddl menus.cddl g 10 > > you get 10 examples: > > {"menu": {"id": "gray", "value": "commixt", "popup": {}}} > {"menu": {"id": "proctoplasty", "value": "compunctious", "popup": {}}} > {"menu": {"id": "taglike", "value": "valvulate", "popup": {}}} > {"edit_menu": {}} > {"menu": {"id": "uninundated", "value": "unworthily", "popup": {}}} > {"edit_menu": {}} > {"edit_menu": {}} > {"menu": {"id": "Orangeist", "value": "imperialin", "popup": {}}} > {"edit_menu": {}} > {=E2=80=9Cedit_menu": {}} > > This is a bit boring as there is only one choice and two non-singleton > types. > Sorry if I didn=E2=80=99t get the intent of your example right. > > Gr=C3=BC=C3=9Fe, Carsten > > PS.: OK, with ignore-unknown: > > top_level =3D file_menu / edit_menu > file_menu =3D { menu: file_menu_contents _..._ } > edit_menu =3D { edit_menu: edit_menu_contents _..._ } > file_menu_contents =3D { > id: text ; I'm assuming here this is your examplotron content > value: text > popup: { _..._ } > _..._ > } > edit_menu_contents =3D { _..._ } > > _..._ =3D ( * text =3D> any ) > > =E2=9E=94 > > {"menu": {"id": "fahlerz", "value": "unshocked", "popup": > {"astrophotometry": "perdurance"}, "foolship": "pentacosane", "larrikin": > "myoglobin"}} > {"edit_menu": {"priggery": "cordaitean", "jackpudding": "righten", > "unconfidence": "photolitho", "reviling": "ewe"}, "allophylic": "compound= ", > "teacupful": "allergen"} > {"menu": {"id": "amazement", "value": "condylomatous", "popup": > {"cosounding": "share", "contribute": "gabblement", "gunpaper": > "dividualism", "undersociety": "noration"}}} > {"edit_menu": {"glareole": "clicket", "madling": "dizain"}, "scrimpily": > "gypsywort", "neurofibrilla": "discolor"} > {"edit_menu": {"unpermissive": "cockneity"}, "caudillism": "visa", > "interloop": "anthracnose"} > {"menu": {"id": "blankite", "value": "puffery", "popup": {"katuka": > "Gnathostomata", "effeteness": "unspelt"}}, "Chaldaic": "extrafoliaceous"= , > "trimesic": "dwindlement", "successful": "fluctuant", "nevadite": > "aggradational"} > {"menu": {"id": "acrostolion", "value": "devocalize", "popup": {}}, > "cymation": "premanufacturer", "mysticete": "analyst", "ethnocentric": > "Myrtales"} > {"edit_menu": {"glycerolize": "blastoid", "undisputedness": > "propheticly"}, "orchiotomy": "illiquidity"} > {"menu": {"id": "tenebriously", "value": "guardo", "popup": {"abeigh": > "fibrillar", "Sminthurus": "disnosed", "accessibility": "autem"}}} > {"edit_menu": {"stableman": "erosional"}} > > > > --000000000000d03aff058a0faf55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Carsten,

    Any thoughts on Tim Bray= 9;s suggestion? Regarding something akin to JSL (+ enums + timestamps), but= perhaps built atop the foundations of CDDL?

    - Uly= sse

    On Wed, May 29, 2019 at 2:15 PM Carsten Bormann <cabo@tzi.org> wrote:
    On May 29, 2019, at 22:17, = Nico Williams <nico@cryptonector.com> wrote:
    >
    >=C2=A0 top_level : choice(file_menu, edit_menu);
    >=C2=A0 file_menu : object{"menu"->file_menu_contents};
    >=C2=A0 edit_menu : object{"edit_menu"->edit_menu_contents}= ;
    >=C2=A0 file_menu_contents :=3D object{
    >=C2=A0 =C2=A0 "id":"file", /* this means this must = be present with this value */
    >=C2=A0 =C2=A0 "value":"File",
    >=C2=A0 =C2=A0 "popup": object { ... }
    >=C2=A0 };

    While it is certainly enjoyable to design another language, I=E2=80=99m not= sure why this should not be done in an ABNF-like syntax such as CDDL (whic= h, by the way, is in AUTH48 and will soon be RFC 8610).=C2=A0
    Keeping your names (even the snake case, where I=E2=80=99d be using kebab c= ase):

    top_level =3D file_menu / edit_menu
    file_menu =3D { menu: file_menu_contents }
    edit_menu =3D { edit_menu: edit_menu_contents }
    file_menu_contents =3D {
    =C2=A0 id: text=C2=A0 =C2=A0 ; assuming here this is your examplotron conte= nt
    =C2=A0 value: text
    =C2=A0 popup: { }
    }
    edit_menu_contents =3D { }

    I didn=E2=80=99t put in the ignore-unknown stuff; that would be 12 characte= rs in CDDL unless you define something to make this shorter.

    Put the above into a menus.cddl and try

    =C2=A0 cddl menus.cddl g 10

    you get 10 examples:

    {"menu": {"id": "gray", "value": &q= uot;commixt", "popup": {}}}
    {"menu": {"id": "proctoplasty", "value&q= uot;: "compunctious", "popup": {}}}
    {"menu": {"id": "taglike", "value":= "valvulate", "popup": {}}}
    {"edit_menu": {}}
    {"menu": {"id": "uninundated", "value&qu= ot;: "unworthily", "popup": {}}}
    {"edit_menu": {}}
    {"edit_menu": {}}
    {"menu": {"id": "Orangeist", "value"= ;: "imperialin", "popup": {}}}
    {"edit_menu": {}}
    {=E2=80=9Cedit_menu": {}}

    This is a bit boring as there is only one choice and two non-singleton type= s.
    Sorry if I didn=E2=80=99t get the intent of your example right.

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

    PS.: OK, with ignore-unknown:

    top_level =3D file_menu / edit_menu
    file_menu =3D { menu: file_menu_contents _..._ }
    edit_menu =3D { edit_menu: edit_menu_contents _..._ }
    file_menu_contents =3D {
    =C2=A0 id: text=C2=A0 =C2=A0 ; I'm assuming here this is your examplotr= on content
    =C2=A0 value: text
    =C2=A0 popup: { _..._ }
    =C2=A0 _..._
    }
    edit_menu_contents =3D { _..._ }

    _..._ =3D ( * text =3D> any )

    =E2=9E=94

    {"menu": {"id": "fahlerz", "value":= "unshocked", "popup": {"astrophotometry": &q= uot;perdurance"}, "foolship": "pentacosane", "= ;larrikin": "myoglobin"}}
    {"edit_menu": {"priggery": "cordaitean", &quo= t;jackpudding": "righten", "unconfidence": "p= hotolitho", "reviling": "ewe"}, "allophylic&q= uot;: "compound", "teacupful": "allergen"} {"menu": {"id": "amazement", "value"= ;: "condylomatous", "popup": {"cosounding": &= quot;share", "contribute": "gabblement", "gun= paper": "dividualism", "undersociety": "norat= ion"}}}
    {"edit_menu": {"glareole": "clicket", "m= adling": "dizain"}, "scrimpily": "gypsywort&q= uot;, "neurofibrilla": "discolor"}
    {"edit_menu": {"unpermissive": "cockneity"}, = "caudillism": "visa", "interloop": "anth= racnose"}
    {"menu": {"id": "blankite", "value"= : "puffery", "popup": {"katuka": "Gnatho= stomata", "effeteness": "unspelt"}}, "Chaldai= c": "extrafoliaceous", "trimesic": "dwindleme= nt", "successful": "fluctuant", "nevadite&quo= t;: "aggradational"}
    {"menu": {"id": "acrostolion", "value&qu= ot;: "devocalize", "popup": {}}, "cymation": = "premanufacturer", "mysticete": "analyst", &q= uot;ethnocentric": "Myrtales"}
    {"edit_menu": {"glycerolize": "blastoid", &qu= ot;undisputedness": "propheticly"}, "orchiotomy": = "illiquidity"}
    {"menu": {"id": "tenebriously", "value&q= uot;: "guardo", "popup": {"abeigh": "fib= rillar", "Sminthurus": "disnosed", "accessibi= lity": "autem"}}}
    {"edit_menu": {"stableman": "erosional"}}



    --000000000000d03aff058a0faf55-- From nobody Thu May 30 02:36: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 D627F1200F1 for ; Thu, 30 May 2019 02:36:16 -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 52GLoac4utM0 for ; Thu, 30 May 2019 02:36:14 -0700 (PDT) Received: from smtp.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 D65221200E0 for ; Thu, 30 May 2019 02:36:13 -0700 (PDT) Received: from client-0039.vpn.uni-bremen.de (client-0039.vpn.uni-bremen.de [134.102.107.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45F2Wv01HPz10RL; Thu, 30 May 2019 11:36:10 +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, 30 May 2019 11:36:10 +0200 Cc: JSON WG X-Mao-Original-Outgoing-Id: 580901723.450272-ddf368eaefbe7280668d6ef44a55192d Content-Transfer-Encoding: quoted-printable Message-Id: References: <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> <20190529144005.GC11773@localhost> <20190529201716.GD11773@localhost> To: Ulysse Carion X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] A minimal examplotron-style JSON validation language. 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, 30 May 2019 09:36:17 -0000 Hi Ulysse, your message catches me at the start of a long weekend (which seamlessly = turns into an IAB workshop and more travel next week). So I won=E2=80=99t= have much time preparing anything in the next 10 days. But most of the job of translating JSL into CDDL is already done in = example form in https://mailarchive.ietf.org/arch/msg/json/1WpdpfsXr3gEIdXb8OV0R_J-O4E Adding enums is easy once there is a JSL side (one would have to decide = between two conventions of doing them in CDDL) =E2=80=94 can you propose = that? CDDL does have ways of specifying timestamps (both POSIX epoch-based = numbers of seconds and RFC 3339 style; the independent tag 1001 is = addressing further types of time such as TAI or GPS); which ones do we = want? Having a JSON data definition language like JSL that is both homoiconic = (represented in JSON itself) and unable to fully describe its own = structure might be considered ironic by some, but it is also a powerful = statement of direction: Not even starting to boil the ocean. Gr=C3=BC=C3=9Fe, Carsten > On May 30, 2019, at 02:07, Ulysse Carion wrote: >=20 > Hi Carsten, >=20 > Any thoughts on Tim Bray's suggestion? Regarding something akin to JSL = (+ enums + timestamps), but perhaps built atop the foundations of CDDL? >=20 > - Ulysse >=20 > On Wed, May 29, 2019 at 2:15 PM Carsten Bormann wrote: > On May 29, 2019, at 22:17, Nico Williams = wrote: > >=20 > > top_level : choice(file_menu, edit_menu); > > file_menu : object{"menu"->file_menu_contents}; > > edit_menu : object{"edit_menu"->edit_menu_contents}; > > file_menu_contents :=3D object{ > > "id":"file", /* this means this must be present with this value = */ > > "value":"File", > > "popup": object { ... } > > }; >=20 > While it is certainly enjoyable to design another language, I=E2=80=99m = not sure why this should not be done in an ABNF-like syntax such as CDDL = (which, by the way, is in AUTH48 and will soon be RFC 8610). =20 > Keeping your names (even the snake case, where I=E2=80=99d be using = kebab case): >=20 > top_level =3D file_menu / edit_menu > file_menu =3D { menu: file_menu_contents } > edit_menu =3D { edit_menu: edit_menu_contents } > file_menu_contents =3D { > id: text ; assuming here this is your examplotron content > value: text > popup: { } > } > edit_menu_contents =3D { } >=20 > I didn=E2=80=99t put in the ignore-unknown stuff; that would be 12 = characters in CDDL unless you define something to make this shorter. >=20 > Put the above into a menus.cddl and try >=20 > cddl menus.cddl g 10 >=20 > you get 10 examples: >=20 > {"menu": {"id": "gray", "value": "commixt", "popup": {}}} > {"menu": {"id": "proctoplasty", "value": "compunctious", "popup": {}}} > {"menu": {"id": "taglike", "value": "valvulate", "popup": {}}} > {"edit_menu": {}} > {"menu": {"id": "uninundated", "value": "unworthily", "popup": {}}} > {"edit_menu": {}} > {"edit_menu": {}} > {"menu": {"id": "Orangeist", "value": "imperialin", "popup": {}}} > {"edit_menu": {}} > {=E2=80=9Cedit_menu": {}} >=20 > This is a bit boring as there is only one choice and two non-singleton = types. > Sorry if I didn=E2=80=99t get the intent of your example right. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > PS.: OK, with ignore-unknown: >=20 > top_level =3D file_menu / edit_menu > file_menu =3D { menu: file_menu_contents _..._ } > edit_menu =3D { edit_menu: edit_menu_contents _..._ } > file_menu_contents =3D { > id: text ; I'm assuming here this is your examplotron content > value: text > popup: { _..._ } > _..._ > } > edit_menu_contents =3D { _..._ } >=20 > _..._ =3D ( * text =3D> any ) >=20 > =E2=9E=94=20 >=20 > {"menu": {"id": "fahlerz", "value": "unshocked", "popup": = {"astrophotometry": "perdurance"}, "foolship": "pentacosane", = "larrikin": "myoglobin"}} > {"edit_menu": {"priggery": "cordaitean", "jackpudding": "righten", = "unconfidence": "photolitho", "reviling": "ewe"}, "allophylic": = "compound", "teacupful": "allergen"} > {"menu": {"id": "amazement", "value": "condylomatous", "popup": = {"cosounding": "share", "contribute": "gabblement", "gunpaper": = "dividualism", "undersociety": "noration"}}} > {"edit_menu": {"glareole": "clicket", "madling": "dizain"}, = "scrimpily": "gypsywort", "neurofibrilla": "discolor"} > {"edit_menu": {"unpermissive": "cockneity"}, "caudillism": "visa", = "interloop": "anthracnose"} > {"menu": {"id": "blankite", "value": "puffery", "popup": {"katuka": = "Gnathostomata", "effeteness": "unspelt"}}, "Chaldaic": = "extrafoliaceous", "trimesic": "dwindlement", "successful": "fluctuant", = "nevadite": "aggradational"} > {"menu": {"id": "acrostolion", "value": "devocalize", "popup": {}}, = "cymation": "premanufacturer", "mysticete": "analyst", "ethnocentric": = "Myrtales"} > {"edit_menu": {"glycerolize": "blastoid", "undisputedness": = "propheticly"}, "orchiotomy": "illiquidity"} > {"menu": {"id": "tenebriously", "value": "guardo", "popup": {"abeigh": = "fibrillar", "Sminthurus": "disnosed", "accessibility": "autem"}}} > {"edit_menu": {"stableman": "erosional"}} >=20 >=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Thu May 30 05:54:07 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 1DBE012014A for ; Thu, 30 May 2019 05:54:05 -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, 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=ccil-org.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 0rxXpNLD9dUI for ; Thu, 30 May 2019 05:54:02 -0700 (PDT) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 816B012004F for ; Thu, 30 May 2019 05:54:02 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id q186so4857806oia.0 for ; Thu, 30 May 2019 05:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5HcI0nQLwrQQNY3CvHGtth+Bb+0B0aQDMyTQD7UffO4=; b=eipFWQQoVYsJkeUgYgDoP/ZpYApQ/JdclS+nAbRXH3MFm31gMYCwM5Tp+Oi9Lx1CYu A4YZT8VmDmplWElcjdQGmpM0i33d2q+jeQr5QZb6LfdoSkFAIsbk/q304b4SxgpqCCSz 2lD+Rro+QwkIkTki7IhSSgMCgJ7q3Wsq1TowpG2c3tthwIxepeX+QPlzECH1dZ5TPzTL bVcCVgAsPIlrSU3SIHfuZeimKEro9IMwMw19JRtDJel4xMMHoDWjDRamjAtpfc9dQ9pZ vNWEtoFmveaIdF6CMb42FswQOBa6JWAzR9CLiAUOILUiRjV2Rrt2t97NvvuSc/IvOfz0 bd1g== 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=5HcI0nQLwrQQNY3CvHGtth+Bb+0B0aQDMyTQD7UffO4=; b=TnrCJwGNJgEjrduw74rdFk5KMgo4CWZVeTtyHtEQZwZ74gooRdD7hZO6nFP7WgiLLV 4GmI8Cih48rmboB21z0jaJjZVMLEzL6sAiibUux2Jrdj5rAAFMBcP8OnN+ZxHtjdghdq Zq2vuHWc6+XDya1KT4oAraNHnH95P7zmParV3He43Ah8ZNlEzfiGtss9WLc1Ch8wEa5S MstSpw+0BrOcMzsh4epx26DAYNAxrdnFGs3Mu907J61WLp/GDqOGbl790Mt78H7+GKPq itkNlR+4QG7UbUcyytB53LSKp8NmZszA1LYNVVK1a3fTLXuTfqeXmBuCLXWVYh7jaz2e iLWA== X-Gm-Message-State: APjAAAVOg1WtE3KQavDbVYWSgpHb37Rb74xZR3VhRF4tm/EQXuVckTrh MYeXcsVW0fAPqJoBg3j2DEiHa3V+CgHrs0nRmFbTzQ== X-Google-Smtp-Source: APXvYqyPCX4YL59HUyTkPEJ5zGmO8C+MaThbvFImnGcN7wjb1Ofi9ZNnUmAHmgGposhSph4WAOS+tS2Vc6Nq0nXP6Zs= X-Received: by 2002:aca:e50d:: with SMTP id c13mr510046oih.42.1559220841471; Thu, 30 May 2019 05:54:01 -0700 (PDT) MIME-Version: 1.0 References: <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> <20190529144005.GC11773@localhost> <20190529201716.GD11773@localhost> In-Reply-To: <20190529201716.GD11773@localhost> From: John Cowan Date: Thu, 30 May 2019 08:53:50 -0400 Message-ID: To: Nico Williams Cc: Tim Bray , JSON WG , Carsten Bormann , Ulysse Carion , Rob Sayre Content-Type: multipart/alternative; boundary="00000000000061f95a058a1a6434" Archived-At: Subject: Re: [Json] A minimal examplotron-style JSON validation language. 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, 30 May 2019 12:54:05 -0000 --00000000000061f95a058a1a6434 Content-Type: text/plain; charset="UTF-8" On Wed, May 29, 2019 at 4:24 PM Nico Williams wrote: - if, where you expect an array you see a boolean, that's an error > Agreed,, because statically typed programming languages can't cope. > - where you expect a numeric value you might have some constraints > (e.g., range constraints) that, again, should raise an error if not > met > > - ditto strings ('must be bas64', 'must be one of these (enum)', 'must > match some regexp', etc.). The question is, where do you stop? Range constraints are all very well, but suppose you want to constrain a number value to be a U.S shoe size, which is either an integer (in a certain range) or an integer plus 0.5? What is more, the valid values of one field often depend on the actual value of one or more other fields, and so you end up designing a whole (functional) programming language. But in general we expect JSON to be consumed by a program written in some such language anyway. So we might as well decode all numbers as double floats, since you can only count on that much precision and range anyway, and leave subtypes of number to general-purpose validation. By the same token, I don't see that it makes sense to put a whole regular expression subsystem into the validator when it can often be expressed much more clearly in code (especially in languages that have a combinator rather than a string representation of regular expressions). Actually, I'll amend my proposal to inclde integers, given how important they are. This is easily accomplished by using, say, 0 (equivalently 0.0) to designate an integer and 0.5 to designate a float.) Using JSON itself as the language for the schema is nice because > you don't need to build a partser for the schema. But it's not very > nice for users, so I'd prefer to have some non-JSON syntax for the > schema. > I don't care about the syntax, but examplotron-style (in which a type designation is an instance of what it designates) is a strong design constraint, which is why I adopted it. I have no problem with a BNF-style syntax for practical use, like RNG compact syntax. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org Assent may be registered by a signature, a handshake, or a click of a computer mouse transmitted across the invisible ether of the Internet. Formality is not a requisite; any sign, symbol or action, or even willful inaction, as long as it is unequivocally referable to the promise, may create a contract. --Specht v. Netscape --00000000000061f95a058a1a6434 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    =
    On Wed, May 29, 2019 at 4:24 PM Nico = Williams <nico@cryptonector.com= > wrote:

    =C2=A0- if, where you expec= t an array you see a boolean, that's an error

    =
    Agreed,, because statically typed programming languages can'= t cope.
    =C2=A0
    - where you expect a numeric value you might have some constraints
    =C2=A0 =C2=A0(e.g., range constraints) that, again, should raise an error i= f not
    =C2=A0 =C2=A0met

    =C2=A0- ditto strings ('must be bas64', 'must be on= e of these (enum)', 'must
    =C2=A0 =C2=A0match some regexp', e= tc.).

    The question is, where do you stop?= =C2=A0 Range constraints are all very well,
    but suppose you want = to constrain a number value to be a U.S shoe size,
    which is eithe= r an integer (in a certain range) or an integer plus 0.5?
    What is= more, the valid values of one field often depend on the actual
    v= alue of one or more other fields, and so you end up designing a whole
    =
    (functional) programming language.

    But in gen= eral we expect JSON to be consumed by a program written
    in some s= uch language anyway.=C2=A0 So we might as well decode all numbers
    as double floats, since you can only count on that much precision and
    range anyway, and leave subtypes of number to general-purpose validat= ion.
    By the same token, I don't see that it makes sense to pu= t a whole
    regular expression subsystem into the validator when it= can often
    be expressed much more clearly in code (especially in = languages
    that have a combinator rather than a string representat= ion of
    regular expressions).

    Actually, I= 'll amend my proposal to inclde integers, given how
    important= they are.=C2=A0 This is easily accomplished by using, say,
    0 (eq= uivalently 0.0) to designate an integer and 0.5 to designate a float.)

    Using JSO= N itself as the language for the schema is nice because
    you don't need to build a partser for the schema.=C2=A0 But it's no= t very
    nice for users, so I'd prefer to have some non-JSON syntax for the
    schema.

    I don't care about the synt= ax, but examplotron-style (in which a
    type designation is an inst= ance of what it designates) is a strong
    design constraint, which = is why I adopted it.=C2=A0 I have no problem
    with a BNF-style syn= tax for practical use, like RNG compact syntax.

    John Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://vrici.lojban.org/~cowan =C2=A0 =C2=A0 = =C2=A0 =C2=A0cowan@ccil.org
    Assent= may be registered by a signature, a handshake, or a click of a computermouse transmitted across the invisible ether of the Internet. Formalityis not a requisite; any sign, symbol or action, or even willful inaction,<= br>as long as it is unequivocally referable to the promise, may create a co= ntract.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0--Specht v. Netscape
    --00000000000061f95a058a1a6434-- From nobody Thu May 30 06:08:59 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 DB3571200F6 for ; Thu, 30 May 2019 06:08:57 -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, 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=ccil-org.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 usAzTznnO3mP for ; Thu, 30 May 2019 06:08:56 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 049C81200B5 for ; Thu, 30 May 2019 06:08:55 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id u11so5517444otq.7 for ; Thu, 30 May 2019 06:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sHd9pZ6qB/viA+B2LzkowTVyZULbf24hrit+VJWAldQ=; b=gGInIpivE1Z0hclOSObYUZHnahfNwJTJDJbM3kg94NddjypkUlMOXLU0uv9w2NFN0q lQsze34wxebgNBbtMXh8oGSb6aZDlgjSwm5pScbaF5mbtKFCaYHbqkgAMam/4fUVVNGW rbkRjMrSbaAYU+a2u4GNzFf3rr++qbnn5m/YgLFogO/XvKGpawJW3Obtk/NwNhXzaaJz bfSwjJnuYt8oS1pmil45WYsSrTDq8ghWZa7X8wj9OIiPNSME2mSvk3uB23gEyvUu6FUI rtxT0c2Onht+yJ+KjhhCEFYy9hMmTqDj/90TQpxVpn9sz3XjECin6n3w7YWchQeuxlBb 6fOw== 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=sHd9pZ6qB/viA+B2LzkowTVyZULbf24hrit+VJWAldQ=; b=eEspiD6DtpWM0xKQutKKquH9nYHZcyv6Vej02w2ELrUCpFburjmA6mYBcE5xWoW/a0 IAfa1ccbJF4rrbD8zpf55itZ4hNff/jM92d04Z8DkUolyi7JRHvf+FWoKteFkZGdn9kG 5/QcfW1xCUUxSJVee727GjfpgjZ+VZXCzQgMyU1R1pLva8mDyufYqGFJwED1hopPzlgn 6bhO+06WlRB/y3+EQRTTZm2ktSdXTYfVIN1DhuG82+5hqNluF4LWg521QX0BxjBk+xGg eQyF0RNwDHM37Kkps0/jexx8Z/Fp7Ari5LdMzJ+NIPTKwsY2BRJKNV4tuW76sl39OAEb /Yww== X-Gm-Message-State: APjAAAWOf1Lmr31Wo7tTKVMmrt6TdhdC07pW45FaEzAt7+IVi3F7HHVk r4I5EjdD7uXvI83jeEgdDRd2SVoqoEFjGdZsXEhcDw== X-Google-Smtp-Source: APXvYqxb+792MoOn27u/2+vfGQqI+91ZDNRz3ZrcliLmRGW21o+1E2DwcsdGgA6VCLJeZI7OpjkH9/SueGeVMEi6dRw= X-Received: by 2002:a9d:538b:: with SMTP id w11mr2615122otg.154.1559221735241; Thu, 30 May 2019 06:08:55 -0700 (PDT) MIME-Version: 1.0 References: <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> <20190529144005.GC11773@localhost> <20190529201716.GD11773@localhost> In-Reply-To: From: John Cowan Date: Thu, 30 May 2019 09:08:44 -0400 Message-ID: To: Carsten Bormann Cc: Nico Williams , Tim Bray , JSON WG , Ulysse Carion , Rob Sayre Content-Type: multipart/alternative; boundary="000000000000a7d6b5058a1a9987" Archived-At: Subject: Re: [Json] A minimal examplotron-style JSON validation language. 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, 30 May 2019 13:08:58 -0000 --000000000000a7d6b5058a1a9987 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 29, 2019 at 5:15 PM Carsten Bormann wrote: > While it is certainly enjoyable to design another language, I cheerfully admit to that motive. > I=E2=80=99m not sure why this should not be done in an ABNF-like syntax such as CDDL (which, by the way, is in AUTH48 and will soon be RFC 8610). Keeping your names (even the snake case, where I=E2=80=99d be using kebab c= ase): > My effort with this schema language is not to show that it can do something that other proposals cannot, but that it is the simplest thing that can possibly work for both dynamically and statically typed programming languages, and that everything else can and should be left to higher (inner) layers that do general-purpose validation. (Another example: a field that must be a "dictionary word" in the sense that it appears in a particular dictionary, whose contents may change over time. Implementing this in the schema language will require a database lookup capability oe perhaps the ability to call a web-services API.) Antoine St.-Exupery said: "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." ("Il semble que la perfection soit atteinte non quand il n'y a plus rien = =C3=A0 ajouter, mais quand il n'y a plus rien =C3=A0 retrancher.") That's what I'm strivin= g for. My design has the advantage of being easy to implement in any programming language, even Fortran. It is also "obvious", with nothing to debate except the syntax, because the answer to "Shall we include this or that feature?" is almost always "No." Another amendment: [] is the type definition of a polymorphic array, as {} is the type signature of a polymorphic object. --000000000000a7d6b5058a1a9987 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    =
    On Wed, May 29, 2019 at 5:15 PM Carst= en Bormann <cabo@tzi.org> wrote:<= br>
    =C2=A0
    While it is certainly enjoyable to design another language,

    I cheerfully admit to that motive.
    =C2=A0
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">=C2=A0I=E2=80=99m not sure= why this should not be done in an ABNF-like syntax=C2=A0such as CDDL (which, by the wa= y, is in AUTH48 and will soon be RFC 8610).=C2=A0=C2=A0 Keeping your names (even the snake case, where I=E2=80=99d be using kebab c= ase):

    My effort with this schema langua= ge is not to show that it can do something
    that other proposals c= annot, but that it is the simplest thing that can possibly
    work f= or both dynamically and statically typed programming languages,
    a= nd that everything else can and should be left to higher (inner) layers
    that do general-purpose validation.=C2=A0 (Another example: a field = that
    must be a "dictionary word" in the sense that it a= ppears in a particular
    dictionary, whose contents may change over= time.=C2=A0 Implementing this
    in the schema language will requir= e a database lookup capability oe
    perhaps the ability to call a w= eb-services API.)

    =C2=A0Antoine St.-Exupery said: = "A designer knows he has achieved perfection
    not when there = is nothing left to add, but when there is nothing left to take away."<= /div>
    ("Il semble que la perfection soit atteinte non quand il n&#= 39;y a plus rien =C3=A0 ajouter,
    mais quand il n'y a plus rie= n =C3=A0 retrancher.")=C2=A0 That's what I'm striving for.
    My design has the advantage of being easy to implement in any progra= mming
    language, even Fortran.=C2=A0 It is also "obvious"= ;, with nothing to debate except the syntax,
    because the answer t= o "Shall we include this or that feature?" is almost always "= ;No."

    Another amendment:=C2=A0 [] is the type= definition of a polymorphic array, as {} is the
    type signature o= f a polymorphic object.
    --000000000000a7d6b5058a1a9987-- From nobody Thu May 30 07:39:53 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 2F7D71201C3 for ; Thu, 30 May 2019 07:39: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 Srv3JCCrsSoi for ; Thu, 30 May 2019 07:39:42 -0700 (PDT) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBB0120199 for ; Thu, 30 May 2019 07:39:41 -0700 (PDT) Received: (qmail 26106 invoked from network); 30 May 2019 15:37:40 +0100 Received: from host86-138-183-130.range86-138.btcentralplus.com (HELO ?192.168.1.72?) (86.138.183.130) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 30 May 2019 15:37:40 +0100 To: John Cowan , Nico Williams Cc: JSON WG References: <8224451C-F21B-41E5-A834-A9005050CB1F@tzi.org> <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> <20190529144005.GC11773@localhost> <20190529201716.GD11773@localhost> From: Pete Cordell Message-ID: <8478bb16-b057-e3af-01f2-dd53a64efb2d@codalogic.com> Date: Thu, 30 May 2019 15:39:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.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] A minimal examplotron-style JSON validation language. 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, 30 May 2019 14:39:51 -0000 On 30/05/2019 13:53, John Cowan wrote: > On Wed, May 29, 2019 at 4:24 PM Nico Williams The question is, where do you stop?  Range constraints are all very well, > but suppose you want to constrain a number value to be a U.S shoe size, > which is either an integer (in a certain range) or an integer plus 0.5? The JCR solution to this type of problem is to be able to have an annotation that associates a URI with a primitive type to indicate it's internal format. e.g. "size" : @{format org.iso.shoe-size} string, (http://json-content-rules.org/drafts/json-content-rules-10.html#rfc.section.6.11.6) As far as JCR is concerned, this merely captures the format of the data. Whether it's the low-level validators job to validate the type or higher-layer functionality is a decision for the individual implementation's developer(s). Same with strings specified with regular expressions. The validator can just treat it as a string and leave it to a higher layer, or it can be a deluxe validator and check the pattern matches. (The latter might be more useful for a generic on-the-wire monitoring type scenario.) > What is more, the valid values of one field often depend on the actual > value of one or more other fields, and so you end up designing a whole > (functional) programming language. We had a play with that sort of thing. Mainly as a proof-of-concept that the extensibility enabled by JCR's feature had sufficient mileage in it. http://json-content-rules.org/drafts/draft-cordell-jcr-co-constraints-00.txt > But in general we expect JSON to be consumed by a program written > in some such language anyway.  So we might as well decode all numbers > as double floats, since you can only count on that much precision and > range anyway, and leave subtypes of number to general-purpose validation. > By the same token, I don't see that it makes sense to put a whole > regular expression subsystem into the validator when it can often > be expressed much more clearly in code (especially in languages > that have a combinator rather than a string representation of > regular expressions). In addition to code, I think a key 'parser' of schemas is human developers. That's why we wanted JCR compact and concise. If the human developer is able to immediately see the constraints in the schema, and not have to wade through pages of prose, I think things are likely to work much better. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Thu May 30 11:28:34 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 E7D331202A9 for ; Thu, 30 May 2019 11:28:32 -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, 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=cryptonector.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 5jrfYcS8Eylr for ; Thu, 30 May 2019 11:28:30 -0700 (PDT) Received: from gecko.birch.relay.mailchannels.net (gecko.birch.relay.mailchannels.net [23.83.209.66]) (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 8450D1202A5 for ; Thu, 30 May 2019 11:28:30 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8DC315E31BF; Thu, 30 May 2019 18:28:29 +0000 (UTC) Received: from pdx1-sub0-mail-a68.g.dreamhost.com (100-96-89-88.trex.outbound.svc.cluster.local [100.96.89.88]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6ABAC5E31D9; Thu, 30 May 2019 18:28:28 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a68.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Thu, 30 May 2019 18:28:29 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Trade-Well-Made: 43fb653d1762f605_1559240909339_3478523510 X-MC-Loop-Signature: 1559240909339:801285633 X-MC-Ingress-Time: 1559240909338 Received: from pdx1-sub0-mail-a68.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a68.g.dreamhost.com (Postfix) with ESMTP id 525247FC9D; Thu, 30 May 2019 11:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=UTHiRSI/SAvOQB v+BvXBG8EOAHQ=; b=QPiQT2WxOIAAZkaP6fvtlQl66FzZk781hvdw9RtEvNQ2IN WbhrCMI8G6nCulBE+T3FmCXHy098oD9QKr/dUuvysS/AKCNsYQE5Xj6E2/1SJafK iZCkN0qswJLHLullK9m0Ge+X8JkxKM/qpegGMk/Q2gTbvB1goCXtOK5L70DAw= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a68.g.dreamhost.com (Postfix) with ESMTPSA id E81BF7FC84; Thu, 30 May 2019 11:28:20 -0700 (PDT) Date: Thu, 30 May 2019 13:16:51 -0500 X-DH-BACKEND: pdx1-sub0-mail-a68 From: Nico Williams To: John Cowan Cc: Tim Bray , JSON WG , Carsten Bormann , Ulysse Carion , Rob Sayre Message-ID: <20190530181650.GE11773@localhost> References: <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> <20190529144005.GC11773@localhost> <20190529201716.GD11773@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddvledguddviecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Json] A minimal examplotron-style JSON validation language. 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, 30 May 2019 18:28:33 -0000 On Thu, May 30, 2019 at 08:53:50AM -0400, John Cowan wrote: > On Wed, May 29, 2019 at 4:24 PM Nico Williams wrote: > - if, where you expect an array you see a boolean, that's an error > > > > Agreed,, because statically typed programming languages can't cope. And dynamic typing sucks. > The question is, where do you stop? Range constraints are all very well, > but suppose you want to constrain a number value to be a U.S shoe size, > which is either an integer (in a certain range) or an integer plus 0.5? You start with what you need and add new constraints as you discover they would be useful. > What is more, the valid values of one field often depend on the actual > value of one or more other fields, and so you end up designing a whole > (functional) programming language. ASN.1 has SDL, but no one uses it. It turns out that SEQUENCE OF/ SEQUENCE/CHOICE is enough to avoid having to add an actual programming language to do much more validation, with "business logic" getting written as natural language text in a spec. Mind you, I wouldn't mind a language for this, but it's a lot of work to expect the IETF to do, so I wouldn't bother. If there were enough interest (there won't be), I suppose we could take inspiration from jq (which is a functional programming language built around JSON) and write an RFC for it or a language inspired by it. > But in general we expect JSON to be consumed by a program written > in some such language anyway. So we might as well decode all numbers Exactly. > as double floats, since you can only count on that much precision and > range anyway, and leave subtypes of number to general-purpose validation. I wasn't proposing that numerics get decoded as whatever the schema says. Rather, that if you have a stack that uses a generic JSON decoder then a validation pass might validate and coerce numeric values to integers/whatever as needed. > By the same token, I don't see that it makes sense to put a whole > regular expression subsystem into the validator when it can often > be expressed much more clearly in code (especially in languages > that have a combinator rather than a string representation of > regular expressions). It's perfectly fine for us to decide we don't need that feature. > Actually, I'll amend my proposal to inclde integers, given how > important they are. This is easily accomplished by using, say, > 0 (equivalently 0.0) to designate an integer and 0.5 to designate a float.) Again, if we have consensus for such a contraint, we should include it, and if not, not. I was not making a detailed proposal, just proposing that a schema language should be built around types and user-defined types -- just like ASN.1. > > Using JSON itself as the language for the schema is nice because > > you don't need to build a partser for the schema. But it's not very > > nice for users, so I'd prefer to have some non-JSON syntax for the > > schema. > > I don't care about the syntax, but examplotron-style (in which a > type designation is an instance of what it designates) is a strong > design constraint, which is why I adopted it. I have no problem > with a BNF-style syntax for practical use, like RNG compact syntax. The point about defining types is that you can express recursive nesting, which is harder to do with by-example schemas. Nico -- From nobody Thu May 30 20:54: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 DAFFC120025 for ; Thu, 30 May 2019 20:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ccil-org.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 a8Z1pf77IQvm for ; Thu, 30 May 2019 20:53:59 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0: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 B2B00120019 for ; Thu, 30 May 2019 20:53:59 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id g18so7804437otj.11 for ; Thu, 30 May 2019 20:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jOBoe3lLQvRPyorcBCLrgbc/LXMVw/kgZqIP5DDOy/Y=; b=ULImT4y/SDsJ1bpCf14Q2pNJscH3jBwSiQHtcRP4X0/TiSJH2DmfoEmLowXuIuwZJt hguuLx1Ncmcr1sXG9pFK7PWn9Hsk5B1odPE46ElwLY0WI9RGcqyYh75x6Pd6jcuRoU4P jJvoSn3oUZiHXXlkKs31e5yG0EgqBjdvtxaCVwbiHMhOIm8l4pxy3ZOHioDCuGxOtxYp QPEC63/RedAMt00ufx7EoMpp3dSjKXCjjz5DyRauF++NXpVa+tPupqbFIdzD4xKfxPPv gxS3gifAM2LsqnKt+T894ThrLP/jN0rZbZu8bTNHqxbbod+ZhcH33KNO/dmWkVGUarZx 1ubw== 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=jOBoe3lLQvRPyorcBCLrgbc/LXMVw/kgZqIP5DDOy/Y=; b=jBOJY6ALEz8OCIHcEqmOweNhPb4B37S6R8CxBRedldtoUbnqnEuSLmI7i4WwME5+tE nxrrcdfYp359bPXf9wKIjnYKUtSUlWSBy+/WkBk0XayYo6GtpTkzkjIDcG/9Qf8pmfIx Kmjm9O0b4fAA8O43uUKGmrm9a14t3GzdbJSAzTGwQWlJenOAcqBNSn9J7JKOToM94+N3 3hvNbfp/loWzbUm1rXoxhoP84AnFrPvsqTb6ky92axyjaUEWBcod7wFcX9gH2gURcsTf aIwlr39vCfFyB3uNThHu1eGdHAQPpBgAQ4HDbEzPzq7hZGw4p4YCdB+j09BaJkESBQiV sRxw== X-Gm-Message-State: APjAAAV033nSquk0NI11nDyCsnTKcVXMRovrBjo5WYWm5wG6VekWYUrV OhoH/LZEAwydlOgsPu9+SikXf6JjBnMf+tFXLDtJAw== X-Google-Smtp-Source: APXvYqxZlGyPKrycdiMzu7rILrBr+wRHcc20ozVBk3YuluOQK3RWOpRc5oHPKR9tzxkjr4js1Viq1dYeegT2ZNwsy5U= X-Received: by 2002:a9d:5c8d:: with SMTP id a13mr102910oti.327.1559274839002; Thu, 30 May 2019 20:53:59 -0700 (PDT) MIME-Version: 1.0 References: <11CDA7F6-30BB-40E4-8926-2EDCBCFD785B@tzi.org> <20190529144005.GC11773@localhost> <20190529201716.GD11773@localhost> <20190530181650.GE11773@localhost> In-Reply-To: <20190530181650.GE11773@localhost> From: John Cowan Date: Thu, 30 May 2019 23:53:48 -0400 Message-ID: To: Nico Williams Cc: Tim Bray , JSON WG , Carsten Bormann , Ulysse Carion , Rob Sayre Content-Type: multipart/alternative; boundary="000000000000e2ea0a058a26f618" Archived-At: Subject: Re: [Json] A minimal examplotron-style JSON validation language. 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, 31 May 2019 03:54:02 -0000 --000000000000e2ea0a058a26f618 Content-Type: text/plain; charset="UTF-8" On Thu, May 30, 2019 at 2:28 PM Nico Williams wrote: > And dynamic typing sucks. > I certainly don't think so. Not that I think static typing sucks either. Dynamically typed languages are statically typed languages with only one static type. > You start with what you need and add new constraints as you discover > they would be useful. > Okay, I'm proposing starting with *no* scalar constraints, only constraints on the types of array elements and object elements. > Again, if we have consensus for such a contraint, we should include it, > and if not, not. It's needed because essentially all statically typed languages treat ints and floats as disjoint types. That's not a good thing, but we are stuck with it de facto. > The point about defining types is that you can express recursive > nesting, which is harder to do with by-example schemas. > Without conditional types, there can be no finite recursion. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org De plichten van een docent zijn divers, die van het gehoor ook. --Edsger Dijkstra --000000000000e2ea0a058a26f618 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    =
    On Thu, May 30, 2019 at 2:28 PM Nico = Williams <nico@cryptonector.com= > wrote:
    =C2=A0
    And dynamic typing sucks.

    <= div>I certainly don't think so.=C2=A0 Not that I think static typing su= cks either.=C2=A0 Dynamically typed languages are statically typed language= s with only one static type.
    =C2=A0
    You start with what you need and add new constrai= nts as you discover
    they would be useful.

    Okay, I'm pro= posing starting with *no* scalar constraints, only constraints on the types= of array elements and object elements.
    =C2=A0
    Again, if we have consensus for such a= contraint, we should include it,
    and if not, not.

    It's needed because es= sentially all statically typed languages treat ints and floats as disjoint = types.=C2=A0 That's not a good thing, but we are stuck with it de facto= .
    =C2=A0
    The point about defining types is that you can express recursive
    nesting, which is harder to do with by-example schemas.

    Without conditional types, there can be no finite recursio= n.


    John Cowan =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0http://vrici.lojban= .org/~cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0cowan@ccil.org
    De plichten van een docent zijn divers, die van het= gehoor ook.
    =C2=A0 =C2=A0 =C2=A0 --Edsger Dijkstra

    --000000000000e2ea0a058a26f618-- From nobody Thu May 30 20:57:38 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 0709E120025 for ; Thu, 30 May 2019 20:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=cryptonector.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 WPtzfbkfnCl1 for ; Thu, 30 May 2019 20:57:35 -0700 (PDT) Received: from goldenrod.birch.relay.mailchannels.net (goldenrod.birch.relay.mailchannels.net [23.83.209.74]) (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 F1426120019 for ; Thu, 30 May 2019 20:57:34 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 610658C2397; Fri, 31 May 2019 03:57:33 +0000 (UTC) Received: from pdx1-sub0-mail-a41.g.dreamhost.com (100-96-89-88.trex.outbound.svc.cluster.local [100.96.89.88]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id F08618C22D8; Fri, 31 May 2019 03:57:29 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a41.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Fri, 31 May 2019 03:57:33 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Trouble-Shelf: 45986add2a8db1b7_1559275053228_109809081 X-MC-Loop-Signature: 1559275053227:4121499219 X-MC-Ingress-Time: 1559275053227 Received: from pdx1-sub0-mail-a41.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a41.g.dreamhost.com (Postfix) with ESMTP id AD3AF8002E; Thu, 30 May 2019 20:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Fejz47QlmZAlrd uc1U3GyJsYplg=; b=Hddh3mD7vcJvcfVp9TgyWVaU8ixj14K+bNTxGK0ctnTHmn AZcFElziqfHjGScni0c0AuTrEpUiojzsxuUtQdXy+N7lEv2U/ja1nhiSwoo0pvA7 rwZUUMF2MRJvtqoaoFYxMaEnIQbEQkpeINu/CWzMFza87bTYxkxOsDI4LYryg= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a41.g.dreamhost.com (Postfix) with ESMTPSA id 465E98002C; Thu, 30 May 2019 20:57:22 -0700 (PDT) Date: Thu, 30 May 2019 22:53:03 -0500 X-DH-BACKEND: pdx1-sub0-mail-a41 From: Nico Williams To: John Cowan Cc: Tim Bray , JSON WG , Carsten Bormann , Ulysse Carion , Rob Sayre Message-ID: <20190531035302.GF11773@localhost> References: <20190529144005.GC11773@localhost> <20190529201716.GD11773@localhost> <20190530181650.GE11773@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrudeftddgjeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Json] A minimal examplotron-style JSON validation language. 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, 31 May 2019 03:57:37 -0000 On Thu, May 30, 2019 at 11:53:48PM -0400, John Cowan wrote: > On Thu, May 30, 2019 at 2:28 PM Nico Williams wrote: > > You start with what you need and add new constraints as you discover > > they would be useful. > > Okay, I'm proposing starting with *no* scalar constraints, only constraints > on the types of array elements and object elements. I can live with that. > > Again, if we have consensus for such a contraint, we should include it, > > and if not, not. > > It's needed because essentially all statically typed languages treat ints > and floats as disjoint types. That's not a good thing, but we are stuck > with it de facto. JSON doesn't distinguish between "ints" and "floats", so if you want that distinction then you're asking for constraints on the numeric scalar type. > > The point about defining types is that you can express recursive > > nesting, which is harder to do with by-example schemas. > > Without conditional types, there can be no finite recursion. Conditional here means "may be present" vs "must be present". That's obviously necessary. Nico -- From nobody Fri May 31 09:03:10 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 70B6E1200FE for ; Fri, 31 May 2019 09:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=ccil-org.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 ysHlvIPubO_o for ; Fri, 31 May 2019 09:03:05 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 9859812013C for ; Fri, 31 May 2019 09:03:05 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id e189so1359706oib.11 for ; Fri, 31 May 2019 09:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DZXde8OmbyUmumCQF8Pj9Wh2Pj0T+/TMHZmq6uUk23o=; b=XFpTpD0nbIUO+Lc7mxnUDlR8z/2xW6N0rYP3YdxTrI8pjUe7m+1EmxLIAjYEQLllJs 68zuJCxpVDCTnP6tddgOowHnHpKqwy/8oCauygKaWsPMlhSsCQNE3MRfcccg/GO+ksrA 1QbacYU7gR/sHtD+1kMRS7PWO9/yD66N4OAMyAaov/UY+dQSwKCgTFWKCRHnqFGxziE7 ahd3HzgJ1qdT9YnpgI5ipdGs6g9islnNVimT2A9z+O1sVb/LYLqvEpRw0HZeA0O6Ve6l YM7S3u7W3oCwrGWAPlpY+45TxnerdV0j6GUJrD/qdCCfeipRsfKHUXgaY2Uh+NI+ErbQ kFGg== 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=DZXde8OmbyUmumCQF8Pj9Wh2Pj0T+/TMHZmq6uUk23o=; b=YqJ1PJ8N8ciV+ZvJR/Y10vq7LWwwySKe5DldWt7pR3pAZSFuoT8Y5DZOmPYQq7dJMh Vv+UUab5zTJOUPKPb9/2dvomPVMUxx2r+Iecb3QT1kVtvfy+UwJ/fcLymkMKdqVOKamg szREcoVaeBLaUbUqgPYB+fWl1M5eDIeJjI7MySsAo4XKwpi5D9Tw9iqu5wkjo8GSC8ci nT9v31VaXDVyJ9Vr1w/i+IIlpn169xD/0Q8IFyUh7LSABssbKAMVysXNk0VZfc5ojTqw WI445zBH2MyZIDhCCVyPt6GrNEQpt+ScrGuo18HPEeb6igwi2GqeiD6RmVMC5UmYn6l3 2b1w== X-Gm-Message-State: APjAAAVR6AEekE4wiVVcXY3B5XcXTah06IVlKLZPWYzYo6xgdM5hHSLT X+uXSEdt2gKKR+/S8Aw5gg/aDHfPixwKtRgl7ZEBiA== X-Google-Smtp-Source: APXvYqyJgNOn8MABFXZvAhKlnF3BHGuf2XjUT9q0ct9s0pIDYT9u2UUrJRht0dbjaI7KDcQfX3zutPg/gsfGsJ66A0w= X-Received: by 2002:aca:de04:: with SMTP id v4mr6360410oig.162.1559318584749; Fri, 31 May 2019 09:03:04 -0700 (PDT) MIME-Version: 1.0 References: <20190529144005.GC11773@localhost> <20190529201716.GD11773@localhost> <20190530181650.GE11773@localhost> <20190531035302.GF11773@localhost> In-Reply-To: <20190531035302.GF11773@localhost> From: John Cowan Date: Fri, 31 May 2019 12:02:54 -0400 Message-ID: To: Nico Williams Cc: Tim Bray , JSON WG , Carsten Bormann , Ulysse Carion , Rob Sayre Content-Type: multipart/alternative; boundary="0000000000005605ae058a3126cf" Archived-At: Subject: Re: [Json] A minimal examplotron-style JSON validation language. 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, 31 May 2019 16:03:08 -0000 --0000000000005605ae058a3126cf Content-Type: text/plain; charset="UTF-8" On Thu, May 30, 2019 at 11:57 PM Nico Williams wrote: JSON doesn't distinguish between "ints" and "floats", so if you want > that distinction then you're asking for constraints on the numeric > scalar type. > Okay, just one constraint. It's a concession to the behavior of statically typed languages right back to Fortran ("God is real unless explicitly declared integer"). Leaving that to inner layers means that everything has to be deserialized into floats and then deep-copied into objects whose fields are integers. Conditional here means "may be present" vs "must be present". That's > obviously necessary. > I don't mean that kind of conditional. I mean alternative, where an object value or array element can be of type "foo" or type "bar". If that's not allowed (as it is not in my proposal), then recursive schemas can only be satisfied by infinitely large JSON values. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org weirdo: When is R7RS coming out? Riastradh: As soon as the top is a beautiful golden brown and if you stick a toothpick in it, the toothpick comes out dry. --0000000000005605ae058a3126cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    =
    On Thu, May 30, 2019 at 11:57 PM Nico= Williams <nico@cryptonector.co= m> wrote:

    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">JSON doesn't distingui= sh between "ints" and "floats", so if you want
    that distinction then you're asking for constraints on the numeric
    scalar type.

    Okay, just one constraint.= =C2=A0 It's a concession to the behavior of statically typed
    = languages right back to Fortran ("God is real unless explicitly declar= ed integer").
    Leaving that to inner layers means that everyt= hing has to be deserialized into floats
    and then deep-copied into= objects whose fields are integers.

    Conditional here means "may be presen= t" vs "must be present".=C2=A0 That's
    obviously necessary.

    I don't mean t= hat kind of conditional. I mean alternative, where an object
    valu= e or array element can be of type "foo" or type "bar".= =C2=A0 If that's not allowed
    (as it is not in my proposal), t= hen recursive schemas can only be satisfied
    by infinitely large J= SON values.


    John Cowan =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0http://v= rici.lojban.org/~cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0cowan@ccil.org
    weirdo: =C2=A0 =C2=A0When is R7RS coming= out?
    Riastradh: As soon as the top is a beautiful golden brown and if y= ou
    stick a toothpick in it, the toothpick comes out dry.
    <= br>
    --0000000000005605ae058a3126cf-- From nobody Fri May 31 11:20: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 9741C12032F for ; Fri, 31 May 2019 11:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=cryptonector.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 lorIUu_CTXme for ; Fri, 31 May 2019 11:20:38 -0700 (PDT) Received: from lavender.maple.relay.mailchannels.net (lavender.maple.relay.mailchannels.net [23.83.214.99]) (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 4128C120328 for ; Fri, 31 May 2019 11:20:38 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 493422C171E; Fri, 31 May 2019 18:20:37 +0000 (UTC) Received: from pdx1-sub0-mail-a80.g.dreamhost.com (100-96-85-75.trex.outbound.svc.cluster.local [100.96.85.75]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id DE0182C12F4; Fri, 31 May 2019 18:20:35 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a80.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Fri, 31 May 2019 18:20:37 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Eight-Thoughtful: 1ac7aeff6db11438_1559326837117_1871183696 X-MC-Loop-Signature: 1559326837116:1737575236 X-MC-Ingress-Time: 1559326837116 Received: from pdx1-sub0-mail-a80.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a80.g.dreamhost.com (Postfix) with ESMTP id 115F9801C0; Fri, 31 May 2019 11:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=mf7QdN33G5w3LN tfp2pNk2EZ0c8=; b=tLvy2qsVgvrkjs3tx/TgWz9YmDIO/M48ky4ilkCMKEeCz9 AmcY8mHpXDY34wxLwcU57SLv9qJUth971Kvk7GQE8yGVGEtW4PsNmW8AG5phzLqV cAWhlKD3b0XgigLhqMsu7XAzhyhdTkVZxiPSs+oujSfLJIEijANEAdgCLAkhg= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a80.g.dreamhost.com (Postfix) with ESMTPSA id 5416C801CF; Fri, 31 May 2019 11:20:32 -0700 (PDT) Date: Fri, 31 May 2019 13:15:05 -0500 X-DH-BACKEND: pdx1-sub0-mail-a80 From: Nico Williams To: John Cowan Cc: Tim Bray , JSON WG , Carsten Bormann , Ulysse Carion , Rob Sayre Message-ID: <20190531181504.GG11773@localhost> References: <20190529144005.GC11773@localhost> <20190529201716.GD11773@localhost> <20190530181650.GE11773@localhost> <20190531035302.GF11773@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrudefuddguddvjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [Json] A minimal examplotron-style JSON validation language. 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, 31 May 2019 18:20:42 -0000 On Fri, May 31, 2019 at 12:02:54PM -0400, John Cowan wrote: > On Thu, May 30, 2019 at 11:57 PM Nico Williams > wrote: > > JSON doesn't distinguish between "ints" and "floats", so if you want > > that distinction then you're asking for constraints on the numeric > > scalar type. > > Okay, just one constraint. [...] :) > > Conditional here means "may be present" vs "must be present". That's > > obviously necessary. > > I don't mean that kind of conditional. I mean alternative, where an object > value or array element can be of type "foo" or type "bar". If that's not > allowed (as it is not in my proposal), then recursive schemas can only > be satisfied by infinitely large JSON values. That's a union / discriminated union. (CHOICE, in ASN.1.) There's been nothing really new in this field since ASN.1... XDR [RFC4506] is akin to a greatly simplified ASN.1, so it's much more accessible and relevant to JSON. Unfortunately XDR conflates "syntax" for specifying schema and "encoding rules", and for JSON we only need "syntax" for specifying schema. But we could read RFC4506 for just the syntax and I think that might prove useful here. Nico --