From nobody Thu Aug 1 09:09: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 D4653120247 for ; Thu, 1 Aug 2019 09:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.102 X-Spam-Level: *** X-Spam-Status: No, score=3.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 VFAZg7K3uyaK for ; Thu, 1 Aug 2019 09:09:06 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 D17771201DA for ; Thu, 1 Aug 2019 09:09:05 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id g67so59604750wme.1 for ; Thu, 01 Aug 2019 09:09: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=bZhITEQ7iL1fnt4CQHHiKRHaeIXUKJKd/TO9ErkUGJI=; b=ZpXCFxlXmrXohnT0aQKPDhmyT5fz1XvJ099kl05tj+s3UUjmQm+gi1YGpz4G8/jeqM 9l9EMr+zuUH4zbcE4sL98jv996meDu0u5zAJKybQjEU4Vh+JZbJm/cacOlnhMZh4OZ+d rTtKAxfOpHJUqPTrbicDuXgJzdcxdP9uwbZu1Rvm/FdM/wN+sqhxe4XxlVe6IMRhE/Va vaM5adxCrFgP02Rhe1uVZbEyRy3qKwRe15IdC4mXaj228nQaA8ZmCxSrlA8IWTjxTPlx ozFhYdAp37B4ASsMYb5q21ZX9BN+lG743HoGhk+LgrIgAnHKVLNk9Lzo4XhA1R++2cjz 6K4Q== 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=bZhITEQ7iL1fnt4CQHHiKRHaeIXUKJKd/TO9ErkUGJI=; b=Orw4H6tmT4UJASJmaWE+6MJ+aGS1msNbxDj3bA2jaZb9T6MT8he18v4r1oqg8mzUgJ 4xkCzo6t/B5kPq/iOYQAxW1DKO1nrtf+X4Mfj6DTgdxaXpc79lH+9llSRZdH6iyzjPH6 S3BGntSA/DJ8g0tkGiyTDaG/HIWlcLsaRvTtrc9EESLel4zLTt/SJypLAGDoXyPT2Br5 M2BIHx+4QzspPwqk233ikkKqdI7Wb1oKMkjapmnPc4W6CY1BLauazzT5Zal+2O/EELaV 3cKT7F62PydfYmtR4My6LKxbn2qMYH/1EWWyAmnmw/yxjBldlf+tm0kLC+QOk75CB8Df dQkg== X-Gm-Message-State: APjAAAXiERVNdUKicQwWPiWWtVdWHqx7IjY0nq7o0AZlaBUTWatDZW8C Rhkqi1OD6Raj2MbTJ/BiqCW4JG9foFt0RbowNblmHw== X-Google-Smtp-Source: APXvYqxMQpQG0EoKgcZmQUttnKlV8K3bhJEqwnNbDTbqjnqrsDY5RFP/QbkoNVbjyWDZh/TZCKoTlQOAe+4DubbvDQU= X-Received: by 2002:a1c:9cd1:: with SMTP id f200mr114226257wme.157.1564675744275; Thu, 01 Aug 2019 09:09:04 -0700 (PDT) MIME-Version: 1.0 References: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com> In-Reply-To: From: John Cowan Date: Thu, 1 Aug 2019 12:08:53 -0400 Message-ID: To: Ulysse Carion Cc: Anders Rundgren , "Manger, James" , JSON WG Content-Type: multipart/alternative; boundary="000000000000ed3427058f10752b" Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 16:09:14 -0000 --000000000000ed3427058f10752b Content-Type: text/plain; charset="UTF-8" On Wed, Jul 31, 2019 at 11:55 PM Ulysse Carion wrote: The same goes for monetary data types. There are too many options, and it's > better for the spec to stick to relatively uncontroversial things. > Monetary amounts need to be represented as JSON strings, or your auditors will be down on you like a ton of bricks. The sum of ten 0.1 values is 0.9999999999999999, not 1.0, assuming the float64 interpretation that essentially all JSON readers assign to JSON numbers. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org If you have ever wondered if you are in hell, it has been said, then you are on a well-traveled road of spiritual inquiry. If you are absolutely sure you are in hell, however, then you must be on the Cross Bronx Expressway. --Alan Feuer, New York Times, 2002-09-20 --000000000000ed3427058f10752b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 31, 2019 at 11:55 PM Ulys= se Carion <ulysse@segment.com&= gt; wrote:

The same g= oes for monetary data types. There are too many options, and it's bette= r for the spec to stick to relatively uncontroversial things.

Monetary amounts need to be represented = as JSON strings, or your auditors will be down on you like a ton of bricks.= =C2=A0 The sum of ten 0.1 values is=C2=A00.9999999999999999, not 1.0, assum= ing the float64 interpretation that essentially all JSON readers assign to = JSON numbers.


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
If you have ever wondered if you are in = hell, it has been said, then
you are on a well-traveled road of spiritua= l inquiry.=C2=A0 If you are
absolutely sure you are in hell, however, th= en you must be on the Cross
Bronx Expressway. =C2=A0--Alan Feuer, New Yo= rk Times, 2002-09-20
--000000000000ed3427058f10752b-- From nobody Thu Aug 1 12:07:33 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 4697C120168 for ; Thu, 1 Aug 2019 12:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.803 X-Spam-Level: X-Spam-Status: No, score=0.803 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 r5HwVsKemwY3 for ; Thu, 1 Aug 2019 12:07:28 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC8712013D for ; Thu, 1 Aug 2019 12:07:28 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4600Cy3pyhz101B; Thu, 1 Aug 2019 21:07:26 +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, 1 Aug 2019 21:07:25 +0200 Cc: Ulysse Carion , JSON WG , "Manger, James" , Anders Rundgren X-Mao-Original-Outgoing-Id: 586379244.047909-0082d77ee9c906fc1b35346fc3d16429 Content-Transfer-Encoding: quoted-printable Message-Id: <5ECB215B-AA05-47AB-AC8F-F14A74A46FEE@tzi.org> References: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com> To: John Cowan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 19:07:30 -0000 On Aug 1, 2019, at 18:08, John Cowan wrote: >=20 > Monetary amounts need to be represented as JSON strings, or your = auditors will be down on you like a ton of bricks. =20 That is only true if you naively equate the interchange data model with = your application data model. There is nothing wrong with interchanging currency values as floating = point values if you properly process them on ingestion. Typically, you = multiply with a common denominator (such as 100 or 1000 [egyptian = pounds?, or US mills as in gasoline prices]) and round to the nearest = integer. > The sum of ten 0.1 values is 0.9999999999999999, not 1.0, assuming the = float64 interpretation that essentially all JSON readers assign to JSON = numbers. Right, you can=E2=80=99t *compute* with them as floating point values = (well, you can, but you need to be even more careful with the rounding). You still can *interchange* them as floating point values if you have = enough precision (binary32 notably doesn=E2=80=99t for most = applications; you really need binary64, and you are still limited to = applications that handle less than ~ 90 Microsofts or Apples a piece and = don=E2=80=99t need more internal decimal places at the same time). A data definition language could contain specific support for binary = floating point values used to encode decimal fractions; CDDL currently = doesn=E2=80=99t (but support could be added using its main extension = point: control operators). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 1 12:54: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 311BC1201D2 for ; Thu, 1 Aug 2019 12:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.002 X-Spam-Level: *** X-Spam-Status: No, score=3.002 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, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 5YhmXBBPFlP1 for ; Thu, 1 Aug 2019 12:54:32 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 4BE9E1201CF for ; Thu, 1 Aug 2019 12:54:32 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id p74so65742829wme.4 for ; Thu, 01 Aug 2019 12:54: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=jk2AafTvCbJ9EPcerKGhTeCg/utlm+5dH1LwbqA7Ca8=; b=tm6WrU7zO98cWkEu95f5FBgBVTp8hdYSbOo9I5+iJX3KcjK0zrqXz9zRCFz+6HcZoX TQaUrx9LR032ltXl1JufD7rEYzjSoSy72hIYOIYoNyw+lP3bb7vJHNucRheErRsp3UaJ WBVkeZe6xD6hNzBp0l3NWnpEiiz/nfzmffkDk9EFPn7gLKJurIwqHtAixgHBPjbfrgmw mA+jqPuj+F3SPa4p/2SCE6OVwgTD+NheXFN/YN0Ys6Uqy4PJFMpyyJpYcchGeOXQQuJO 847iJKOniAgGw5ZUYuZYYY2xR7Zjb3LJdYcWG/9gdnnuMTFOrJqHthfWciY7O+1peeHA LPag== 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=jk2AafTvCbJ9EPcerKGhTeCg/utlm+5dH1LwbqA7Ca8=; b=SJtcpXQEtUKXB+15k5jdunW99nipSowA2X9FQp1VlJcnjzzz0ZfkMXAu1SvLjCF676 ga6UkrfWY3CXrP6Um9fS9i/FUxxg/eWWZYXLVwsBCiCQSOsYnkhKV9YKyCiIPQ+uq2nI 2bqvJhXGAVAYfPoNURoCb4+PyEsjhZQQoXEs3apvO4KWJUWpPiPkX+XxUlvorNA17PA8 7rTmdoYfWIDDCopAsAseHao6ezQgRdzFIk0ps5k62Kt1JCI0m8GYEPdOAdodYLrsrxkh p6OvN0nHSUO9bpLKJy4mETfnIvcMdAJeDXRhEbOllDP4i/IGvchnJ9GbfAm+ufwPjk1M CY7A== X-Gm-Message-State: APjAAAWlNiH6NALk4hnNP5kmVWZTxGaKOShuc4rme2jtoE51PWDk2raB utehiIrvZbhKhB64E9gwYq8= X-Google-Smtp-Source: APXvYqxKq3nEMQ2kcGyAuz7TFF/qgWa8Y/CjHoqNALLuOuchL2ID8gLzd25R9H5NLozI8AuB/1vB8Q== X-Received: by 2002:a1c:7e85:: with SMTP id z127mr294625wmc.95.1564689270725; Thu, 01 Aug 2019 12:54: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 j33sm156524141wre.42.2019.08.01.12.54.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Aug 2019 12:54:29 -0700 (PDT) To: Carsten Bormann , John Cowan Cc: Ulysse Carion , JSON WG , "Manger, James" References: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com> <5ECB215B-AA05-47AB-AC8F-F14A74A46FEE@tzi.org> From: Anders Rundgren Message-ID: Date: Thu, 1 Aug 2019 21:54:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <5ECB215B-AA05-47AB-AC8F-F14A74A46FEE@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 is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 19:54:34 -0000 On 2019-08-01 21:07, Carsten Bormann wrote: > On Aug 1, 2019, at 18:08, John Cowan wrote: >> >> Monetary amounts need to be represented as JSON strings, or your auditors will be down on you like a ton of bricks. > > That is only true if you naively equate the interchange data model with your application data model. > > There is nothing wrong with interchanging currency values as floating point values if you properly process them on ingestion. Typically, you multiply with a common denominator (such as 100 or 1000 [egyptian pounds?, or US mills as in gasoline prices]) and round to the nearest integer. In this case there are standards that are interoperable with any JSON parser although you typically have to perform one or two additional operations in order to get the proper local representation: https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value We lucky guys(?) who build our own stuff have it natively: https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/json/JSONObjectReader.html#getMoney-java.lang.String-java.lang.Integer%2d mapped => "string" Anders > >> The sum of ten 0.1 values is 0.9999999999999999, not 1.0, assuming the float64 interpretation that essentially all JSON readers assign to JSON numbers. > > Right, you can’t *compute* with them as floating point values (well, you can, but you need to be even more careful with the rounding). > > You still can *interchange* them as floating point values if you have enough precision (binary32 notably doesn’t for most applications; you really need binary64, and you are still limited to applications that handle less than ~ 90 Microsofts or Apples a piece and don’t need more internal decimal places at the same time). > > A data definition language could contain specific support for binary floating point values used to encode decimal fractions; CDDL currently doesn’t (but support could be added using its main extension point: control operators). > > Grüße, Carsten > From nobody Thu Aug 1 21:40:14 2019 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D345E1200A1 for ; Thu, 1 Aug 2019 21:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PDqzfhD4F5Q for ; Thu, 1 Aug 2019 21:40:10 -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 91E40120074 for ; Thu, 1 Aug 2019 21:40:10 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id k8so149459359iot.1 for ; Thu, 01 Aug 2019 21:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jw+qdLBhyfGwqG4PmlJlYCO/zBm3CW+BRhBMdGEsodE=; b=gq6xqpJE37lmG8i0++5iC/WMYTZ5toznIzFBfPNFIFL7RMDc13Lge9WK5vc3J6onPv LdMFP4gxXcGRic8+dJXUi8DvDNgpu2opReW7tn9hh+X2AG8t9DEP/SFhLig8exzonQji 1h+chk+tUNCpPdq5F1nUyL3d2EwmcidTLhymA= 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=Jw+qdLBhyfGwqG4PmlJlYCO/zBm3CW+BRhBMdGEsodE=; b=QobNH/M2TEP+cuR92LE3HHIQbs3Nyq3sZs822/ROdMK4qw6pXjbQ2Bm+ihQufFy/zw U43pHVkdjgLz6bU24Uuyx03WxNtjz7YRdJ/JrdY6znnvuapTB4WAPRWy8DP7i31ssvIf GzwzzNL7PEgcXrK2OXJDwC+JPEDMZ9y4+LKglTD2SxSylllyiZVvmCL9rnx+dnIalVhU TyBzzpATZDgD+meMNK2A7QL4yRU5t0TLEf48Iv8Jy/lbehWBgj3uWYMfGS7nki87oN+3 GqVrK6+Y71ausUovnchUGZcGJVWHQNIEx4cvub2r0OEVCV5pMM7XE2DK8g3KuOEFnzS5 lClQ== X-Gm-Message-State: APjAAAVBopIYwYx4D/r/YfT0t2evFNJIl6O4R2tWoaDCcc4/tQ17vvHr YEgQIZ9uToLn6U8ipPJWJJihncT3lcc5/bVYHzY6Hg== X-Google-Smtp-Source: APXvYqwc5biyB5MmDlR4ptddGT2RF3MzKC/tnNsj1RAMn6wxAQy+mEMg5cptuI8QN39hIJNSRvEhXBPJBoLyiOIRSq4= X-Received: by 2002:a6b:dc08:: with SMTP id s8mr2525510ioc.209.1564720809795; Thu, 01 Aug 2019 21:40:09 -0700 (PDT) MIME-Version: 1.0 References: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com> <5ECB215B-AA05-47AB-AC8F-F14A74A46FEE@tzi.org> In-Reply-To: From: Ulysse Carion Date: Thu, 1 Aug 2019 21:39:58 -0700 Message-ID: To: Anders Rundgren Cc: Carsten Bormann , John Cowan , JSON WG , "Manger, James" Content-Type: multipart/alternative; boundary="0000000000000a9194058f1af49c" Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 04:40:13 -0000 --0000000000000a9194058f1af49c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Within this discussion we've seen precisely why I don't think JSL should take on directly supporting currency-related stuff. Anders describes the W3C's payment-request spec, which uses a string, whereas Carsten describes the multiply-by-denominator approach, which is the one that Stripe uses: https://stripe.com/docs/api/charges/create I think JSL is useful without currency-specific support, just as it is useful without int64/uint64. Better to ship fewer things well, no? On Thu, Aug 1, 2019 at 12:54 PM Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > On 2019-08-01 21:07, Carsten Bormann wrote: > > On Aug 1, 2019, at 18:08, John Cowan wrote: > >> > >> Monetary amounts need to be represented as JSON strings, or your > auditors will be down on you like a ton of bricks. > > > > That is only true if you naively equate the interchange data model with > your application data model. > > > > There is nothing wrong with interchanging currency values as floating > point values if you properly process them on ingestion. Typically, you > multiply with a common denominator (such as 100 or 1000 [egyptian pounds?= , > or US mills as in gasoline prices]) and round to the nearest integer. > > In this case there are standards that are interoperable with any JSON > parser although you typically have to perform one or two additional > operations in order to get the proper local representation: > https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value > > We lucky guys(?) who build our own stuff have it natively: > > https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/json/JSO= NObjectReader.html#getMoney-java.lang.String-java.lang.Integer%2d > mapped =3D> "string" > > Anders > > > > >> The sum of ten 0.1 values is 0.9999999999999999, not 1.0, assuming the > float64 interpretation that essentially all JSON readers assign to JSON > numbers. > > > > Right, you can=E2=80=99t *compute* with them as floating point values (= well, you > can, but you need to be even more careful with the rounding). > > > > You still can *interchange* them as floating point values if you have > enough precision (binary32 notably doesn=E2=80=99t for most applications;= you > really need binary64, and you are still limited to applications that hand= le > less than ~ 90 Microsofts or Apples a piece and don=E2=80=99t need more i= nternal > decimal places at the same time). > > > > A data definition language could contain specific support for binary > floating point values used to encode decimal fractions; CDDL currently > doesn=E2=80=99t (but support could be added using its main extension poin= t: control > operators). > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > --0000000000000a9194058f1af49c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Within this discussion we've seen precisely why I= don't think JSL should take on directly supporting currency-related st= uff. Anders describes the W3C's payment-request spec, which uses a stri= ng, whereas Carsten describes the multiply-by-denominator approach, which i= s the one that Stripe uses: https://stripe.com/docs/api/charges/create

=
I think JSL is useful without currency-specific support, just as it is= useful without int64/uint64. Better to ship fewer things well, no?

On Thu, Aug 1, 2019 at 12:54 PM Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
On 2019-08-01 21:0= 7, Carsten Bormann wrote:
> On Aug 1, 2019, at 18:08, John Cowan <cowan@ccil.org> wrote:
>>
>> Monetary amounts need to be represented as JSON strings, or your a= uditors will be down on you like a ton of bricks.
>
> That is only true if you naively equate the interchange data model wit= h your application data model.
>
> There is nothing wrong with interchanging currency values as floating = point values if you properly process them on ingestion.=C2=A0 Typically, yo= u multiply with a common denominator (such as 100 or 1000 [egyptian pounds?= , or US mills as in gasoline prices]) and round to the nearest integer.

In this case there are standards that are interoperable with any JSON parse= r although you typically have to perform one or two additional operations i= n order to get the proper local representation:
https://www.w3.org/TR/payment= -request/#dfn-valid-decimal-monetary-value

We lucky guys(?) who build our own stuff have it natively:
https://cyberphone.github.io/doc/open= keystore/javaapi/org/webpki/json/JSONObjectReader.html#getMoney-java.lang.S= tring-java.lang.Integer%2d
mapped =3D> "string"

Anders

>
>> The sum of ten 0.1 values is 0.9999999999999999, not 1.0, assuming= the float64 interpretation that essentially all JSON readers assign to JSO= N numbers.
>
> Right, you can=E2=80=99t *compute* with them as floating point values = (well, you can, but you need to be even more careful with the rounding). >
> You still can *interchange* them as floating point values if you have = enough precision (binary32 notably doesn=E2=80=99t for most applications; y= ou really need binary64, and you are still limited to applications that han= dle less than ~ 90 Microsofts or Apples a piece and don=E2=80=99t need more= internal decimal places at the same time).
>
> A data definition language could contain specific support for binary f= loating point values used to encode decimal fractions; CDDL currently doesn= =E2=80=99t (but support could be added using its main extension point: cont= rol operators).
>
> Gr=C3=BC=C3=9Fe, Carsten
>

--0000000000000a9194058f1af49c-- From nobody Thu Aug 1 22:21: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 05553120132 for ; Thu, 1 Aug 2019 22:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDkYBYlJl7ri for ; Thu, 1 Aug 2019 22:20:57 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 CF175120044 for ; Thu, 1 Aug 2019 22:20:56 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id g67so60974441wme.1 for ; Thu, 01 Aug 2019 22:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=+PSENgvkMCBAXgqjSlLDZ9aH3tpRyPWXvD/TbEpqI+M=; b=biZ1Mxu4wzoOtgXA6PrLmpUIFjUEdlTsucqsOaLsScxzEqraNdQ3KG0SeNhbx0ONM5 TcZchwyRg36fAI57L0GSoeYfC1Qigsy+0mwOSuPa1fSgemyk1daYcJOs6ckaSl+zbEsm Ez6cw5DR8ufYWB5pTfgqLYVigf+9L+T+RQnNuZ7RxGc1oX6zxRWaBsj3+W7XdpKwVmtb t97qEbjqNSyaql1tlhKiN+K+lfFiyfG8WONqA+0mdF/Uv6tQpp12Mogy0iUgeMWJPJcB bPiMGIqdU2FbsMryV4ONpXp3h21a3U2xLqJlvyE6SwiitMzBcXv7JZEqepV71ecPa2ZK 2I5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+PSENgvkMCBAXgqjSlLDZ9aH3tpRyPWXvD/TbEpqI+M=; b=XrbP7q8WMUomHCDZw8Rje20JHdmRN8xboo9ThEYBjsZxif5tp9QS0gWpfHjcvjOAha LxCGVKcF5cCT5nOTmhSfgDl8LNRL0+4I9jdl1cJ0V9CnvpulI9u9k9BWLIaFvwErXCNj ANzSLsck/iBaDI9xgUe6X+6ncK7krWm8KMBDm45s9Oo27HCmoddoLgkQf/WifnDxdi/d 49hX+8ZYMfA9hq7A5K9AYoo6xSNyQMuW6ofZHwPrOwcvVx04ViIqHrcdghWGmGwdI+Ur 68cY/lQjLDjl0fGOr/TZc5j6gz7pzM7eDf/FQbHGpLga4sE0uOTnnJqGrh9iiez8HjbP RGNg== X-Gm-Message-State: APjAAAUE7UJWao5N3k0l9/JeAeWWqXTqusDuYCoucMB+SJGaFwgJoFgm dZQ/njCeB+9AFsyZNKnpObsDEH+x X-Google-Smtp-Source: APXvYqzwyyu165hwGuvmS90mVQNBAvkKDzqRmrSyrrS47/oMdPGlfdKkuZ4DxrCHfzUnJk/qFGLWAA== X-Received: by 2002:a05:600c:490:: with SMTP id d16mr2272565wme.104.1564723254767; Thu, 01 Aug 2019 22:20:54 -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 v65sm85380344wme.31.2019.08.01.22.20.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Aug 2019 22:20:53 -0700 (PDT) From: Anders Rundgren To: JSON WG References: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com> <5ECB215B-AA05-47AB-AC8F-F14A74A46FEE@tzi.org> Message-ID: Date: Fri, 2 Aug 2019 07:20:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] Monetary type: JSON Schema Language is nearly done X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 05:20:59 -0000 https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value It has been agreed upon by payment folks from Google, Microsoft, VISA, etc. Published Open Banking API's have AFAIK adopted this scheme as well. The previously posted link rot due an API change... https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/json/JSONObjectWriter.html#setMoney-java.lang.String-java.math.BigDecimal-int%2d For those who insist that JSON Number is the only "true" way of serializing numbers in JSON, a "number" type would be the logical choice. /anders From nobody Thu Aug 1 23:47: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 CB612120136 for ; Thu, 1 Aug 2019 23:47:21 -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 N8U8Q0KqlaHN for ; Thu, 1 Aug 2019 23:47:19 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9141812008A for ; Thu, 1 Aug 2019 23:47:19 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 460HlT6FYWzyxn; Fri, 2 Aug 2019 08:47:17 +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, 2 Aug 2019 08:47:17 +0200 Cc: Anders Rundgren , John Cowan , JSON WG , "Manger, James" X-Mao-Original-Outgoing-Id: 586421235.836823-85e8431d9da69b65bc36ab9a120cbc2d Content-Transfer-Encoding: quoted-printable Message-Id: <6EEAE0DB-A337-4122-B9F5-F3BBBBC45B64@tzi.org> References: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com> <5ECB215B-AA05-47AB-AC8F-F14A74A46FEE@tzi.org> To: Ulysse Carion X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 06:47:22 -0000 > On Aug 2, 2019, at 06:39, Ulysse Carion wrote: >=20 > Within this discussion we=E2=80=99ve seen precisely why I don't think = JSL should take on directly supporting currency-related stuff.=20 The more powerful data definition languages don=E2=80=99t need any more = functionality here, e.g., in CDDL one would simply write: decimal-monetary-value =3D text .regexp "-?[0-9]+(\\.[0-9]+)?=E2=80=9D For a data definition scheme such as JSL, which opts out of specifying = subtypes of what are the common base types in programming languages, = this would indeed seem to be misplaced. Let=E2=80=99s see how well JSL withstands the =E2=80=9Cjust this one = more feature=E2=80=9D urge=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 2 04:00: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 93D961200A3 for ; Fri, 2 Aug 2019 04:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.099 X-Spam-Level: *** X-Spam-Status: No, score=3.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, 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 jexi2qtyq-xF for ; Fri, 2 Aug 2019 04:00:47 -0700 (PDT) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40731200B1 for ; Fri, 2 Aug 2019 04:00:46 -0700 (PDT) Received: (qmail 5936 invoked from network); 2 Aug 2019 11:58:19 +0100 Received: from host109-149-217-70.range109-149.btcentralplus.com (HELO ?192.168.1.72?) (109.149.217.70) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 2 Aug 2019 11:58:19 +0100 To: Ulysse Carion , Anders Rundgren Cc: Carsten Bormann , John Cowan , "Manger, James" , JSON WG References: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com> <5ECB215B-AA05-47AB-AC8F-F14A74A46FEE@tzi.org> From: Pete Cordell Message-ID: <6c13347a-b64b-c43e-67be-e704450025e4@codalogic.com> Date: Fri, 2 Aug 2019 12:00:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 11:00:50 -0000 On 02/08/2019 05:39, Ulysse Carion wrote: > Within this discussion we've seen precisely why I don't think JSL should > take on directly supporting currency-related stuff. Anders describes the > W3C's payment-request spec, which uses a string, whereas Carsten > describes the multiply-by-denominator approach, which is the one that > Stripe uses: https://stripe.com/docs/api/charges/create > > I think JSL is useful without currency-specific support, just as it is > useful without int64/uint64. Better to ship fewer things well, no? A recent solution to JCR for managing an ever growing type system is to allow the base type to have a format URI designator with it. So JSL would end up looking something like: "amount": { "type": "string", "format": "https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value" } The format can then be defined in separate documents. Which layer of validation ensures the format is correct is an implementation detail. The lower layers could just ensure it's a string. Higher layers could ensure that the string has the correct format. > On Thu, Aug 1, 2019 at 12:54 PM Anders Rundgren > > > wrote: > > On 2019-08-01 21:07, Carsten Bormann wrote: > > On Aug 1, 2019, at 18:08, John Cowan > wrote: > >> > >> Monetary amounts need to be represented as JSON strings, or your > auditors will be down on you like a ton of bricks. > > > > That is only true if you naively equate the interchange data > model with your application data model. > > > > There is nothing wrong with interchanging currency values as > floating point values if you properly process them on ingestion. > Typically, you multiply with a common denominator (such as 100 or > 1000 [egyptian pounds?, or US mills as in gasoline prices]) and > round to the nearest integer. > > In this case there are standards that are interoperable with any > JSON parser although you typically have to perform one or two > additional operations in order to get the proper local representation: > https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value > > We lucky guys(?) who build our own stuff have it natively: > https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/json/JSONObjectReader.html#getMoney-java.lang.String-java.lang.Integer%2d > mapped => "string" > > Anders > > > > >> The sum of ten 0.1 values is 0.9999999999999999, not 1.0, > assuming the float64 interpretation that essentially all JSON > readers assign to JSON numbers. > > > > Right, you can’t *compute* with them as floating point values > (well, you can, but you need to be even more careful with the rounding). > > > > You still can *interchange* them as floating point values if you > have enough precision (binary32 notably doesn’t for most > applications; you really need binary64, and you are still limited to > applications that handle less than ~ 90 Microsofts or Apples a piece > and don’t need more internal decimal places at the same time). > > > > A data definition language could contain specific support for > binary floating point values used to encode decimal fractions; CDDL > currently doesn’t (but support could be added using its main > extension point: control operators). > > > > Grüße, Carsten > > Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Fri Aug 2 06:41:42 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 2E2231200F4 for ; Fri, 2 Aug 2019 06:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 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, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 6b_BaBQY85jV for ; Fri, 2 Aug 2019 06:41:39 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 7BD5E120088 for ; Fri, 2 Aug 2019 06:41:39 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id n9so77341050wru.0 for ; Fri, 02 Aug 2019 06:41:39 -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=jpP5sKegapWVTyUcLx3gUI5FBa6lsPKBXsa3vvmlEwQ=; b=j2Wze92aw8CVLuumqVmXUA398afmzQoxXrNJ/UiJLa1a/gsi5eXo1ItEWaZS46UO4h LIDWiocRwIaZxkAOZ6777PmhCdXKoyYd71VWP/xmnwdaXbfLUGiqTkIIRfoPfGP6mAkM Rf8Sg4JIY3BT/IwAyyF8JkbmEG28AFH4Pa2ubrMfFDqEpBzX4uHE+FZdwBz9VE+sSME1 5Tv5KHQLYRoDs3JzG7qztpd0JhI+PcxdvGQjuk91sYCJ18aQyprY6EWldosQT/3QkXz3 YvLNmFRETmJX67G8F7kt355ou9ts95eTtuS0ycA9N8APRZ1qHqe8an9WYCD3Hcc12HvC XvSQ== 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=jpP5sKegapWVTyUcLx3gUI5FBa6lsPKBXsa3vvmlEwQ=; b=CPDduHxZ0UEZ4VjxbKQAXmfhhP7lzm9mrqfOqHAYu0KRp3pPbNY9NND7394CCQUfb6 nww9yMiufH1Hsu7yn5cIOBuOVqO3YkfgX3Pj1Qwzi4e49Us/+Ul+2zvxOek872Gzuysm NkPCtj0MuEXiOz3LVRtTEcPaGZQBiRyphBPPxst0Nub1+sdDEEayjb6re63BmNuF6O+W ozzRAVyzRIm3qK7tS8syi01olCU1NcLZbm/KUy8IWQKq0O5lxYNzrbZf3007BkBJD86p uJdbi7lPSHXcy9UIs5OFxIfdnyOLrUkb/Sb0iVGB6ly9hYkDz69jh8MdTH/B0yqRW1k5 KHXA== X-Gm-Message-State: APjAAAUEzs9IophOF7r6SEZIe9YTXmgbvrbPXEMX4GegaUvn8Mhg1XVc IQM8smEsxtDRVHPAwutI5abtxnLT X-Google-Smtp-Source: APXvYqwNFBZ1+TaZBo4e2FYgeBcv6a17i/J32CLVqHZ8CX1sQmcv6L2gHm0/yFyBG2DuMuyS6pPM+g== X-Received: by 2002:adf:de08:: with SMTP id b8mr9955947wrm.282.1564753297384; Fri, 02 Aug 2019 06:41:37 -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 e3sm89032535wrs.37.2019.08.02.06.41.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Aug 2019 06:41:36 -0700 (PDT) To: Pete Cordell , Ulysse Carion Cc: JSON WG References: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com> <5ECB215B-AA05-47AB-AC8F-F14A74A46FEE@tzi.org> <6c13347a-b64b-c43e-67be-e704450025e4@codalogic.com> From: Anders Rundgren Message-ID: Date: Fri, 2 Aug 2019 15:41:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <6c13347a-b64b-c43e-67be-e704450025e4@codalogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON Schema Language is nearly done: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 13:41:41 -0000 Cool! On 2019-08-02 13:00, Pete Cordell wrote: > On 02/08/2019 05:39, Ulysse Carion wrote: >> Within this discussion we've seen precisely why I don't think JSL should >> take on directly supporting currency-related stuff. Anders describes the >> W3C's payment-request spec, which uses a string, whereas Carsten >> describes the multiply-by-denominator approach, which is the one that >> Stripe uses: https://stripe.com/docs/api/charges/create >> >> I think JSL is useful without currency-specific support, just as it is >> useful without int64/uint64. Better to ship fewer things well, no? > > A recent solution to JCR for managing an ever growing type system is to > allow the base type to have a format URI designator with it. So JSL > would end up looking something like: > > "amount": { > "type": "string", > "format": > "https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value" } > > The format can then be defined in separate documents. Which layer of > validation ensures the format is correct is an implementation detail. > The lower layers could just ensure it's a string. Higher layers could > ensure that the string has the correct format. > > >> On Thu, Aug 1, 2019 at 12:54 PM Anders Rundgren >> > >> wrote: >> >> On 2019-08-01 21:07, Carsten Bormann wrote: >> > On Aug 1, 2019, at 18:08, John Cowan > > wrote: >> >> >> >> Monetary amounts need to be represented as JSON strings, or your >> auditors will be down on you like a ton of bricks. >> > >> > That is only true if you naively equate the interchange data >> model with your application data model. >> > >> > There is nothing wrong with interchanging currency values as >> floating point values if you properly process them on ingestion. >> Typically, you multiply with a common denominator (such as 100 or >> 1000 [egyptian pounds?, or US mills as in gasoline prices]) and >> round to the nearest integer. >> >> In this case there are standards that are interoperable with any >> JSON parser although you typically have to perform one or two >> additional operations in order to get the proper local representation: >> https://www.w3.org/TR/payment-request/#dfn-valid-decimal-monetary-value >> >> We lucky guys(?) who build our own stuff have it natively: >> https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/json/JSONObjectReader.html#getMoney-java.lang.String-java.lang.Integer%2d >> mapped => "string" >> >> Anders >> >> > >> >> The sum of ten 0.1 values is 0.9999999999999999, not 1.0, >> assuming the float64 interpretation that essentially all JSON >> readers assign to JSON numbers. >> > >> > Right, you can’t *compute* with them as floating point values >> (well, you can, but you need to be even more careful with the rounding). >> > >> > You still can *interchange* them as floating point values if you >> have enough precision (binary32 notably doesn’t for most >> applications; you really need binary64, and you are still limited to >> applications that handle less than ~ 90 Microsofts or Apples a piece >> and don’t need more internal decimal places at the same time). >> > >> > A data definition language could contain specific support for >> binary floating point values used to encode decimal fractions; CDDL >> currently doesn’t (but support could be added using its main >> extension point: control operators). >> > >> > Grüße, Carsten >> > > > > Pete. > From nobody Fri Aug 9 18:43: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 425E612003F for ; Fri, 9 Aug 2019 18:43:52 -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=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 TFu9gtQgIF5v for ; Fri, 9 Aug 2019 18:43:49 -0700 (PDT) Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (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 E134D120047 for ; Fri, 9 Aug 2019 18:43:48 -0700 (PDT) Received: by mail-ot1-x341.google.com with SMTP id l15so82505411oth.7 for ; Fri, 09 Aug 2019 18:43:48 -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=1MaDFKSb7T+nQ5SPCviGOGa0eO1rchY2iVJ3a2WJlTg=; b=qrevrOAqa2i1wNj5mLUKpIcIUKTEG7YBZ2FsdxrrOmjEYHbw0uMg5lwW7WdLyMg1hQ 9IVjSJWAVbGS718gR6ywqo8sTieU8OE+UUu4FG0nil+HMjeC4BwUdIpAVFGga9N5C6db UgmEy/3vL06ZAQ/PUVZsGCPFG7VqMSN7D4/gc= 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=1MaDFKSb7T+nQ5SPCviGOGa0eO1rchY2iVJ3a2WJlTg=; b=fLyOKjv26fg2AtqjayYFgYxkvkzlC7qu9ErTI8P+VTiI3vFQ8iwjVNudIJ9o53gEDD GRBSnGDbcQu5JeLtJgr96+5jbwQC2ed0fOKD+vPr+jWjYFeBZcqc+R/TdkVe3zBG9rFb wdY7+L7XdXAOOhjZJeQYhe21Nn3jihyLvtTCueNqcr6KsN1XLuaF2eWMPMi6gPYnoXHe s4BYMfOb+eiNCcy92M0IRzkf9eWm+1H2ctEHRZQdhgf1YsPhhxMxi63htmqHT7Yzj6gK cqdijbSZe/XT7tDCf2dRq9SCFrbE7eLdlZzbRDO9bt37c5XefCg1o97Q/RizjaST4UaQ 6BXQ== X-Gm-Message-State: APjAAAVvYWQdbeavsQkJlS1RpwyPkGDNTCfxbhbNseL4StQlRxoBUHv6 FRi+1GFkxmiQ0wBMSstW6pZXEx8uPAYhwoCGsJB4vvF1Yvo= X-Google-Smtp-Source: APXvYqyjefg369JTYWxRyaUATmdf1pDpLWUHK1PzDjzOAWiZ9/gCCZkM7AxKJ/OTWrLTP0j+9+vuF4gSIo8wzmb1IQs= X-Received: by 2002:a5d:96d8:: with SMTP id r24mr24263612iol.269.1565401427789; Fri, 09 Aug 2019 18:43:47 -0700 (PDT) MIME-Version: 1.0 From: Ulysse Carion Date: Fri, 9 Aug 2019 18:43:37 -0700 Message-ID: To: JSON WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Json] JSON Schema Language: extensibility and unspecified properties 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, 10 Aug 2019 01:43:52 -0000 Hi folks, Thanks again for all the wonderful suggestions for JSON Schema Language. I've just published a new draft incorporating suggestions from the last update. You can read it here: https://tools.ietf.org/html/draft-ucarion-json-schema-language-02 I would like advice on the two following changes I've made to the spec. First, I added explicit discussion of how JSL can be extended. The language is at the end of section 2, but I'll reproduce it here: > This document does not describe any extension mechanisms for JSL schema > validation. However, schemas (through the `non-keyword` CDDL rule in this > section) are defined to allow members whose names are not equal to any of the > specially-defined keywords (i.e. `definitions`, `elements`, etc.) described in > this section. Call these members "non-keyword members". > > Users MAY add additional, non-keyword members to JSL schemas to convey > information that is not pertinent to validation. For example, such non-keyword > members could provide hints to code generators, or trigger some special behavior > for a library that generates user interfaces from schemas. > > Users SHOULD NOT expect non-keyword members to be understood by other parties. > As a result, if consistent validation with other parties is a requirement, users > SHOULD NOT use non-keyword members to affect how schema validation, as described > in {{semantics}}, works. Basically, my stance is: you can add custom stuff to schemas, but you can't change validation. I expect that people will change validation anyway, but they're not going to expect portability. I don't feel that adding some sort of registry of keywords / forms is valuable yet. Perhaps something like that can be in whatever replaces JSL? How do folks feel about this? Does anyone have suggestions on better ways I can approach extensibility, or how I should phrase this language? The other thing I want advice on is "strict" mode, called "strict instance semantics" in the spec. Basically, strict instance semantics about whether it's ok to send "extra"/"unknown"/"unspecified" properties in an object. Right now, validation behavior is specified as a single, top-level "strict": true/false (default is "true") property. You can't mix and match strict and non-strict. But Carsten off-list noted that might be a bit "blunt". Do others agree? The context for my decision is that two of major typed languages used in industry, Java and Golang, don't typically support mixing and matching. Go just as a blunt DisallowUnknownFields: https://golang.org/pkg/encoding/json/#Decoder.DisallowUnknownFields And Java's Jackson has a FAIL_ON_UNKNOWN_PROPERTIES: http://fasterxml.github.io/jackson-databind/javadoc/2.9/com/fasterxml/jackson/databind/DeserializationFeature.html#FAIL_ON_UNKNOWN_PROPERTIES Both are all or nothing. Also, there is the question of whether "strict" is a good name for this property in schemas. Is there a better name for it? "strict" can be understood in many ways. Open to ideas here as well. Other changes: - Removed int64/uint64 (and removed discussion related to I-JSON) - Clarified that 1.0e1 is an integer Finally, I've moved JSL to a desired status of "Informative", and I'll be going through the independent stream once the discussion here appears to have settled. Thanks again for all the help, Ulysse From nobody Fri Aug 9 23:23: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 883E9120108 for ; Fri, 9 Aug 2019 23:23:37 -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 XNU4SCxIBJnw for ; Fri, 9 Aug 2019 23:23:35 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F861200E5 for ; Fri, 9 Aug 2019 23:23:35 -0700 (PDT) Received: from client-0171.vpn.uni-bremen.de (client-0171.vpn.uni-bremen.de [134.102.107.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 465BrP6gZFz10gG; Sat, 10 Aug 2019 08:23: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: Date: Sat, 10 Aug 2019 08:23:33 +0200 Cc: JSON WG X-Mao-Original-Outgoing-Id: 587111010.5112-121e593ee9eae9633474c25cd656f458 Content-Transfer-Encoding: quoted-printable Message-Id: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> References: To: Ulysse Carion X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 10 Aug 2019 06:23:38 -0000 Examples are good: This schema [=E2=80=A6] limits =E2=80=9Cgenerated=E2=80=9D and "expires" to timestamps less than 2^32 seconds after January 1, 1970 00:00 UTC.=20 This is a nice demonstration that it was a mistake to remove uint53. (Note that on 32-bit systems time_t is an int32. But you definitely = don=E2=80=99t want that restriction; 2038 is coming too close now. = Uint32 is completely arbitrary and wrong in many ways.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Aug 10 12:01: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 5D6BB120186 for ; Sat, 10 Aug 2019 12:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7ZjlkgOIwQY for ; Sat, 10 Aug 2019 12:00:52 -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 DD238120148 for ; Sat, 10 Aug 2019 12:00:51 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id f72so8691639wmf.5 for ; Sat, 10 Aug 2019 12:00:51 -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=Qs29bHdVzAjprg/ppIT5N5iDH8Lx61iFdgv1/T+EpaE=; b=jO74D84mCGhYSlunAnLpyqEeGZwfPEDkX+RYLQSbksdGlSgzzlXuINvTDggYFZkPKd 9s9UtU798GqJVwMAmoZUetZXqnG/VfCDXHXCH3Ap+lYTifulwHchHxA24lDs9DtefZ9B mwXZ/jhh1kp6iyQ46LlzgzO9m+IXXBiPXyOKVZ/Z/lzA3I1wb02ZiV3gOm1Pkjws+o/a MOquVWojQKdPaqWPvQ1N0rPrHbslgFPE0/BS3FxCSQEWxURkudCJWyzKhQD1eQjQ2nzX 6yBDeLN2st/zlF+oJw9ncFjAYOvuaIotsNPYYmMfWoaysszqWXArqxYqAqDe8zTzOJSu nB3g== 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=Qs29bHdVzAjprg/ppIT5N5iDH8Lx61iFdgv1/T+EpaE=; b=Ewb/7uzLDjIKRJFCP6CyNAxC8HHD/a6Lyw3Aa3e5PErq2wvuWOiSk0az6GSjXsRGog SQEBBbLtgML05AGhp5aWlnMbevi0hoGZ9/Q4OtCxoWhTQsJQn+1Kk7R6dGDS1XBnTpRl Uef6GYaTRpaia7iYuDWKXeEsVvCVtHu3s31qD9dg0sMRehYZbD95DBN8fp8FHfMnNY07 zN66FpAXR6Cp6A412cKE6+o1w5vWU32izGY+ewYHQo6covr7P3oVgQ6SSdm6FaTew/dw FcQA2tpWn+jXO1046Ro4aCBVxM4+ktCG/Heqx7pSp3l+POmvkaenl3v0BD/2MARGtnYj BQ3Q== X-Gm-Message-State: APjAAAUCEF8z488TfH3gtVGuEs56VXVfoMGidc6ur4C+xFtPf/90pNUM bQKUqNb12uptqU7qXpoYfEc= X-Google-Smtp-Source: APXvYqz5P1zUO5sAKq3ojfKUZfk1fr9MtK/nEyAICIKoD87YfLIpPZ5lDCyf8REkXWIaMee60ahqKA== X-Received: by 2002:a1c:be11:: with SMTP id o17mr18154717wmf.115.1565463650207; Sat, 10 Aug 2019 12:00:50 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id u1sm11221364wml.14.2019.08.10.12.00.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Aug 2019 12:00:49 -0700 (PDT) To: Ulysse Carion , JSON WG References: From: Anders Rundgren Message-ID: <8d56f00d-14af-c387-ff02-e279cca6ddea@gmail.com> Date: Sat, 10 Aug 2019 21:00:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 10 Aug 2019 19:01:03 -0000 If we stick to unspecified properties I'm currently working with a payment authorization scheme where some components will be defined by the payment networks. The components start with a defined property holding a JSON Object but the contents of the object is not known by the "main" schema. In my programmatic solution the "main schema" ignores such components and only validates that they conform JSON. The components are then dealt with by customer supplied decoders which indeed may use a schema. How can you express this in a main schema using JCL? Anders paymentRequest = new PaymentRequest(rd.getObject(PAYMENT_REQUEST_JSON)); undecodedPaymentMethodSpecific = rd.getObject(BACKEND_METHOD_SPECIFIC_JSON); rd.scanAway(BACKEND_METHOD_SPECIFIC_JSON); referenceId = rd.getString(REFERENCE_ID_JSON); On 2019-08-10 03:43, Ulysse Carion wrote: > Hi folks, > > Thanks again for all the wonderful suggestions for JSON Schema > Language. I've just published a new draft incorporating suggestions > from the last update. You can read it here: > > https://tools.ietf.org/html/draft-ucarion-json-schema-language-02 > > I would like advice on the two following changes I've made to the spec. > > First, I added explicit discussion of how JSL can be extended. The > language is at the end of section 2, but I'll reproduce it here: > >> This document does not describe any extension mechanisms for JSL schema >> validation. However, schemas (through the `non-keyword` CDDL rule in this >> section) are defined to allow members whose names are not equal to any of the >> specially-defined keywords (i.e. `definitions`, `elements`, etc.) described in >> this section. Call these members "non-keyword members". >> >> Users MAY add additional, non-keyword members to JSL schemas to convey >> information that is not pertinent to validation. For example, such non-keyword >> members could provide hints to code generators, or trigger some special behavior >> for a library that generates user interfaces from schemas. >> >> Users SHOULD NOT expect non-keyword members to be understood by other parties. >> As a result, if consistent validation with other parties is a requirement, users >> SHOULD NOT use non-keyword members to affect how schema validation, as described >> in {{semantics}}, works. > > Basically, my stance is: you can add custom stuff to schemas, but you > can't change validation. I expect that people will change validation > anyway, but they're not going to expect portability. I don't feel that > adding some sort of registry of keywords / forms is valuable yet. > Perhaps something like that can be in whatever replaces JSL? > > How do folks feel about this? Does anyone have suggestions on better > ways I can approach extensibility, or how I should phrase this > language? > > The other thing I want advice on is "strict" mode, called "strict > instance semantics" in the spec. Basically, strict instance semantics > about whether it's ok to send "extra"/"unknown"/"unspecified" > properties in an object. > > Right now, validation behavior is specified as a single, top-level > "strict": true/false (default is "true") property. You can't mix and > match strict and non-strict. But Carsten off-list noted that might be > a bit "blunt". Do others agree? > > The context for my decision is that two of major typed languages used > in industry, Java and Golang, don't typically support mixing and > matching. Go just as a blunt DisallowUnknownFields: > > https://golang.org/pkg/encoding/json/#Decoder.DisallowUnknownFields > > And Java's Jackson has a FAIL_ON_UNKNOWN_PROPERTIES: > > http://fasterxml.github.io/jackson-databind/javadoc/2.9/com/fasterxml/jackson/databind/DeserializationFeature.html#FAIL_ON_UNKNOWN_PROPERTIES > > Both are all or nothing. > > Also, there is the question of whether "strict" is a good name for > this property in schemas. Is there a better name for it? "strict" can > be understood in many ways. Open to ideas here as well. > > Other changes: > > - Removed int64/uint64 (and removed discussion related to I-JSON) > - Clarified that 1.0e1 is an integer > > Finally, I've moved JSL to a desired status of "Informative", and I'll > be going through the independent stream once the discussion here > appears to have settled. > > Thanks again for all the help, > Ulysse > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Sat Aug 10 12:55: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 CC555120041 for ; Sat, 10 Aug 2019 12:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QNnFhjM5g9T for ; Sat, 10 Aug 2019 12:55:44 -0700 (PDT) Received: from sonic313-14.consmr.mail.bf2.yahoo.com (sonic313-14.consmr.mail.bf2.yahoo.com [74.6.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48F512002F for ; Sat, 10 Aug 2019 12:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1565466942; bh=qoRUTtYRkFwZ7RjHK8rMy0GS0TIOrETuHd/pNUnP+1Q=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=eK5eMUIL+SPdqtsLJegjeUVyQ4mCAVnQPF3ERHI0WspRoAXeY48nLFX657V0rQTduA3p9zLEyBtmZFkrYST5o4YIoN1px2yHataZhn8aVrXYA5PIdH/S7C+QYgL/f3z9ncxk9CqvFynIMTNESNBwJpV+K3ziN0zJkH4NfLzAnV3osTWuMUzvURmjA3ISC96fr406rUTg/1rw7tW4Rtmu49qx9oz3egFZGOaY+h64Y+3tnB6BU9TfIRZK2xjuKqOzPWfQzHUJY3v519N6LT7pJKzndV9AAoebY7ed8fqN57hYu+DO8Oq/vj+vVLfYta//XzeEQXZGOZ2qKLMpsqI+yw== X-YMail-OSG: z_h5zKEVM1kXgTspcY97kYLavLw9qG2NEu7AcoHNfX3hRrU_LsU.zQZIwU7nJ1s krahcmylsKmAUxuA1E6zFacxUikNhDd4gGS_a8ZNPJwbIpXclPw_s8ynTUcy.7UD8S2BmI_c6z2W AM1iM2J.yyc2ut.WgDFO3omm9eyRC6dX_oO8d9eu0msTRlSzKmL71R4jFSaUHCZAsCiM9NkVok0H Mb1vpne4cK19VprKK3S20y2SofHO.Q08M95w0BgBGHeTJ5gjR4SRYttOAOMd42huB_e3muwND_Pn kM.9NINzvkK2hqhtQxaR8G9dr89ZWJxfnJcz1clAuo6cwA2Ho3k_Ucvmdbrdx6ZGtBCl7A7gt3e0 enwoSBmpdsWgDreXS9cq9iyvg.hyNtXvQMxX1_1v_vQdAsZj7c..7kgHCGiplde4zphi.wb9LP9s SFc5jF9yibllorP9S6ci2XYxg4RjZs3.RYvRC3PikO4mDbsEgQGAUnJc23w2oKFYkhV3rLXfkP0i G9Q2luV0IQOBJTogRaUtgJfVQAGxnAFle52liDpjU.hcSr1fcDtr4_sSSfutgAcJLSqeCM8BMiF5 rc98f750oJlcJ3Qmyjg3vqEWL0TjouWr4feP.maUozFtcSgQML.K1i5_bGh_t1sQOxOR.YIyut6B TeiltwG6X9y0.vzhLk8gz9j7LhhCGBAny.12ilYVXn7hzBKql5ilrmcNSn3G2h.4zhiugl7hd1PL xF8Voa1UiUkXMrQS7.0d.K21srI27__YUqgPy34E3GbuOUMx35.kEVA6TdfaAwucPetKyWXA4l40 xcaT1gQazxrvEiOUBmEF2Qzorh79xfGXYZO7wmv6alqcl_cRfIq1Mx4Rri5ev6IeLiJE01RXY58S j6QmtriGxTPCiF4Ks5p_nah77P3yYRuDCFnh8INq9bEZgSmpQZrD2ac6WYVuHNiFfXQLaLgBIG3O CNnQM.v5tCHx9uteX4IsT.NPTOhxc_6EdUUfvjuOwQDhkf6iR1KmUGj.bDtS5xPkPARNxIVUdzcc ryH6KlY7ckPg_zE8CxFvr1LtECiGgThvpR74XcD8_sNjh1AR4gV9g.u5vsnavL5Lnt9OBncf6aLg vqJA4VFKKVUDIXhVZig.A2KVwE1JZT5Aad_GeMbaRjyWFY8rdeICd..oR5aoji2_eXOWD9fm.HnM mdYMdEujNOB3boXEYlePF3CWRk.bOfbBhQQZzGPdF27U0Q4yolQsLLg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Sat, 10 Aug 2019 19:55:42 +0000 Date: Sat, 10 Aug 2019 19:55:37 +0000 (UTC) From: Henry Andrews Reply-To: Henry Andrews To: JSON WG Message-ID: <1371506030.2752303.1565466937101@mail.yahoo.com> In-Reply-To: <8d56f00d-14af-c387-ff02-e279cca6ddea@gmail.com> References: <8d56f00d-14af-c387-ff02-e279cca6ddea@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2752302_885198095.1565466937099" X-Mailer: WebService/1.1.14097 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36 Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 10 Aug 2019 19:55:47 -0000 ------=_Part_2752302_885198095.1565466937099 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I know folks here are not interested in JSON Schema itself, but i will poi= nt out that we have spent most of the past year on exactly this problem.=C2= =A0 JSON Schema vocabularies are identified by URIs, which implementations = can use to load extension libraries.=C2=A0 The keyword taxonomy we have dev= eloped classifies keywords into several sorts of high-level behaviors (prim= arily assertions, which produce boolean validation outcomes, annotations, w= hich attach information for applications to consume, and applicators, which= apply subschemas and potentially combine or modify their results), allowin= g extensible JSON Schema implementations to provide hooks for handling thos= e basic types of keywords. This work is the primary focus of the new draft, which will be published by= the end of August.=C2=A0 Here are some links to the vocabulary- and taxono= my-related sections in the work-in-progress review copies: http://json-schema.org/work-in-progress/WIP-jsonschema-core.html#rfc.sectio= n.6.5 http://json-schema.org/work-in-progress/WIP-jsonschema-core.html#rfc.sectio= n.7 http://json-schema.org/work-in-progress/WIP-jsonschema-core.html#rfc.sectio= n.8 =20 thanks,-henry On Saturday, August 10, 2019, 12:01:20 PM PDT, Anders Rundgren wrote: =20 =20 If we stick to unspecified properties I'm currently working with a payment authorization scheme where some components will be defined by the payment networks.=C2=A0 The components start with a defined property holding a JSON Object but the contents of the object is not known by the "main" schema. In my programmatic solution the "main schema" ignores such components and only validates that they conform JSON.=C2=A0 The components are then dealt with by customer supplied decoders which indeed may use a schema. How can you express this in a main schema using JCL? Anders =C2=A0 paymentRequest =3D new PaymentRequest(rd.getObject(PAYMENT_REQUEST_J= SON)); =C2=A0 undecodedPaymentMethodSpecific =3D rd.getObject(BACKEND_METHOD_SPECI= FIC_JSON); =C2=A0 rd.scanAway(BACKEND_METHOD_SPECIFIC_JSON); =C2=A0 referenceId =3D rd.getString(REFERENCE_ID_JSON); On 2019-08-10 03:43, Ulysse Carion wrote: > Hi folks, >=20 > Thanks again for all the wonderful suggestions for JSON Schema > Language. I've just published a new draft incorporating suggestions > from the last update. You can read it here: >=20 > https://tools.ietf.org/html/draft-ucarion-json-schema-language-02 >=20 > I would like advice on the two following changes I've made to the spec. >=20 > First, I added explicit discussion of how JSL can be extended. The > language is at the end of section 2, but I'll reproduce it here: >=20 >> This document does not describe any extension mechanisms for JSL schema >> validation. However, schemas (through the `non-keyword` CDDL rule in thi= s >> section) are defined to allow members whose names are not equal to any o= f the >> specially-defined keywords (i.e. `definitions`, `elements`, etc.) descri= bed in >> this section. Call these members "non-keyword members". >> >> Users MAY add additional, non-keyword members to JSL schemas to convey >> information that is not pertinent to validation. For example, such non-k= eyword >> members could provide hints to code generators, or trigger some special = behavior >> for a library that generates user interfaces from schemas. >> >> Users SHOULD NOT expect non-keyword members to be understood by other pa= rties. >> As a result, if consistent validation with other parties is a requiremen= t, users >> SHOULD NOT use non-keyword members to affect how schema validation, as d= escribed >> in {{semantics}}, works. >=20 > Basically, my stance is: you can add custom stuff to schemas, but you > can't change validation. I expect that people will change validation > anyway, but they're not going to expect portability. I don't feel that > adding some sort of registry of keywords / forms is valuable yet. > Perhaps something like that can be in whatever replaces JSL? >=20 > How do folks feel about this? Does anyone have suggestions on better > ways I can approach extensibility, or how I should phrase this > language? >=20 > The other thing I want advice on is "strict" mode, called "strict > instance semantics" in the spec. Basically, strict instance semantics > about whether it's ok to send "extra"/"unknown"/"unspecified" > properties in an object. >=20 > Right now, validation behavior is specified as a single, top-level > "strict": true/false (default is "true") property. You can't mix and > match strict and non-strict. But Carsten off-list noted that might be > a bit "blunt". Do others agree? >=20 > The context for my decision is that two of major typed languages used > in industry, Java and Golang, don't typically support mixing and > matching. Go just as a blunt DisallowUnknownFields: >=20 > https://golang.org/pkg/encoding/json/#Decoder.DisallowUnknownFields >=20 > And Java's Jackson has a FAIL_ON_UNKNOWN_PROPERTIES: >=20 > http://fasterxml.github.io/jackson-databind/javadoc/2.9/com/fasterxml/jac= kson/databind/DeserializationFeature.html#FAIL_ON_UNKNOWN_PROPERTIES >=20 > Both are all or nothing. >=20 > Also, there is the question of whether "strict" is a good name for > this property in schemas. Is there a better name for it? "strict" can > be understood in many ways. Open to ideas here as well. >=20 > Other changes: >=20 > - Removed int64/uint64 (and removed discussion related to I-JSON) > - Clarified that 1.0e1 is an integer >=20 > Finally, I've moved JSL to a desired status of "Informative", and I'll > be going through the independent stream once the discussion here > appears to have settled. >=20 > Thanks again for all the help, > Ulysse >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json =20 ------=_Part_2752302_885198095.1565466937099 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I know folks here are not in= terested in JSON Schema itself, but i will point out that we have spent mos= t of the past year on exactly this problem.  JSON Schema vocabularies = are identified by URIs, which implementations can use to load extension lib= raries.  The keyword taxonomy we have developed classifies keywords in= to several sorts of high-level behaviors (primarily assertions, which produ= ce boolean validation outcomes, annotations, which attach information for a= pplications to consume, and applicators, which apply subschemas and potenti= ally combine or modify their results), allowing extensible JSON Schema impl= ementations to provide hooks for handling those basic types of keywords.

This work is the primary focus of the new draft, which will= be published by the end of August.  Here are some links to the vocabu= lary- and taxonomy-related sections in the work-in-progress review copies:<= /div>

=20
=20

thank= s,
-henry

On Saturday, August 10, 2019, 12:01:20 PM PDT, Anders R= undgren <anders.rundgren.net@gmail.com> wrote:


If we stick to unspecified properties= I'm currently working with a
payment authorization schem= e where some components will be defined
by the payment ne= tworks.  The components start with a defined property
holding a JSON Object but the contents of the object is not known by
the "main" schema.

In my= programmatic solution the "main schema" ignores such components
and only validates that they conform JSON.  The components a= re
then dealt with by customer supplied decoders which in= deed may use
a schema.

How can you express this in a main schema using JCL?
<= br clear=3D"none">Anders

  payme= ntRequest =3D new PaymentRequest(rd.getObject(PAYMENT_REQUEST_JSON));
  undecodedPaymentMethodSpecific =3D rd.getObject(BACKEN= D_METHOD_SPECIFIC_JSON);
  rd.scanAway(BACKEND_METH= OD_SPECIFIC_JSON);
  referenceId =3D rd.getString(R= EFERENCE_ID_JSON);


= On 2019-08-10 03:43, Ulysse Carion wrote:
> Hi folks,<= br clear=3D"none">>
> Thanks again for all the won= derful suggestions for JSON Schema
> Language. I've ju= st published a new draft incorporating suggestions
> f= rom the last update. You can read it here:
>
> https:/= /tools.ietf.org/html/draft-ucarion-json-schema-language-02
>
> I would like advice on the two following= changes I've made to the spec.
>
&= gt; First, I added explicit discussion of how JSL can be extended. The
> language is at the end of section 2, but I'll reproduce = it here:
>
>> This document d= oes not describe any extension mechanisms for JSL schema
= >> validation. However, schemas (through the `non-keyword` CDDL rule = in this
>> section) are defined to allow members wh= ose names are not equal to any of the
>> specially-= defined keywords (i.e. `definitions`, `elements`, etc.) described in
>> this section. Call these members "non-keyword members"= .
>>
>> Users MAY add addit= ional, non-keyword members to JSL schemas to convey
>&= gt; information that is not pertinent to validation. For example, such non-= keyword
>> members could provide hints to code gene= rators, or trigger some special behavior
>> for a l= ibrary that generates user interfaces from schemas.
>&= gt;
>> Users SHOULD NOT expect non-keyword members = to be understood by other parties.
>> As a result, = if consistent validation with other parties is a requirement, users
>> SHOULD NOT use non-keyword members to affect how schema= validation, as described
>> in {{semantics}}, work= s.
>
> Basically, my stance is: = you can add custom stuff to schemas, but you
> can't c= hange validation. I expect that people will change validation
> anyway, but they're not going to expect portability. I don't feel= that
> adding some sort of registry of keywords / for= ms is valuable yet.
> Perhaps something like that can = be in whatever replaces JSL?
>
>= How do folks feel about this? Does anyone have suggestions on better
> ways I can approach extensibility, or how I should phrase= this
> language?
>
> The other thing I want advice on is "strict" mode, called "stric= t
> instance semantics" in the spec. Basically, strict= instance semantics
> about whether it's ok to send "e= xtra"/"unknown"/"unspecified"
> properties in an objec= t.
>
> Right now, validation beh= avior is specified as a single, top-level
> "strict": = true/false (default is "true") property. You can't mix and
> match strict and non-strict. But Carsten off-list noted that might b= e
> a bit "blunt". Do others agree?
= >
> The context for my decision is that two of maj= or typed languages used
> in industry, Java and Golang= , don't typically support mixing and
> matching. Go ju= st as a blunt DisallowUnknownFields:
>
> https://gol= ang.org/pkg/encoding/json/#Decoder.DisallowUnknownFields
>
> And Java's Jackson has a FAIL_ON_UNKNOWN_P= ROPERTIES:
>
> http://fasterxml.github.io/jackson-dat= abind/javadoc/2.9/com/fasterxml/jackson/databind/DeserializationFeature.htm= l#FAIL_ON_UNKNOWN_PROPERTIES
>
= > Both are all or nothing.
>
>= ; Also, there is the question of whether "strict" is a good name for
> this property in schemas. Is there a better name for it? "= strict" can
> be understood in many ways. Open to idea= s here as well.
>
> Other change= s:
>
> - Removed int64/uint64 (a= nd removed discussion related to I-JSON)
> - Clarified= that 1.0e1 is an integer
>
> Fi= nally, I've moved JSL to a desired status of "Informative", and I'll
> be going through the independent stream once the discussio= n here
> appears to have settled.
&g= t;
> Thanks again for all the help,
> Ulysse
>
> _______________= ________________________________
> json mailing list> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json<= div class=3D"ydp919f86feyqt7885709620" id=3D"ydp919f86feyqtfd61222">
>

____________________= ___________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
------=_Part_2752302_885198095.1565466937099-- From nobody Mon Aug 12 00:43: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 24A11120E38 for ; Mon, 12 Aug 2019 00:43:52 -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=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 w1NJc9kZpZwa for ; Mon, 12 Aug 2019 00:42:51 -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 4CBB812008D for ; Sun, 11 Aug 2019 10:34:02 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id z17so32664955otk.13 for ; Sun, 11 Aug 2019 10:34:02 -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=YY7KeW+rla3p4BATYpbDyKYtWVRckIjg81ALj6799RY=; b=mYAjviaqxoBuuwY2H1AZNBKKAGyRE7owAFSvk7ZZ7dlMY3DJeeVVUKdHNH6dkCE0W/ aW0rYURU7NeWibSGUtDB7WjCNfdmFNUMwXEe7NIjXOAxc2+bDmp1XWF9N9fO6Vry393H kFOYy9sEhIf9bl6y4dXsGs+W/gejh1wwdDYVc= 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=YY7KeW+rla3p4BATYpbDyKYtWVRckIjg81ALj6799RY=; b=QqocU/DSFTCTl9osgKUwSVnjlqiYjjQPAIT1YXU5PduPqzrHL2/42DlgRF6CUZG9gj 58j81dhPpzJ3V9RF5/xdntE08mwjgvc9B5lQGP3QPGZe1KhD+X0EiH5gnBPRN5yxRfNl zhCyAtNG65Iy4/I+XWe1nrZZyR8rMct0llEbYZMZv5LxHkf8Y131o9fP07W3xvOsQ4bC aUtAWnoOyuBpRZ2b2/XOKZeeA3wRFU/rydVKOhZxlaL+4H7fMaQ/oE/JpcNil6ftoapU Da3aNnVi1fyIUdidRNHRLHJ+KiOGMWaZS+LbNqZ2ZXtX2RE5zF7a13s9e+vkVNC+2T6l oUDw== X-Gm-Message-State: APjAAAUHzXKqoEosv4hAHYvk3GkSQMEMk3HYeP5lLczNOq3VFy036CC5 p+m4oTFFR2gVdQLMoELxYwjMWFyTY1GyTl6CPGf9lkA8ALk= X-Google-Smtp-Source: APXvYqxiQSYs73FiYn//TqfGI1YXajAUdQswf7hj2b2i5WeBHizHpY6T6nSUSN768jWL/IUuum9slAWTl7ZEF+0zZCI= X-Received: by 2002:a6b:ce19:: with SMTP id p25mr16624668iob.201.1565544841440; Sun, 11 Aug 2019 10:34:01 -0700 (PDT) MIME-Version: 1.0 References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> In-Reply-To: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> From: Ulysse Carion Date: Sun, 11 Aug 2019 10:33:50 -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: extensibility and unspecified properties 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, 12 Aug 2019 07:43:52 -0000 > This is a nice demonstration that it was a mistake to remove uint53. Perhaps. But perhaps instead I should just use {"type": "number"}, and accept that JSL isn't going to be able to express certain things about numbers? Re-reading https://tools.ietf.org/html/rfc7071, it seems it constrains the timestamps to not have a fractional part at the JSON syntax level. That's another thing JSL can't deal with. But I'm not sure if in practice that's such a big deal. On Fri, Aug 9, 2019 at 11:23 PM Carsten Bormann wrote: > > Examples are good: > > This schema [=E2=80=A6] limits =E2=80=9Cgenerated=E2=80=9D and > "expires" to timestamps less than 2^32 seconds after January 1, 1970 > 00:00 UTC. > > This is a nice demonstration that it was a mistake to remove uint53. > > (Note that on 32-bit systems time_t is an int32. But you definitely don= =E2=80=99t want that restriction; 2038 is coming too close now. Uint32 is = completely arbitrary and wrong in many ways.) > > Gr=C3=BC=C3=9Fe, Carsten > From nobody Mon Aug 12 00:50:56 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 77E58121375 for ; Mon, 12 Aug 2019 00:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGjtFMDElovx for ; Mon, 12 Aug 2019 00:49:51 -0700 (PDT) Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (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 5CB8D120E3D for ; Sun, 11 Aug 2019 10:37:55 -0700 (PDT) Received: by mail-ot1-x341.google.com with SMTP id g17so214898otl.2 for ; Sun, 11 Aug 2019 10:37:55 -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=94XiiS+Gky0C/HCh0d2QRgdnpDDzuNw9eptBChPDAh8=; b=el8jZ7ekMiL91lnHf+UcgdYOk9nNkU1vXv9nQjasPmc/Ai0HRQ1eLBs1v3ylLHWe75 OsXWWdSilP9Xcra4yE7Zxi+IYe1xvN4UAD/St56vEQn/QVvWr97ksKMFA3L30zqb7tTR xOmMIK0R4L/2Hb1GT23hFLxGGvrIKBYC5Gn/k= 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=94XiiS+Gky0C/HCh0d2QRgdnpDDzuNw9eptBChPDAh8=; b=gRZMQuaJ13B1M6cB8BSYfo7u+pzDArIsqMHMC132B413d3tgqbv99Y2Ohd3ATal1Y9 H/pkJaj+W8l93KSwXtOuir3g2sGaOFER05dUfaFPsbMjrR5akvm+nDgtjuVLS3ioY7BD ArQ2f13nq/hbpJjkTR3a3QeelwoIOzGVf+lHiWOzgumoTcY92U9/oVSMEod0pYM/l8Sf +LzV0Y6ZUkd5uacnLV/dl9dowrVOBnqxBrgUEXA5r/KDNv0oYuok3WVPZsN1BIyA3nWI QN/2Ia6hyIFRZSd4G/EGP1E+xojclQ3CqEApV9GyaRUVFHQnpbcmi6Xn04G500+tMkMt 5hJg== X-Gm-Message-State: APjAAAWH6KrO+kdE5IemIv/uQRkVPjRKk2f3b/u7G8EJmYy+3yiC2Mm5 MA5qEzk+NrhAQGvBWds6eTV9yL0+ydiwhWqgARBjerm4Jn4= X-Google-Smtp-Source: APXvYqxLXcGMayAY2wNgWAUxUINvmVoWQ1Y6wlARYWJrJyOvKrK04jdRkfTnhyrdnFtBLyegBpkYwTO0NFH0lzwogHc= X-Received: by 2002:a5e:d507:: with SMTP id e7mr18253052iom.284.1565545074631; Sun, 11 Aug 2019 10:37:54 -0700 (PDT) MIME-Version: 1.0 References: <8d56f00d-14af-c387-ff02-e279cca6ddea@gmail.com> In-Reply-To: <8d56f00d-14af-c387-ff02-e279cca6ddea@gmail.com> From: Ulysse Carion Date: Sun, 11 Aug 2019 10:37:43 -0700 Message-ID: To: Anders Rundgren Cc: JSON WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 12 Aug 2019 07:50:55 -0000 > How can you express this in a main schema using JCL? I'm not entirely sure I follow your description. Could you illustrate it with some example JSON values? I'm also a bit unclear on your requirements for the "main schema", and how it fits with requirements around "unspecified properties". On Sat, Aug 10, 2019 at 12:00 PM Anders Rundgren wrote: > > If we stick to unspecified properties I'm currently working with a > payment authorization scheme where some components will be defined > by the payment networks. The components start with a defined property > holding a JSON Object but the contents of the object is not known by > the "main" schema. > > In my programmatic solution the "main schema" ignores such components > and only validates that they conform JSON. The components are > then dealt with by customer supplied decoders which indeed may use > a schema. > > How can you express this in a main schema using JCL? > > Anders > > paymentRequest = new PaymentRequest(rd.getObject(PAYMENT_REQUEST_JSON)); > undecodedPaymentMethodSpecific = rd.getObject(BACKEND_METHOD_SPECIFIC_JSON); > rd.scanAway(BACKEND_METHOD_SPECIFIC_JSON); > referenceId = rd.getString(REFERENCE_ID_JSON); > > > On 2019-08-10 03:43, Ulysse Carion wrote: > > Hi folks, > > > > Thanks again for all the wonderful suggestions for JSON Schema > > Language. I've just published a new draft incorporating suggestions > > from the last update. You can read it here: > > > > https://tools.ietf.org/html/draft-ucarion-json-schema-language-02 > > > > I would like advice on the two following changes I've made to the spec. > > > > First, I added explicit discussion of how JSL can be extended. The > > language is at the end of section 2, but I'll reproduce it here: > > > >> This document does not describe any extension mechanisms for JSL schema > >> validation. However, schemas (through the `non-keyword` CDDL rule in this > >> section) are defined to allow members whose names are not equal to any of the > >> specially-defined keywords (i.e. `definitions`, `elements`, etc.) described in > >> this section. Call these members "non-keyword members". > >> > >> Users MAY add additional, non-keyword members to JSL schemas to convey > >> information that is not pertinent to validation. For example, such non-keyword > >> members could provide hints to code generators, or trigger some special behavior > >> for a library that generates user interfaces from schemas. > >> > >> Users SHOULD NOT expect non-keyword members to be understood by other parties. > >> As a result, if consistent validation with other parties is a requirement, users > >> SHOULD NOT use non-keyword members to affect how schema validation, as described > >> in {{semantics}}, works. > > > > Basically, my stance is: you can add custom stuff to schemas, but you > > can't change validation. I expect that people will change validation > > anyway, but they're not going to expect portability. I don't feel that > > adding some sort of registry of keywords / forms is valuable yet. > > Perhaps something like that can be in whatever replaces JSL? > > > > How do folks feel about this? Does anyone have suggestions on better > > ways I can approach extensibility, or how I should phrase this > > language? > > > > The other thing I want advice on is "strict" mode, called "strict > > instance semantics" in the spec. Basically, strict instance semantics > > about whether it's ok to send "extra"/"unknown"/"unspecified" > > properties in an object. > > > > Right now, validation behavior is specified as a single, top-level > > "strict": true/false (default is "true") property. You can't mix and > > match strict and non-strict. But Carsten off-list noted that might be > > a bit "blunt". Do others agree? > > > > The context for my decision is that two of major typed languages used > > in industry, Java and Golang, don't typically support mixing and > > matching. Go just as a blunt DisallowUnknownFields: > > > > https://golang.org/pkg/encoding/json/#Decoder.DisallowUnknownFields > > > > And Java's Jackson has a FAIL_ON_UNKNOWN_PROPERTIES: > > > > http://fasterxml.github.io/jackson-databind/javadoc/2.9/com/fasterxml/jackson/databind/DeserializationFeature.html#FAIL_ON_UNKNOWN_PROPERTIES > > > > Both are all or nothing. > > > > Also, there is the question of whether "strict" is a good name for > > this property in schemas. Is there a better name for it? "strict" can > > be understood in many ways. Open to ideas here as well. > > > > Other changes: > > > > - Removed int64/uint64 (and removed discussion related to I-JSON) > > - Clarified that 1.0e1 is an integer > > > > Finally, I've moved JSL to a desired status of "Informative", and I'll > > be going through the independent stream once the discussion here > > appears to have settled. > > > > Thanks again for all the help, > > Ulysse > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > > From nobody Mon Aug 12 05:17: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 B34CA120F15 for ; Mon, 12 Aug 2019 05:16:59 -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 mTLID_cZW-ze for ; Mon, 12 Aug 2019 05:16:06 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24CC12097C for ; Sun, 11 Aug 2019 13:06:28 -0700 (PDT) Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46693Q546Zzysr; Sun, 11 Aug 2019 22:06:26 +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, 11 Aug 2019 22:06:26 +0200 Cc: JSON WG X-Mao-Original-Outgoing-Id: 587246784.714946-8311f4f1d05817dc7b42d0d7fe797fa9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> To: Ulysse Carion X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 12 Aug 2019 12:17:00 -0000 On Aug 11, 2019, at 19:33, Ulysse Carion wrote: >=20 >> This is a nice demonstration that it was a mistake to remove uint53. >=20 > Perhaps. But perhaps instead I should just use {"type": "number"}, and > accept that JSL isn't going to be able to express certain things about > numbers? Sure, that is one way of handling it. However, it seems bizarre to support int8, int16, and int32, but not = JSON=E2=80=99s generic interoperable integers. > Re-reading https://tools.ietf.org/html/rfc7071, it seems it constrains > the timestamps to not have a fractional part at the JSON syntax level. Oops. (I=E2=80=99d consider this an erratum, though, as Section 2.4 of RFC = 4627 does not define =E2=80=9Cinteger=E2=80=9D.) > That=E2=80=99s another thing JSL can't deal with. Actually, that=E2=80=99s something JSON can=E2=80=99t deal with. > But I'm not sure if in > practice that=E2=80=99s such a big deal. MS-Excel has repeatedly taught me that my university phone number is = 2.1863921e7, but people still manage to call me :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 12 22:04: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 A841512007C for ; Mon, 12 Aug 2019 22:04:09 -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=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 ZVrY3bxZYvoW for ; Mon, 12 Aug 2019 22:04:07 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 2AC41120073 for ; Mon, 12 Aug 2019 22:04:07 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id f17so32462947otq.4 for ; Mon, 12 Aug 2019 22:04:07 -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=dkL4baXQTL2J9pEhS+Gps1ALW6gKZaE4iEE/vMvG884=; b=N6oy14skCVuEYKGP0Y3bgDb7ChkngHT0gR4iQtjOKCLpUMVUXUKxD0WR+5xIusxIY8 8+JSJVVG/qzmi8ExAnGhrdimnDTB/PZxrQPm9fxlKg1OXgpMKnpvtOa3ftwNiK0xk0Bk 7xCw16KffqL+tr2ZDSeU1CmQ7rxNmgI3AO0xY= 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=dkL4baXQTL2J9pEhS+Gps1ALW6gKZaE4iEE/vMvG884=; b=gGtPIqbu+rz6ycAjaM5rtG9Vnp7K5FJc2oPZNsBdJJwwR02VSjoK824FYz0WLSvR/F 0MOFuPRP4N43swTlqDoQc+JvddD5iFI0fbQ5JHqYUrUzeaSIGCrt3ltxIE7T8cob7OEi uMQSp7rC0Xk0LdlsffE2v8AJMjAKmnG8OzFAvHkDhlracNSx+hQcwl0oKQF8YMRzJ5do 5xV+Aqpqu6ir9xwiFcKT/T9+HbWGfypjnnL5Vlk+rLJ0P3ZjhlZBe3xzoi/nNsrTf5jI LxHywZ2oUtaerp4XcWRfvfMS0Uxv2kz2AcC183dAzF3CBtRE8gHnmLjW7fldk99U4gW7 KjEg== X-Gm-Message-State: APjAAAVZ2Wgf34MSGc+eRsYR5FJz44/6Mc4xrK/K5HbIAu76V9TOHRiB mm+KmV/S0QwvSuLEw04pU+/eFdHqI4ErAfK2aXRYEOMzeEw= X-Google-Smtp-Source: APXvYqx8CiTMgskK8cp+/FP40ozN71s6cFR4BzL22RxydGtyYnm3iMcBlwYR0UajnJX3vud/OfSdDaNpWdD79KyziBA= X-Received: by 2002:a02:952d:: with SMTP id y42mr16663626jah.66.1565672646198; Mon, 12 Aug 2019 22:04:06 -0700 (PDT) MIME-Version: 1.0 References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> In-Reply-To: From: Ulysse Carion Date: Mon, 12 Aug 2019 22:03:55 -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: extensibility and unspecified properties 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, 13 Aug 2019 05:04:10 -0000 > However, it seems bizarre to support int8, int16, and int32, but not JSON= =E2=80=99s generic interoperable integers. Supposing we add int53 to JSL, do you picture code generators producing int64_t/long for {"type": "int53" }? Does that mean that, before serializing an int64_t to something marked as int53 in JSL, the application must first do an extra bounds check? Today, it's fairly easy to generate code from JSL where serializing is an infallible affair. But with int53, that property would be lost, because most type systems cannot express int53. I'm inclined to think this is something better handled by extensions. Perhaps someone can define a "intt53" property to do something like: { "type": "number", "int53": true } The person writing the extension would document that the "int53" property indicates whether a number is meant to represent a number in the I-JSON range. Applications which don't understand this keyword will still do something reasonable -- validate for some sort of number, and code generate a "double" -- but applications which care about this can handle this case specially. It also signals an intent about how the number will be used. I expect this sort of approach is how JSL may need to handle big-number encoding schemes. There are so many different ways approach that problem, and I think JSL is most useful if it establishes an uncontroversial foundation, and then lets additional, out-of-spec keywords tighten the schema further in a way which most folks don't care about, and hence don't want to have to implement. Does that seem like a reasonable approach? > Actually, that=E2=80=99s something JSON can=E2=80=99t deal with. By this you mean that JSON prescribes "all numbers are doubles", and so integers aren't really a good thing to try to foist onto JSON's syntax? > MS-Excel has repeatedly taught me that my university phone number is 2.18= 63921e7, but people still manage to call me :-) Could you expand what you mean here? I realize no joke is funny enough to survive explanation, but I'm afraid I'm perhaps missing your point. On Sun, Aug 11, 2019 at 1:06 PM Carsten Bormann wrote: > > On Aug 11, 2019, at 19:33, Ulysse Carion wrote: > > > >> This is a nice demonstration that it was a mistake to remove uint53. > > > > Perhaps. But perhaps instead I should just use {"type": "number"}, and > > accept that JSL isn't going to be able to express certain things about > > numbers? > > Sure, that is one way of handling it. > However, it seems bizarre to support int8, int16, and int32, but not JSON= =E2=80=99s generic interoperable integers. > > > Re-reading https://tools.ietf.org/html/rfc7071, it seems it constrains > > the timestamps to not have a fractional part at the JSON syntax level. > > Oops. > (I=E2=80=99d consider this an erratum, though, as Section 2.4 of RFC 4627= does not define =E2=80=9Cinteger=E2=80=9D.) > > > That=E2=80=99s another thing JSL can't deal with. > > Actually, that=E2=80=99s something JSON can=E2=80=99t deal with. > > > But I'm not sure if in > > practice that=E2=80=99s such a big deal. > > MS-Excel has repeatedly taught me that my university phone number is 2.18= 63921e7, but people still manage to call me :-) > > Gr=C3=BC=C3=9Fe, Carsten > From nobody Mon Aug 12 22:31: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 74136120088 for ; Mon, 12 Aug 2019 22:31:52 -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 txrjblTeTHRE for ; Mon, 12 Aug 2019 22:31:50 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4F0120077 for ; Mon, 12 Aug 2019 22:31:49 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4671YH6bSfz10pP; Tue, 13 Aug 2019 07:31:47 +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, 13 Aug 2019 07:31:47 +0200 Cc: JSON WG X-Mao-Original-Outgoing-Id: 587367104.3199871-76b87a4c43c17fedf4fe43effac15e3e Content-Transfer-Encoding: quoted-printable Message-Id: <118F844A-453D-497D-8107-CF2BD05AC313@tzi.org> References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> To: Ulysse Carion X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 13 Aug 2019 05:31:52 -0000 On Aug 13, 2019, at 07:03, Ulysse Carion wrote: >=20 >> However, it seems bizarre to support int8, int16, and int32, but not = JSON=E2=80=99s generic interoperable integers. >=20 > Supposing we add int53 to JSL, do you picture code generators > producing int64_t/long for {"type": "int53" }? Does that mean that, > before serializing an int64_t to something marked as int53 in JSL, the > application must first do an extra bounds check? Today, it's fairly > easy to generate code from JSL where serializing is an infallible > affair. But with int53, that property would be lost, because most type > systems cannot express int53. Many type systems don=E2=80=99t have a uint8, either. > I'm inclined to think this is something better handled by extensions. > Perhaps someone can define a "intt53" property to do something like: >=20 > { "type": "number", "int53": true } >=20 > The person writing the extension would document that the "int53" > property indicates whether a number is meant to represent a number in > the I-JSON range. Applications which don't understand this keyword > will still do something reasonable -- validate for some sort of > number, and code generate a "double" -- but applications which care > about this can handle this case specially. It also signals an intent > about how the number will be used. Again, the same is true for uint8. (This opens the whole =E2=80=9Ctypes vs. subtypes=E2=80=9D discussion.) > I expect this sort of approach is how JSL may need to handle > big-number encoding schemes. There are so many different ways approach > that problem, and I think JSL is most useful if it establishes an > uncontroversial foundation, and then lets additional, out-of-spec > keywords tighten the schema further in a way which most folks don't > care about, and hence don't want to have to implement. >=20 > Does that seem like a reasonable approach? >=20 >> Actually, that=E2=80=99s something JSON can=E2=80=99t deal with. >=20 > By this you mean that JSON prescribes "all numbers are doubles", and > so integers aren't really a good thing to try to foist onto JSON's > syntax? Integer is a mathematical concept. JSON does not have a problem with = that. The problem comes in when applications arbitrarily restrict the syntax. Not allowing a fractional or exponent part is akin to requiring two = spaces of indentation before or a newline after a number. It gets worse when syntax variations are assigned different application = semantics. (E.g., I=E2=80=99m aware of at least one =E2=80=9CJSON-based=E2=80=9D = syntax where a string that starts with =E2=80=9C\u0073=E2=80=9D has = semantics different from a string that starts with =E2=80=9Cs=E2=80=9D.) You can=E2=80=99t do that to a format like JSON and still be part of the = JSON ecosystem, because generic JSON decoders discard these syntax = features, and generic JSON encoders generally can=E2=80=99t produce = them. >> MS-Excel has repeatedly taught me that my university phone number is = 2.1863921e7, but people still manage to call me :-) >=20 > Could you expand what you mean here? I realize no joke is funny enough > to survive explanation, but I=E2=80=99m afraid I'm perhaps missing = your point. Well, my phone number is 21863921, but some spreadsheets consider this a = large number and turn it into an NR3 number=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Aug 17 18:35:14 2019 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71A21200EC for ; Sat, 17 Aug 2019 18:35: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQeFzymckgUL for ; Sat, 17 Aug 2019 18:35:10 -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 5CCF61200E5 for ; Sat, 17 Aug 2019 18:35:10 -0700 (PDT) Received: by mail-io1-xd41.google.com with SMTP id e20so13803545iob.9 for ; Sat, 17 Aug 2019 18:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=14XTRiRLToPbcQs6Xsp2y2+CBiN5m6EM7t/eYU5wxUY=; b=CEYyS/rYZqCGnIXmaNi//3CxkndZO0p4BPu7dysUbJJXQvskvLEMOmGGL5sr87/SXI jGeCxjVRlqH+0bRvhNRbeZJrSlaQoaToflljbrf+4oQvDhugDx9nIMN+AtNSlnY3chdy y3sH5At6sm52fGi9UcjOR32opdxkcyjpY/F6A= 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=14XTRiRLToPbcQs6Xsp2y2+CBiN5m6EM7t/eYU5wxUY=; b=pEdwnPUQKbQejzdGmjAArbHa3CsM/XqUSUYEmkd0bwUZPvaKbFtTrSY/Wc16YBNQ20 H98rYKloFiRxiV8rZsnLcCO01xbTwif0n8GXuXDo44eqLZdveWYjJlI+q9XvRIImPJX1 wc8Z3jprJygnEYINsMMPzKd7rd8HaaTduOYzTHXRK7dRuFIMhg8cuv7UWAMyYOXLiXcT G7OTGm4kF2EM0YSMvCCTHK0ZKtHVcJ6w+dk5lUUDp7QTMJbzJPbKiPhRs0ei8u4vtSDr eDrCRgk2wxb3mT+RZJkk0W7gGqQZM2rRSepHKpgLV1f4gYHsO4cq4wb5TTYOo2YAzDhB bLgQ== X-Gm-Message-State: APjAAAWhj5qusX40TBigCKqYk6X8LokIVsil4uQdq0pnDyaD637KA2En sYaGuwOhoBUHoNvI79cl+JJJpWX8+V5bEIsfujde5GMa X-Google-Smtp-Source: APXvYqyihm4WH9W7Gv1bmugtLVx0DQwQKPQ1/tPMEMIvxAcGC1n6ZtxtscVxcGTBQ++Ia8dyELoVO4JQ/vVL3DBLmh4= X-Received: by 2002:a6b:630b:: with SMTP id p11mr8389781iog.284.1566092109574; Sat, 17 Aug 2019 18:35:09 -0700 (PDT) MIME-Version: 1.0 References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> <118F844A-453D-497D-8107-CF2BD05AC313@tzi.org> In-Reply-To: <118F844A-453D-497D-8107-CF2BD05AC313@tzi.org> From: Ulysse Carion Date: Sat, 17 Aug 2019 18:34:58 -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: extensibility and unspecified properties 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, 18 Aug 2019 01:35:13 -0000 Carsten, I think you are bringing up an important point. I should clarify what is and isn't a type in the spec, and what the principle is for deciding that. I'd like to add a brief discussion of that reasoning in the introduction of the next draft. Does this principle make sense to folks here? "Only include in the spec things which are (1) commonly (and portably) used in the JSON ecosystem, and (2) which have a clear mapping to programming languages in widespread use today." By that standard, int64/uint64 fails (1), as it's unportable (i.e., not I-JSON) or implemented in a bunch mutually incompatible methods. int53 fails (2) because no mainstream language I know of has support for integers strictly up to 2^53. I disagree with you about uint8. I think we agree it satisfies (1); it seems we disagree on whether it passes (2)? Perhaps you were thinking of Java's strictly-signed "byte". If so: by convention, Java folks ignore the signed-ness of byte when uint8 is needed. This is perhaps a bit sketchy (since you can so easily mix and match signed and unsigned 8-bit numbers), but it has gotten the job done in many applications. So the spec's uint8 and int8 both correspond to Java's byte, in my view. On the principle above, I think I should remove {"type": "number"} from the spec. It's unclear what "number" means. Does it mean BigDecimal? If so, it's not portable and so fails (1). Does it mean float64? Then just use {"type": "float64"} instead. On Mon, Aug 12, 2019 at 10:31 PM Carsten Bormann wrote: > > On Aug 13, 2019, at 07:03, Ulysse Carion wrote: > > > >> However, it seems bizarre to support int8, int16, and int32, but not J= SON=E2=80=99s generic interoperable integers. > > > > Supposing we add int53 to JSL, do you picture code generators > > producing int64_t/long for {"type": "int53" }? Does that mean that, > > before serializing an int64_t to something marked as int53 in JSL, the > > application must first do an extra bounds check? Today, it's fairly > > easy to generate code from JSL where serializing is an infallible > > affair. But with int53, that property would be lost, because most type > > systems cannot express int53. > > Many type systems don=E2=80=99t have a uint8, either. > > > I'm inclined to think this is something better handled by extensions. > > Perhaps someone can define a "intt53" property to do something like: > > > > { "type": "number", "int53": true } > > > > The person writing the extension would document that the "int53" > > property indicates whether a number is meant to represent a number in > > the I-JSON range. Applications which don't understand this keyword > > will still do something reasonable -- validate for some sort of > > number, and code generate a "double" -- but applications which care > > about this can handle this case specially. It also signals an intent > > about how the number will be used. > > Again, the same is true for uint8. > > (This opens the whole =E2=80=9Ctypes vs. subtypes=E2=80=9D discussion.) > > > I expect this sort of approach is how JSL may need to handle > > big-number encoding schemes. There are so many different ways approach > > that problem, and I think JSL is most useful if it establishes an > > uncontroversial foundation, and then lets additional, out-of-spec > > keywords tighten the schema further in a way which most folks don't > > care about, and hence don't want to have to implement. > > > > Does that seem like a reasonable approach? > > > >> Actually, that=E2=80=99s something JSON can=E2=80=99t deal with. > > > > By this you mean that JSON prescribes "all numbers are doubles", and > > so integers aren't really a good thing to try to foist onto JSON's > > syntax? > > Integer is a mathematical concept. JSON does not have a problem with tha= t. > > The problem comes in when applications arbitrarily restrict the syntax. > > Not allowing a fractional or exponent part is akin to requiring two space= s of indentation before or a newline after a number. > > It gets worse when syntax variations are assigned different application s= emantics. > (E.g., I=E2=80=99m aware of at least one =E2=80=9CJSON-based=E2=80=9D syn= tax where a string that starts with =E2=80=9C\u0073=E2=80=9D has semantics = different from a string that starts with =E2=80=9Cs=E2=80=9D.) > > You can=E2=80=99t do that to a format like JSON and still be part of the = JSON ecosystem, because generic JSON decoders discard these syntax features= , and generic JSON encoders generally can=E2=80=99t produce them. > > >> MS-Excel has repeatedly taught me that my university phone number is 2= .1863921e7, but people still manage to call me :-) > > > > Could you expand what you mean here? I realize no joke is funny enough > > to survive explanation, but I=E2=80=99m afraid I'm perhaps missing your= point. > > Well, my phone number is 21863921, but some spreadsheets consider this a = large number and turn it into an NR3 number=E2=80=A6 > > Gr=C3=BC=C3=9Fe, Carsten > From nobody Sat Aug 17 18:56: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 847EE12007C for ; Sat, 17 Aug 2019 18:56:00 -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=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 GVmQ5GyLvEPr for ; Sat, 17 Aug 2019 18:55:58 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 04AEF12006D for ; Sat, 17 Aug 2019 18:55:57 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id o9so13863124iom.3 for ; Sat, 17 Aug 2019 18:55:57 -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=HnmbsLZpddM/EtJ0W5xAs2MkeqetOPAbMfi545t3YLI=; b=P8rRxWNHcA7y/JAZ20wfhV69h0IXJSA9WAbD/XfxxCPtug4P7Cou1SBn12MpnKhNIA YgyD9LzVZG3omphWLKlGBHrJJlntaAxyOy8YS/Q7aaAKbCcfjVhAL6iw45jcs9eswNp0 2XFhAAgsIiM4dz4zbIXpPyY8uDiXPsCBYhv6w= 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=HnmbsLZpddM/EtJ0W5xAs2MkeqetOPAbMfi545t3YLI=; b=gnGzZSut9ZG2ZGPbqb1KCmFFLI17QUo0tEDhG75w8VBVVuk8I3VnRjj6ip3jHZRXYB RO0KoMzRmkINP6Fd/FrO5pTchpA61JlI1GaUptyij8dAT8fYXERIu1Yl2gWOifz9poLH bUgfElZ/aBiKM0alfgii8AP2Df5GGJFaAsITq82ZcVlkJ/uibPleYmTWcCQViJXj14C4 fLgul2H+y5zISiFvJn23srtjEnKOEHfbIhkS7jiQ0oW4HH5miEoxGicBxnWr6wGUE2yk eQXcwuaMqAsi0F8a3VCBsykQpPHSHzX8u274onicOBnOPXJ87Do1VQtik7bNPv137wzB 4+bg== X-Gm-Message-State: APjAAAVrl0sv2DGCT2owEgj8+vhQSrfZD3P2f2eeHv8L/wQJjEHWTrNp ipL6RaBM+oxWwaduK15SItWVJfetWn6hOGvJ+vXt8w== X-Google-Smtp-Source: APXvYqwAOKbqH3LhP02YGC26NfUjnKyV97RpPvCCafMQCQBHf/nln285l7rdBIhhRADhDLJhDChfDULk/1R5lVQpG/4= X-Received: by 2002:a6b:ce19:: with SMTP id p25mr19016233iob.201.1566093357160; Sat, 17 Aug 2019 18:55:57 -0700 (PDT) MIME-Version: 1.0 References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> <118F844A-453D-497D-8107-CF2BD05AC313@tzi.org> In-Reply-To: From: Ulysse Carion Date: Sat, 17 Aug 2019 18:55:46 -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: extensibility and unspecified properties 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, 18 Aug 2019 01:56:01 -0000 Also: from off-list discussion, and from talking with folks in industry about their experiences taking legacy systems and retrofitting schemas onto them, I think the spec's current approach to "unexpected/unspecified/additional" properties is inadequate. In the current draft, whether to tolerate properties not mentioned in a schema is a global option on the schema. This is not good enough, because oftentimes folks only progressively lock down parts of their schema -- some parts are better documented and can be locked down, but other parts may be inscrutable or just too risky to lock down. So I'm thinking, in the next draft, for schemas -- be they root schemas or sub-schemas -- to be able to specify whether they'll allow properties outside those mentioned in properties/optionalProperties. Also, since "strict" is super vague, I'll rename it "additionalProperties". It'll still take true/false, but now the default is "false" and the value's meaning is flipped. On Sat, Aug 17, 2019 at 6:34 PM Ulysse Carion wrote: > > Carsten, I think you are bringing up an important point. I should > clarify what is and isn't a type in the spec, and what the principle > is for deciding that. > > I'd like to add a brief discussion of that reasoning in the > introduction of the next draft. Does this principle make sense to > folks here? > > "Only include in the spec things which are (1) commonly (and portably) > used in the JSON ecosystem, and (2) which have a clear mapping to > programming languages in widespread use today." > > By that standard, int64/uint64 fails (1), as it's unportable (i.e., > not I-JSON) or implemented in a bunch mutually incompatible methods. > int53 fails (2) because no mainstream language I know of has support > for integers strictly up to 2^53. > > I disagree with you about uint8. I think we agree it satisfies (1); it > seems we disagree on whether it passes (2)? Perhaps you were thinking > of Java's strictly-signed "byte". If so: by convention, Java folks > ignore the signed-ness of byte when uint8 is needed. This is perhaps a > bit sketchy (since you can so easily mix and match signed and unsigned > 8-bit numbers), but it has gotten the job done in many applications. > So the spec's uint8 and int8 both correspond to Java's byte, in my > view. > > On the principle above, I think I should remove {"type": "number"} > from the spec. It's unclear what "number" means. Does it mean > BigDecimal? If so, it's not portable and so fails (1). Does it mean > float64? Then just use {"type": "float64"} instead. > > On Mon, Aug 12, 2019 at 10:31 PM Carsten Bormann wrote: > > > > On Aug 13, 2019, at 07:03, Ulysse Carion wrote: > > > > > >> However, it seems bizarre to support int8, int16, and int32, but not= JSON=E2=80=99s generic interoperable integers. > > > > > > Supposing we add int53 to JSL, do you picture code generators > > > producing int64_t/long for {"type": "int53" }? Does that mean that, > > > before serializing an int64_t to something marked as int53 in JSL, th= e > > > application must first do an extra bounds check? Today, it's fairly > > > easy to generate code from JSL where serializing is an infallible > > > affair. But with int53, that property would be lost, because most typ= e > > > systems cannot express int53. > > > > Many type systems don=E2=80=99t have a uint8, either. > > > > > I'm inclined to think this is something better handled by extensions. > > > Perhaps someone can define a "intt53" property to do something like: > > > > > > { "type": "number", "int53": true } > > > > > > The person writing the extension would document that the "int53" > > > property indicates whether a number is meant to represent a number in > > > the I-JSON range. Applications which don't understand this keyword > > > will still do something reasonable -- validate for some sort of > > > number, and code generate a "double" -- but applications which care > > > about this can handle this case specially. It also signals an intent > > > about how the number will be used. > > > > Again, the same is true for uint8. > > > > (This opens the whole =E2=80=9Ctypes vs. subtypes=E2=80=9D discussion.) > > > > > I expect this sort of approach is how JSL may need to handle > > > big-number encoding schemes. There are so many different ways approac= h > > > that problem, and I think JSL is most useful if it establishes an > > > uncontroversial foundation, and then lets additional, out-of-spec > > > keywords tighten the schema further in a way which most folks don't > > > care about, and hence don't want to have to implement. > > > > > > Does that seem like a reasonable approach? > > > > > >> Actually, that=E2=80=99s something JSON can=E2=80=99t deal with. > > > > > > By this you mean that JSON prescribes "all numbers are doubles", and > > > so integers aren't really a good thing to try to foist onto JSON's > > > syntax? > > > > Integer is a mathematical concept. JSON does not have a problem with t= hat. > > > > The problem comes in when applications arbitrarily restrict the syntax. > > > > Not allowing a fractional or exponent part is akin to requiring two spa= ces of indentation before or a newline after a number. > > > > It gets worse when syntax variations are assigned different application= semantics. > > (E.g., I=E2=80=99m aware of at least one =E2=80=9CJSON-based=E2=80=9D s= yntax where a string that starts with =E2=80=9C\u0073=E2=80=9D has semantic= s different from a string that starts with =E2=80=9Cs=E2=80=9D.) > > > > You can=E2=80=99t do that to a format like JSON and still be part of th= e JSON ecosystem, because generic JSON decoders discard these syntax featur= es, and generic JSON encoders generally can=E2=80=99t produce them. > > > > >> MS-Excel has repeatedly taught me that my university phone number is= 2.1863921e7, but people still manage to call me :-) > > > > > > Could you expand what you mean here? I realize no joke is funny enoug= h > > > to survive explanation, but I=E2=80=99m afraid I'm perhaps missing yo= ur point. > > > > Well, my phone number is 21863921, but some spreadsheets consider this = a large number and turn it into an NR3 number=E2=80=A6 > > > > Gr=C3=BC=C3=9Fe, Carsten > > From nobody Sun Aug 18 18:32: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 95AE512007A for ; Sun, 18 Aug 2019 18:32:27 -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 vPJ3BXpQPuqC for ; Sun, 18 Aug 2019 18:32:26 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 20439120052 for ; Sun, 18 Aug 2019 18:32:26 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id x3so185915lji.5 for ; Sun, 18 Aug 2019 18:32:26 -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=RyyqAuD9puwVYR7iLsUmRbknum3TQnBC/8F2YRg55Xw=; b=i/B8t8kYZWwoTKTYNr2+b3QD0B9xNsfNOEsyohkbzGsanvHWv8k+J7UZgKpbvVoa+A bhiYxSIOSfOAQ+q2Szxta6IYqIMiDUDEZISMMt4ZX0VXYudv7BM8u9xIpqH2LDtFCRm6 3acoXwJI8LcC0bq67CRA5KWaxA8UQf6AfJePE80I3oPZRWxsVjsnFjdWHWUriTD7w0Gp +vIKdWp98s7B70ZUrdywFv1TdnAMsUEOzzB+GuBi/7CvAoWB6B/UogGcwXjK9efkqTU/ STYmPUf48DI2xc1kR5w+gWNoNDkFZoHU/p5hXZaecm70paau2ueetnB2L6+9jRpnk9Ht dAoQ== 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=RyyqAuD9puwVYR7iLsUmRbknum3TQnBC/8F2YRg55Xw=; b=J/7zTXjLUPnD9f10J17icP/M+j+Q6us9ANLhmGcGAi8yA7KZSzMreGRuCNw6ZI4FQ6 bSgoZOau42WcbRpec4w6e6vANM2hMnnYvt3UhdHjdr6nQm/8lpLSpWW6DRLiH4ytsd1l g79xadhjomKm2KNW9g8Nlr2BuHKh3efope3zx+rJcEBA74j3gwQL7eyXC8y8sv7iHvVL kbKyb7zP8Q7lLWNhoyUiPVti+7wsqraFVyoliLSWP7eUPjq2cqOymWJCbK4bSI/OPRK/ 3PmM1pMfALqMZivFqlro5PwIB6q88XypxtibwAfI+ycqY5+J001yMS2b69e1jBwxIsXN DIkQ== X-Gm-Message-State: APjAAAXtNK7+j74hkSb4T6QBdVUcbQ+DoFuKoeit6fSsK5TA3DI0gisX +FDNb3cMS9dlcFR1K0nNBlwgQkvpJplxqfCpUDY= X-Google-Smtp-Source: APXvYqyRybWEYV2GmaztqfeWUGpfKcza4IdTL489yMgxdTnzNvVaaVMGHwYumIYvo2HGAcM+fb+qDkSW9QL1D8JDB+k= X-Received: by 2002:a2e:864c:: with SMTP id i12mr10894407ljj.88.1566178344344; Sun, 18 Aug 2019 18:32:24 -0700 (PDT) MIME-Version: 1.0 References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> <118F844A-453D-497D-8107-CF2BD05AC313@tzi.org> In-Reply-To: From: Richard Gibson Date: Sun, 18 Aug 2019 21:32:13 -0400 Message-ID: To: Ulysse Carion Cc: Carsten Bormann , JSON WG Content-Type: multipart/alternative; boundary="000000000000dea11505906e4f07" Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 19 Aug 2019 01:32:28 -0000 --000000000000dea11505906e4f07 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 17, 2019 at 9:35 PM Ulysse Carion wrote: > no mainstream language I know of has support for integers strictly up to > 2^53 > >From a certain point of view, nearly all mainstream languages do so, because that is the maximum value in the range of contiguous IEEE 754 binary64 integers and thus the upper bound on portable integers (which is why RFC 7493 section 2.2 limits I-JSON numbers to being strictly less than it). But you're right that languages have no int53-specific type, because those with specific integer types have at least the larger range of int64 and those without them have the larger reduced-precision range of binary64. But is the portability argument not sufficient for including such a constraint, as it was for I-JSON? --000000000000dea11505906e4f07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 17, 2019 at 9:35 PM Ulysse Ca= rion <ulysse@segment.com> w= rote:
no mainstream language I know of has support for integers = strictly up to 2^53

From a certain poin= t of view, nearly all mainstream languages do so, because that is the maxim= um value in the range of contiguous IEEE 754 binary64 integers and thus the= upper bound on portable integers (which is why RFC 7493 section 2.2 limits= I-JSON numbers to being strictly less than it). But you're right that = languages have no int53-specific type, because those with specific integer = types have at least the larger range of int64 and those without them have t= he larger reduced-precision range of binary64. But is the portability argum= ent not sufficient for including such a constraint, as it was for I-JSON?
--000000000000dea11505906e4f07-- From nobody Mon Aug 19 13:46: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 0B1C612016E for ; Mon, 19 Aug 2019 13:46:56 -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=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 5OomRLS2b9u3 for ; Mon, 19 Aug 2019 13:46:52 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 0ACA1120048 for ; Mon, 19 Aug 2019 13:46:52 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id s21so7370824ioa.1 for ; Mon, 19 Aug 2019 13:46:51 -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=xJy4xSL/Si8Z8cXKLlR+Aiyy8air1cX8eZJKRbY6dqw=; b=NDfPoImihshKCBb3g1+v0CbG/mKf3t4Om6zgs9ZjFM+QavJUMumUw7LoCSJBXsFGBl GnvT7rdKtLHhljSf62wWpniqY+lV+2mBkfIEKogqE5SlD+DPc91fp464QqYz0xBTzCsW Sn8KKvUFHiLlFCmIsiTty1GHaW/G+WFDLs7F0= 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=xJy4xSL/Si8Z8cXKLlR+Aiyy8air1cX8eZJKRbY6dqw=; b=QUhvAZjzV/fNRu85yDc21Zg5LcmZEUYxIYNKBv86Ba0fcKdahuNZRuq4P5FccDYRLA CCuKQOEEOdfw5l8b6SfmZyDqJq8xusMs1qcs453nTvTJWbGJRnHZcPAU0vBzkjbnuBFY F8X8DeTzazo93DQpVaHdO+ooKa78zbm46xFohw9ODJCT1U0TvrWr3AoK6yNVVVWO13cf Ki4XNW1tPipAFy7aWNHbMGwoNpXc1CahDpbItq4j2ETlEAdc7NJ9T2J4Ihu9bTI0Fo2/ cXxCwsCb1RmyYjwAN57OUrOv3lLNs3WeULNmEm9stLTupPL9JYLKX28o7S7YpKdhxZ5d CZfQ== X-Gm-Message-State: APjAAAVOx6LYgvKIZmbFc0PTeb0iRONIOv0F3UyJ7NynV1NOUX1dL/vp HAEtfbJqevN2hrLW6UAyaIE5io9o4gtoJ/ft97UhGQ== X-Google-Smtp-Source: APXvYqxgaGAY4Nv2CT+cm54eF3u6jlPZg7e5V4avgfZH9waiiOzQTwWYe2DrnRUWEWHPQejcv7r16jigkMce/cQsDPE= X-Received: by 2002:a02:a518:: with SMTP id e24mr20573137jam.44.1566247611240; Mon, 19 Aug 2019 13:46:51 -0700 (PDT) MIME-Version: 1.0 References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> <118F844A-453D-497D-8107-CF2BD05AC313@tzi.org> In-Reply-To: From: Ulysse Carion Date: Mon, 19 Aug 2019 13:46:40 -0700 Message-ID: To: Richard Gibson Cc: Carsten Bormann , JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 19 Aug 2019 20:46:56 -0000 > But is the portability argument not sufficient for including such a const= raint, as it was for I-JSON? What constraint are you referring to here? On Sun, Aug 18, 2019 at 6:32 PM Richard Gibson w= rote: > > On Sat, Aug 17, 2019 at 9:35 PM Ulysse Carion wrote: >> >> no mainstream language I know of has support for integers strictly up to= 2^53 > > > From a certain point of view, nearly all mainstream languages do so, beca= use that is the maximum value in the range of contiguous IEEE 754 binary64 = integers and thus the upper bound on portable integers (which is why RFC 74= 93 section 2.2 limits I-JSON numbers to being strictly less than it). But y= ou're right that languages have no int53-specific type, because those with = specific integer types have at least the larger range of int64 and those wi= thout them have the larger reduced-precision range of binary64. But is the = portability argument not sufficient for including such a constraint, as it = was for I-JSON? From nobody Mon Aug 19 17:52: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 82E7E120122 for ; Mon, 19 Aug 2019 17:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 W-QF70_yI0xZ for ; Mon, 19 Aug 2019 17:52:07 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 6B77B120045 for ; Mon, 19 Aug 2019 17:52:07 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id b29so2752736lfq.1 for ; Mon, 19 Aug 2019 17:52:07 -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=yXubDxEbm+/eFwYzQq4JarrNTn6prkLBHT74U0R03TQ=; b=N3CFyxEsK1E0LcAw2T0JzGgWBqasMTRwp8JyQQMbqC66Ya7rfQZ9YHJFmacf8onbe7 gPwn/MOT8EkV5crq8XoOxFiK5NChad84z0TSkiLTUlqtY3IjxvQCINE/abMd5T75xZPM VonzYwmCrFxxA8gmuFHx5xUpNcW5HgpD6TGwKrAs7oK5YV4aK8RdIFkdcM2GtP9mTkMV laO035YPfeEvNVOzew27gOc9LvEhH9Zg0XhI+Lq9EO/9qF4KnZ+y5Ui4D8xy20syKyv+ 2Iqy66ZvoZuvJ4Wumj3RbeGw+1ik3SYZ9gJXgX3ydPj065cxo35k61LGxb5ikPmqEYSY TN0g== 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=yXubDxEbm+/eFwYzQq4JarrNTn6prkLBHT74U0R03TQ=; b=ciijkm8ZI0FVTw074yVjwXaI22MSWiNdV1UK4JkBZF5ZufMRHIMloJSVFeLtV6CEqV OgZPzseiE0131ZtiF3/wSXY5WdL4UVoRwkEfQoIE8WU7EvLWVfCtrUQ+G4LZM2GG0vME 3Ca2tgNN7/ClO0igX9YdahMaaQ+FM/qXFoz3IG5sqw9etQSF1ekn5VPApExZP86q6RAv ahpxZMBuHMejMwXQwNDpuHuNuR6pvREXrjRx4XKJO3No9XxWfwcKFDKycpqrd6uSJs6G WPEl7sPC+n3FsxB5wpeWL0tbiPDPynhmTn4tiyAnYlH8FGuoxDMlgbdtpbvY+Bzlb0MF Zjew== X-Gm-Message-State: APjAAAWwiWNEV0j6Na5QD8SbZaGlhOKI/RO7+ZecBEGjjlxzx7Xchzms 6bl4izdLWLSNwspDVdvVwR2p0dIY/dRUN5kVsbg= X-Google-Smtp-Source: APXvYqxiId0l9aTo9Uy2wR0ALhN1ogHDR0MOFd5GIRHKUqSUEwuxnalz9e6+G/g4faWwFpFe59qmYmYAQ+i+McNZbaE= X-Received: by 2002:a19:dc14:: with SMTP id t20mr11338892lfg.182.1566262325816; Mon, 19 Aug 2019 17:52:05 -0700 (PDT) MIME-Version: 1.0 References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> <118F844A-453D-497D-8107-CF2BD05AC313@tzi.org> In-Reply-To: From: Richard Gibson Date: Mon, 19 Aug 2019 20:51:54 -0400 Message-ID: To: Ulysse Carion Cc: Carsten Bormann , JSON WG Content-Type: multipart/alternative; boundary="0000000000008e2fea059081ddc6" Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 20 Aug 2019 00:52:09 -0000 --0000000000008e2fea059081ddc6 Content-Type: text/plain; charset="UTF-8" An "int53" type or other means of requiring that a JSON number have zero fractional part and magnitude no greater than 2^53. On Mon, Aug 19, 2019 at 4:46 PM Ulysse Carion wrote: > > But is the portability argument not sufficient for including such a > constraint, as it was for I-JSON? > > What constraint are you referring to here? > On Sun, Aug 18, 2019 at 6:32 PM Richard Gibson > wrote: > > > > On Sat, Aug 17, 2019 at 9:35 PM Ulysse Carion > wrote: > >> > >> no mainstream language I know of has support for integers strictly up > to 2^53 > > > > > > From a certain point of view, nearly all mainstream languages do so, > because that is the maximum value in the range of contiguous IEEE 754 > binary64 integers and thus the upper bound on portable integers (which is > why RFC 7493 section 2.2 limits I-JSON numbers to being strictly less than > it). But you're right that languages have no int53-specific type, because > those with specific integer types have at least the larger range of int64 > and those without them have the larger reduced-precision range of binary64. > But is the portability argument not sufficient for including such a > constraint, as it was for I-JSON? > --0000000000008e2fea059081ddc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
An "int53" type or other means of requiring that= a JSON number have zero fractional part and magnitude no greater than 2^53= .

On Mon, Aug 19, 2019 at 4:46 PM Ulysse Carion <ulysse@segment.com> wrote:
> But is the portability argument not s= ufficient for including such a constraint, as it was for I-JSON?

What constraint are you referring to here?
On Sun, Aug 18, 2019 at 6:32 PM Richard Gibson <richard.gibson@gmail.com> wrot= e:
>
> On Sat, Aug 17, 2019 at 9:35 PM Ulysse Carion <ulysse@segment.com> wrote:
>>
>> no mainstream language I know of has support for integers strictly= up to 2^53
>
>
> From a certain point of view, nearly all mainstream languages do so, b= ecause that is the maximum value in the range of contiguous IEEE 754 binary= 64 integers and thus the upper bound on portable integers (which is why RFC= 7493 section 2.2 limits I-JSON numbers to being strictly less than it). Bu= t you're right that languages have no int53-specific type, because thos= e with specific integer types have at least the larger range of int64 and t= hose without them have the larger reduced-precision range of binary64. But = is the portability argument not sufficient for including such a constraint,= as it was for I-JSON?
--0000000000008e2fea059081ddc6-- From nobody Mon Aug 19 20:26:30 2019 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14694120233 for ; Mon, 19 Aug 2019 20:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtkaEdbmJDDl for ; Mon, 19 Aug 2019 20:26:27 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 7EE861201DB for ; Mon, 19 Aug 2019 20:26:27 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id o9so9135567iom.3 for ; Mon, 19 Aug 2019 20:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SAPOfqrNzhkNieEyRCvWx0IeNrSe/PgBIf8WLgQQMCw=; b=YYfP3TGjP2DY6qa9kxv+zHLE3PHwR5hsmBUYYowZ8LIi67U+itjuXQ3MrGrx2QgTgO 96YvV4cmbQhG7MTbcjPye0Ui2qy77FFOvNT421Z9FE1S3yn+IDNR7AjMGG+rac8/81+o gmLo+6IdjJzYBIaC3dE+68xTlQvdK0039B9Lk= 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=SAPOfqrNzhkNieEyRCvWx0IeNrSe/PgBIf8WLgQQMCw=; b=gp/s2XdLsRPxhonufUnMxJqLDOFdD6WLta0CwjIigvBn1P0rfvxv3iOHS5RRZ05JEw HeheM7T2j8eUmeYrKUOPQ/Z27RE6PW8D+wk/QdgfBjEzur/0KoRlhXOQClx8He1PlWBN S0TjRmL4Mk4KphV3S6r7ZKWwldfjND4r7TRaDGJdb/zAwCC/wM0qxtQO+QUGpiW6jMCt K9G+gZyL0qflzCztpS2BmiTH1jTIMI21TX4p+He6vOTN7P9z7tNyuiofNh1F1jSG4iZP Lw4ek0CdAlP90GX2Mb7ZU7UlXbl0kk3UhMLq6nPw1MEqnJMZQtDS0B/kGhs7M0W+bR8p FTog== X-Gm-Message-State: APjAAAV0MSrYjIvgWVYHYZXbgvAUvGq/Q0sAsRVkz5Jw2dRqNzDFlpwB 6g2Cl31JjuvpsDVJ9NBwuLkpxcQEDlRc4F8KkZxK0g== X-Google-Smtp-Source: APXvYqzQz2Dsq6a1DKk0JWmYXq6P/QFH06SkBenindg79ZSJTCT5UngmrpnmRZ3SKLsgT+tUnCeR7J/OUd5aao6Rmd8= X-Received: by 2002:a5d:9747:: with SMTP id c7mr16469196ioo.244.1566271586679; Mon, 19 Aug 2019 20:26:26 -0700 (PDT) MIME-Version: 1.0 References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> <118F844A-453D-497D-8107-CF2BD05AC313@tzi.org> In-Reply-To: From: Ulysse Carion Date: Mon, 19 Aug 2019 20:26:15 -0700 Message-ID: To: Richard Gibson Cc: Carsten Bormann , JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 20 Aug 2019 03:26:29 -0000 > An "int53" type or other means of requiring that a JSON number have zero = fractional part and magnitude no greater than 2^53. Ah -- in that case, I think it fails the other part of the criterion I put forward: having "a clear mapping to programming languages in widespread use today." In case the language is unclear, my thinking was that both (1) and (2) need to be satisfied for something to be included in the spec. At least on my view, int53's correspondence is unclear -- should it be a double/f64, or a long/int64_t, with a runtime check to make sure it's in-bounds? That's not very idiomatic. Better, in my view, to stick to uncontroversial things? On Mon, Aug 19, 2019 at 5:52 PM Richard Gibson w= rote: > > An "int53" type or other means of requiring that a JSON number have zero = fractional part and magnitude no greater than 2^53. > > On Mon, Aug 19, 2019 at 4:46 PM Ulysse Carion wrote: >> >> > But is the portability argument not sufficient for including such a co= nstraint, as it was for I-JSON? >> >> What constraint are you referring to here? >> On Sun, Aug 18, 2019 at 6:32 PM Richard Gibson wrote: >> > >> > On Sat, Aug 17, 2019 at 9:35 PM Ulysse Carion wro= te: >> >> >> >> no mainstream language I know of has support for integers strictly up= to 2^53 >> > >> > >> > From a certain point of view, nearly all mainstream languages do so, b= ecause that is the maximum value in the range of contiguous IEEE 754 binary= 64 integers and thus the upper bound on portable integers (which is why RFC= 7493 section 2.2 limits I-JSON numbers to being strictly less than it). Bu= t you're right that languages have no int53-specific type, because those wi= th specific integer types have at least the larger range of int64 and those= without them have the larger reduced-precision range of binary64. But is t= he portability argument not sufficient for including such a constraint, as = it was for I-JSON? From nobody Tue Aug 20 04:54:09 2019 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2C81200B2 for ; Tue, 20 Aug 2019 04:54:08 -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 2rAWVhtEwSGu for ; Tue, 20 Aug 2019 04:54:06 -0700 (PDT) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C75120033 for ; Tue, 20 Aug 2019 04:54:05 -0700 (PDT) Received: (qmail 19190 invoked from network); 20 Aug 2019 12:51:30 +0100 Received: from host86-157-45-36.range86-157.btcentralplus.com (HELO ?192.168.1.72?) (86.157.45.36) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 20 Aug 2019 12:51:29 +0100 To: Ulysse Carion , Richard Gibson Cc: Carsten Bormann , JSON WG References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> <118F844A-453D-497D-8107-CF2BD05AC313@tzi.org> From: Pete Cordell Message-ID: Date: Tue, 20 Aug 2019 12:54:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 20 Aug 2019 11:54:08 -0000 On 20/08/2019 04:26, Ulysse Carion wrote: >> An "int53" type or other means of requiring that a JSON number have zero fractional part and magnitude no greater than 2^53. > > Ah -- in that case, I think it fails the other part of the criterion I > put forward: having "a clear mapping to programming languages in > widespread use today." In case the language is unclear, my thinking > was that both (1) and (2) need to be satisfied for something to be > included in the spec. > > At least on my view, int53's correspondence is unclear -- should it be > a double/f64, or a long/int64_t, with a runtime check to make sure > it's in-bounds? That's not very idiomatic. Better, in my view, to > stick to uncontroversial things? IMO, the schema should be about representing what the protocol needs rather than how it is represented on a target machine. An implementation may choose to store an int8 in a 32-bit integer. As long as it does suitable bounds checking at the appropriate points nothing outside the machine need know that it has chosen to do that. There may be cases where there is a need for something that is larger than int32 but more inter-operable than int64. int53 satisfies that need in many cases. Mapping it to either double/f64 or long/int64_t is a local implementation choice. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Tue Aug 20 07:34: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 104A3120074 for ; Tue, 20 Aug 2019 07:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 VoupbmOKxAa4 for ; Tue, 20 Aug 2019 07:34:56 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 8D59212000F for ; Tue, 20 Aug 2019 07:34:55 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id c9so4316744lfh.4 for ; Tue, 20 Aug 2019 07:34:55 -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=wD4i8AYdfIwRrhcQOt+h5U+E+MQ1/H/n3m3qm33DJqM=; b=GKgyx2E3nNbOzWpyuRtUfF+FJ+Xg2BKZAF1t/dY+67hcsp2vcWpduV2Jb06OflwlIm 2GlAm7wd3qrhaKJPlqKKc0mHKMLDg5DGV5rldRh++SB5kKCPFflwOVwmVVcyA7gYU0l8 QlKTpVf8zhTlOp9df6YnwLEBGtHx7N37UBo6SMKr67JLdcnzfQ1Afz69/xsw8bZd0Wsu kIJGErlMZ15jjjAtJBON2XcJrsjlnKjNT/onE55D/kLnQwun2mQ/VMwzSxPrZOcTg5wY liO3I8x2vwKMo9aqxz5V10SAnSP6iues0lj6L4v/mUOrcS2xOczugaDP6KAdlH1BYT85 +ZyA== 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=wD4i8AYdfIwRrhcQOt+h5U+E+MQ1/H/n3m3qm33DJqM=; b=KliKeGjLGDflc3BzAvu5flkCz4ZU/50BWHZRJJI1ijv6sGp1sGa6vWI+oklrjkWPnQ nN1TRaWo96zYbOv2+6QUwNeQuVbCt+Z/Szv3IZO2yP5Kc5VPHfiZCOJkXcpp46Q9CQAP iLMgjdjHTzzEoiHERJw4r86Sxz0x2+UI4WGLPP0kLBNhnbdMCenW53AvoC3lNBdoR7xR Z8HQRRpfRE2Jq24hOKrt3eT9FymZ4mRllln9fqR534HvwkKHeGwLYgNKzudCtKs/8ITT ZdbC+7Oodb6yAKIBGsvVGMA7wLndypLhZQ4D9bdV51+EBX7p0Di2DP1iy2jhusd7l4vK E9XQ== X-Gm-Message-State: APjAAAXkSnl2r5C12JM6oNsNjR22Qbv2aEFAU8tTJk6DwM6Qss/EwMZl Fz4RfaPgAMWAxmeDp+HZ3XC1QoVo9UxsjnBVtmQ= X-Google-Smtp-Source: APXvYqwDkuX8LcTj3dwJmaEsg/lOquD9q4MajtkMcrgnJ8Wzygmd29Sf4xV+zG84SyYYFNN5ur+Zpg50LToVLWdIoNQ= X-Received: by 2002:a19:e04f:: with SMTP id g15mr15952372lfj.46.1566311693878; Tue, 20 Aug 2019 07:34:53 -0700 (PDT) MIME-Version: 1.0 References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> <118F844A-453D-497D-8107-CF2BD05AC313@tzi.org> In-Reply-To: From: Richard Gibson Date: Tue, 20 Aug 2019 10:34:42 -0400 Message-ID: To: Pete Cordell Cc: Ulysse Carion , Carsten Bormann , JSON WG Content-Type: multipart/alternative; boundary="0000000000001f0c6005908d5c78" Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 20 Aug 2019 14:34:58 -0000 --0000000000001f0c6005908d5c78 Content-Type: text/plain; charset="UTF-8" Exactly. binary64 is an obvious option since it is the source of the bounds, but int64 is equally capable of fulfilling the role. Just like int8 imposes constraints on a value without requiring any particular machine-local treatment or representation (which should remain irrelevant to the schema language itself), so too would int53. On Tue, Aug 20, 2019 at 7:54 AM Pete Cordell wrote: > On 20/08/2019 04:26, Ulysse Carion wrote: > >> An "int53" type or other means of requiring that a JSON number have > zero fractional part and magnitude no greater than 2^53. > > > > Ah -- in that case, I think it fails the other part of the criterion I > > put forward: having "a clear mapping to programming languages in > > widespread use today." In case the language is unclear, my thinking > > was that both (1) and (2) need to be satisfied for something to be > > included in the spec. > > > > At least on my view, int53's correspondence is unclear -- should it be > > a double/f64, or a long/int64_t, with a runtime check to make sure > > it's in-bounds? That's not very idiomatic. Better, in my view, to > > stick to uncontroversial things? > > IMO, the schema should be about representing what the protocol needs > rather than how it is represented on a target machine. > > An implementation may choose to store an int8 in a 32-bit integer. As > long as it does suitable bounds checking at the appropriate points > nothing outside the machine need know that it has chosen to do that. > > There may be cases where there is a need for something that is larger > than int32 but more inter-operable than int64. int53 satisfies that need > in many cases. > > Mapping it to either double/f64 or long/int64_t is a local > implementation choice. > > Pete. > -- > --------------------------------------------------------------------- > Pete Cordell > Codalogic Ltd > C++ tools for C++ programmers, http://codalogic.com > Read & write XML in C++, http://www.xml2cpp.com > --------------------------------------------------------------------- > --0000000000001f0c6005908d5c78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Exactly. binary64 is an obvious option since it is the sou= rce of the bounds, but int64 is equally capable of fulfilling the role. Jus= t like int8 imposes constraints on a value without requiring any particular= machine-local treatment or representation (which should remain irrelevant = to the schema language itself), so too would int53.

On Tue, Aug 20, 2019 at = 7:54 AM Pete Cordell <petejson= @codalogic.com> wrote:
On 20/08/2019 04:26, Ulysse Carion wrote:
>> An "int53" type or other means of requiring that a JSON = number have zero fractional part and magnitude no greater than 2^53.
>
> Ah -- in that case, I think it fails the other part of the criterion I=
> put forward: having "a clear mapping to programming languages in<= br> > widespread use today." In case the language is unclear, my thinki= ng
> was that both (1) and (2) need to be satisfied for something to be
> included in the spec.
>
> At least on my view, int53's correspondence is unclear -- should i= t be
> a double/f64, or a long/int64_t, with a runtime check to make sure
> it's in-bounds? That's not very idiomatic. Better, in my view,= to
> stick to uncontroversial things?

IMO, the schema should be about representing what the protocol needs
rather than how it is represented on a target machine.

An implementation may choose to store an int8 in a 32-bit integer. As
long as it does suitable bounds checking at the appropriate points
nothing outside the machine need know that it has chosen to do that.

There may be cases where there is a need for something that is larger
than int32 but more inter-operable than int64. int53 satisfies that need in many cases.

Mapping it to either double/f64 or long/int64_t is a local
implementation choice.

Pete.
--
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
---------------------------------------------------------------------
--0000000000001f0c6005908d5c78-- From nobody Tue Aug 20 12: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 0CC461201DE for ; Tue, 20 Aug 2019 12:05:50 -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=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 8twKedUYC6vL for ; Tue, 20 Aug 2019 12:05:46 -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 8F20A120180 for ; Tue, 20 Aug 2019 12:05:46 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id p12so12056220iog.5 for ; Tue, 20 Aug 2019 12:05:46 -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=pQyL3PNIodtDTdeqdiEH/RF6E11rosvjB4S80O+V/L4=; b=qgnvPtgN1/wEpUsyMjxufsfowGSYqffgMJalkCRd8taNI9Eelwm6CmSk01aS9P5FZE ADN4gi92bqDDjgM2Q/NaqQPj34bD5Z+oL0GBaX6n0GlyHgJiHiKO6+auo6Mw8ZNoXYWD e+nWvf/FwXBVBEDC6dA9fSC68FJi1dHmjv3Lo= 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=pQyL3PNIodtDTdeqdiEH/RF6E11rosvjB4S80O+V/L4=; b=JSODHZeT+XJNRqM/l4JGy3h+/F/KMPjNKB4JbXv1eX56HOE1yR28BYcXAw1fUPqo98 SI+Gb0yvD7jQnqFI2dMQyFzqRslEn+0Df99JjbUb3vin3IM6nN5828Radz8EqAsmj7zo u+dFuuw48atN/it+Y38KEzlr5rp91YCsiZC5zBtFSkoSKFpgX0LHCz0XPvVeuN/g9bo8 KL/Me4Hd/MYOpWa5j1vrlF8kxzqYCXc0RLd/SjeCqDgsVxAuN3tmMZGOrLVFCteyMK4Q A0FcZizqSrg/L40sbF7kFvORxkZbBV62wFdI8RmjejkqUQF5JOyQL/jj3YeUD5NCf15h j0Ig== X-Gm-Message-State: APjAAAUCQ8obtH1xM5E4SPVrx88aQelJ+eWyUOaifIk8WNEu/Ktnmyxm bBzDqNNMWhDnpksXL825Us62L7NUEiMCfL6yI04Vqg== X-Google-Smtp-Source: APXvYqzTG/aGBGL54vA0uuZgq8QDZUqb3rvp/GEVbbpyXGNB6ZjOkxF76x7W45iz2ATKwPESp0spJattPjYRceNkdPM= X-Received: by 2002:a6b:630b:: with SMTP id p11mr21134366iog.284.1566327945739; Tue, 20 Aug 2019 12:05:45 -0700 (PDT) MIME-Version: 1.0 References: <53094378-B559-49E1-B42B-54FBA8BC35AA@tzi.org> <118F844A-453D-497D-8107-CF2BD05AC313@tzi.org> In-Reply-To: From: Ulysse Carion Date: Tue, 20 Aug 2019 12:05:34 -0700 Message-ID: To: Richard Gibson Cc: Pete Cordell , Carsten Bormann , JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties 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, 20 Aug 2019 19:05:50 -0000 > IMO, the schema should be about representing what the protocol needs > rather than how it is represented on a target machine. This is a reasonable stance. But I don't think it's what I'm trying to solve for. My focus has continually been on code generation from schemas; the spec's expressive power is intentionally limited specifically to enable code generation. Optimizing for code generation is why I *am* concerning myself with how things are represented on target machines. There are lots of good options for schemas languages that are focused on being as expressive as protocols are complex -- you've written one of these good options, Pete -- but I've been concerned with making a schema language as inexpressive as mainstream type systems are simple. I'm not debating whether there are ways of representing int53 in many languages. My objection is that I would be making up a type that doesn't exist in existing programming languages natively or idiomatically. If someone wants to do int53 bounds checks, they can always use the float64 type, and then do bounds checking after schema validation. Or they can write an extension. On Tue, Aug 20, 2019 at 7:34 AM Richard Gibson w= rote: > > Exactly. binary64 is an obvious option since it is the source of the boun= ds, but int64 is equally capable of fulfilling the role. Just like int8 imp= oses constraints on a value without requiring any particular machine-local = treatment or representation (which should remain irrelevant to the schema l= anguage itself), so too would int53. > > On Tue, Aug 20, 2019 at 7:54 AM Pete Cordell wro= te: >> >> On 20/08/2019 04:26, Ulysse Carion wrote: >> >> An "int53" type or other means of requiring that a JSON number have z= ero fractional part and magnitude no greater than 2^53. >> > >> > Ah -- in that case, I think it fails the other part of the criterion I >> > put forward: having "a clear mapping to programming languages in >> > widespread use today." In case the language is unclear, my thinking >> > was that both (1) and (2) need to be satisfied for something to be >> > included in the spec. >> > >> > At least on my view, int53's correspondence is unclear -- should it be >> > a double/f64, or a long/int64_t, with a runtime check to make sure >> > it's in-bounds? That's not very idiomatic. Better, in my view, to >> > stick to uncontroversial things? >> >> IMO, the schema should be about representing what the protocol needs >> rather than how it is represented on a target machine. >> >> An implementation may choose to store an int8 in a 32-bit integer. As >> long as it does suitable bounds checking at the appropriate points >> nothing outside the machine need know that it has chosen to do that. >> >> There may be cases where there is a need for something that is larger >> than int32 but more inter-operable than int64. int53 satisfies that need >> in many cases. >> >> Mapping it to either double/f64 or long/int64_t is a local >> implementation choice. >> >> Pete. >> -- >> --------------------------------------------------------------------- >> Pete Cordell >> Codalogic Ltd >> C++ tools for C++ programmers, http://codalogic.com >> Read & write XML in C++, http://www.xml2cpp.com >> --------------------------------------------------------------------- From nobody Tue Aug 20 21: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 7488B120106 for ; Tue, 20 Aug 2019 21:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=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 c0NBFUKAGBcm for ; Tue, 20 Aug 2019 21:56:33 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB014120071 for ; Tue, 20 Aug 2019 21:56:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,411,1559484000"; d="scan'208";a="322463255" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 21 Aug 2019 14:56:06 +1000 Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcavi.tcif.telstra.com.au with ESMTP; 21 Aug 2019 14:55:58 +1000 Received: from wsapp6785.srv.dir.telstra.com (10.75.3.134) by wsmsg3754.srv.dir.telstra.com (172.49.40.198) with Microsoft SMTP Server (TLS) id 8.3.485.1; Wed, 21 Aug 2019 14:54:56 +1000 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp6785.srv.dir.telstra.com (10.75.3.134) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 21 Aug 2019 14:54:55 +1000 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.101.126) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 21 Aug 2019 14:54:55 +1000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EiJ+G89OTEHqhMkVT8xXzs0gxDgiJVUaKxq0lB8N34sQ4mxvK8c02FCqEAwg6xn1jatwkfmxVGLCjMZhJMqtWEGKUlpXeFd5LLqB9HeFCaXnUFULhO+oBO40vXfeaiWNCd4h2sN3ihrdwhGKFupL25fNNBEq9LHLFmhkhcW+obLpdEbXgeonjdZSW6HV8OKSrGk+jhhWWlJOZqBr3N3Wn7n7KFeQqAK8cXsf48k8ub7X8P4siUUgpI2gCU6jxs7DwUfttp2t1IUG6nfbIgLLTkVFyIehcjh8+xpRlF2ygXTRZhbAR5IL8JfQGVJPCSFS/MCTNfjaI8rGVdg2co9bcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vOaRsFN7dPLOop/8iCTTpm1HlxKIxH611Oko1fkwc44=; b=QceuCA/SgJcVgQT4ZH+UHe9bvhNRfRCHGsziAWQIKi6tyZD/6TaPyS2Ty94V7gRQBuo3ivVtBGfTArqinOeGDIXTu3jBfqrcGfg128roPmsMLLM62D8Wz2uemWP412BlW39tS7NvFxRRvOgULSIgAbTpc1CvfI4l0O4OTy0GjfngTaE9SC9pLN1M3Zkcf0O/FtdT3R6eEF0RRFSreIk/Wt1iqw7YvpNcOjD5CJvuvRtK3Fz+z7yDN7m0KhDfLDsKk6uA79NzpxWL08it571V0FG0zWgcCtDSRKJe6KEzU3s6yHBLBgzYaFCRHkkTQ25YFhdsyntrmpyvF7DMwkyLFw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vOaRsFN7dPLOop/8iCTTpm1HlxKIxH611Oko1fkwc44=; b=aTUpEMCUGRgUWCiu27wfvkv/JFbrFm1BTYRxPz4XjXsO4tScLrF2zGIjizBTB30H0xhOmNiP5606jB+AcTlzKt/IPdn2WxU0r1YFXjlf5A4czCHn0RZK+VEwdpm+dPHl/o+djp/klDoD9vPUDbtvH/4m/prSTvaK/C+SRsYRET8= Received: from SY2PR01MB2764.ausprd01.prod.outlook.com (52.134.190.138) by SY2PR01MB2412.ausprd01.prod.outlook.com (52.134.168.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Wed, 21 Aug 2019 04:54:54 +0000 Received: from SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::a080:9084:3e2f:68ab]) by SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::a080:9084:3e2f:68ab%4]) with mapi id 15.20.2178.018; Wed, 21 Aug 2019 04:54:54 +0000 From: "Manger, James" To: Ulysse Carion CC: JSON WG Thread-Topic: [Json] JSON Schema Language: int53 Thread-Index: AdVX3JGiH0dWYyhaRM2MmxjdYByFeQ== Date: Wed, 21 Aug 2019 04:54:54 +0000 Message-ID: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.41.142.253] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 621182db-20d2-427a-abf7-08d725f3b545 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:SY2PR01MB2412; x-ms-traffictypediagnostic: SY2PR01MB2412: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39860400002)(346002)(136003)(366004)(376002)(13464003)(199004)(189003)(5024004)(14444005)(2906002)(66066001)(186003)(52536014)(8936002)(26005)(316002)(476003)(81166006)(7736002)(305945005)(5660300002)(74316002)(8676002)(81156014)(486006)(102836004)(53546011)(7696005)(6506007)(9686003)(71200400001)(478600001)(71190400001)(4326008)(229853002)(76116006)(6116002)(14454004)(99286004)(55016002)(33656002)(6246003)(6436002)(86362001)(3846002)(6916009)(66446008)(66476007)(64756008)(66946007)(66556008)(256004)(25786009)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:SY2PR01MB2412; H:SY2PR01MB2764.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1v9ophRtUj2Vpe4b06rI+326l/kJ68HAYnKHGPEyT3wGvxagznj5bcDLUFo6//dYcSWiVUvVI5aM7z9ZN00jSSBq02lOwj3aTyl6G7K/lz/LFzEbatV7ZX7ToUkQQSodAbblpWlECD+NOcKZxBfKkYvxkdgtOp83Qukzczbg02iZcdn26DofkETaYkGcuKEbTVxLFVzz+1+NMaz2u8Q96z3kua7Ax18I7ZxcmsauHxveEqXgeEKpVmpvmIm8F40l2vwTowvQbFLolL5V2p5QeoNvvgWTlUVMkv2G1WiyepTvuyUk6CtpgiObVnPmlhM8AjN5m/KfoFMdiRetP0UuC8j+j+NhsEOK1wJfTAATO6nm81/fNcHrr7lK5HCijx6FvvLJZ8g1DFhfp6PCPjZAussQyXqgPLCMyNZuC6EyuyE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 621182db-20d2-427a-abf7-08d725f3b545 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 04:54:54.3328 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7CA/6QcA8B582rPDQZVylwB5KnvtwnSsjdAIPsWnBhL6pAWOhivDBQ3MG9sjS88LRSCwtGjDBrL0jQML6oU/vdjbrapIVeWP+0tTd8ehdhA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY2PR01MB2412 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [Json] JSON Schema Language: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 04:56:36 -0000 U3VyZWx5IGludDUzIGlzIGZpbmUgZm9yIGNvZGUgZ2VuZXJhdGlvbi4gV2hlbiB5b3Ugc2VlIGlu dDUzIGluIGEgc2NoZW1hLCBnZW5lcmF0ZSBhIGZpZWxkIG9mIHR5cGUgbG9uZyAoaW4gSmF2YSku DQpUaGF0IGFsb25lIHdpbGwgbm90IGVuZm9yY2UgYSAyXjUzIGxpbWl0LCBidXQgc28gd2hhdC4N Cg0KV2hlbiBhIHNjaGVtYSBoYXM6DQogICJudW1iZXJPZlNpYmxpbmdzIjogImludDgiDQogICJk YXlPZldlZWsiIDogImludDgiDQpJdCBkb2Vzbid0IG1lYW4gdGhhdCAxMjAgaXMgYSBzZW5zaWJs ZSBudW1iZXIgb2YgYnJvdGhlcnMgJiBzaXN0ZXJzLCBvciAtNTUgY2FuIGJlIGEgZGF5IG9mIHRo ZSB3ZWVrLiBJdCBqdXN0IG1lYW5zIHRoYXQgdGhlIHZhbGlkIHZhbHVlcyBmb3IgdGhlc2UgZmll bGRzIGNhbiBiZSByZXByZXNlbnRlZCB3aXRoIHRoZSByYW5nZSBvZmZlcmVkIGJ5IGludDguIEFw cHMgc3RpbGwgbmVlZCB0byBkbyB0aGVpciBvd24gdmFsaWRhdGlvbiBiZXlvbmQgdGhhdC4NCg0K SWYgeW91IG9taXQgaW50NTMsIHRoZW4geW91ciBjb2RlIGdlbmVyYXRpb24gd2lsbCBuZXZlciBj cmVhdGUgYSBsb25nIGRlc3BpdGUgdGhpcyBiZWluZyBhIHdpZGVseSBhdmFpbGFibGUgJiB1c2Vm dWwgdHlwZS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbToganNvbiA8anNvbi1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgVWx5c3Nl IENhcmlvbg0KU2VudDogV2VkbmVzZGF5LCAyMSBBdWd1c3QgMjAxOSA1OjA2IEFNDQpUbzogUmlj aGFyZCBHaWJzb24gPHJpY2hhcmQuZ2lic29uQGdtYWlsLmNvbT4NCkNjOiBDYXJzdGVuIEJvcm1h bm4gPGNhYm9AdHppLm9yZz47IFBldGUgQ29yZGVsbCA8cGV0ZWpzb25AY29kYWxvZ2ljLmNvbT47 IEpTT04gV0cgPGpzb25AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0pzb25dIEpTT04gU2NoZW1h IExhbmd1YWdlOiBleHRlbnNpYmlsaXR5IGFuZCB1bnNwZWNpZmllZCBwcm9wZXJ0aWVzDQoNCltF eHRlcm5hbCBFbWFpbF0gVGhpcyBlbWFpbCB3YXMgc2VudCBmcm9tIG91dHNpZGUgdGhlIG9yZ2Fu aXNhdGlvbiDigJMgYmUgY2F1dGlvdXMsIHBhcnRpY3VsYXJseSB3aXRoIGxpbmtzIGFuZCBhdHRh Y2htZW50cy4NCg0KPiBJTU8sIHRoZSBzY2hlbWEgc2hvdWxkIGJlIGFib3V0IHJlcHJlc2VudGlu ZyB3aGF0IHRoZSBwcm90b2NvbCBuZWVkcw0KPiByYXRoZXIgdGhhbiBob3cgaXQgaXMgcmVwcmVz ZW50ZWQgb24gYSB0YXJnZXQgbWFjaGluZS4NCg0KVGhpcyBpcyBhIHJlYXNvbmFibGUgc3RhbmNl LiBCdXQgSSBkb24ndCB0aGluayBpdCdzIHdoYXQgSSdtIHRyeWluZyB0bw0Kc29sdmUgZm9yLiBN eSBmb2N1cyBoYXMgY29udGludWFsbHkgYmVlbiBvbiBjb2RlIGdlbmVyYXRpb24gZnJvbQ0Kc2No ZW1hczsgdGhlIHNwZWMncyBleHByZXNzaXZlIHBvd2VyIGlzIGludGVudGlvbmFsbHkgbGltaXRl ZA0Kc3BlY2lmaWNhbGx5IHRvIGVuYWJsZSBjb2RlIGdlbmVyYXRpb24uIE9wdGltaXppbmcgZm9y IGNvZGUgZ2VuZXJhdGlvbg0KaXMgd2h5IEkgKmFtKiBjb25jZXJuaW5nIG15c2VsZiB3aXRoIGhv dyB0aGluZ3MgYXJlIHJlcHJlc2VudGVkIG9uDQp0YXJnZXQgbWFjaGluZXMuDQoNClRoZXJlIGFy ZSBsb3RzIG9mIGdvb2Qgb3B0aW9ucyBmb3Igc2NoZW1hcyBsYW5ndWFnZXMgdGhhdCBhcmUgZm9j dXNlZA0Kb24gYmVpbmcgYXMgZXhwcmVzc2l2ZSBhcyBwcm90b2NvbHMgYXJlIGNvbXBsZXggLS0g eW91J3ZlIHdyaXR0ZW4gb25lDQpvZiB0aGVzZSBnb29kIG9wdGlvbnMsIFBldGUgLS0gYnV0IEkn dmUgYmVlbiBjb25jZXJuZWQgd2l0aCBtYWtpbmcgYQ0Kc2NoZW1hIGxhbmd1YWdlIGFzIGluZXhw cmVzc2l2ZSBhcyBtYWluc3RyZWFtIHR5cGUgc3lzdGVtcyBhcmUgc2ltcGxlLg0KDQpJJ20gbm90 IGRlYmF0aW5nIHdoZXRoZXIgdGhlcmUgYXJlIHdheXMgb2YgcmVwcmVzZW50aW5nIGludDUzIGlu IG1hbnkNCmxhbmd1YWdlcy4gTXkgb2JqZWN0aW9uIGlzIHRoYXQgSSB3b3VsZCBiZSBtYWtpbmcg dXAgYSB0eXBlIHRoYXQNCmRvZXNuJ3QgZXhpc3QgaW4gZXhpc3RpbmcgcHJvZ3JhbW1pbmcgbGFu Z3VhZ2VzIG5hdGl2ZWx5IG9yDQppZGlvbWF0aWNhbGx5LiBJZiBzb21lb25lIHdhbnRzIHRvIGRv IGludDUzIGJvdW5kcyBjaGVja3MsIHRoZXkgY2FuDQphbHdheXMgdXNlIHRoZSBmbG9hdDY0IHR5 cGUsIGFuZCB0aGVuIGRvIGJvdW5kcyBjaGVja2luZyBhZnRlciBzY2hlbWENCnZhbGlkYXRpb24u IE9yIHRoZXkgY2FuIHdyaXRlIGFuIGV4dGVuc2lvbi4NCg0K From nobody Thu Aug 22 14:54: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 747E912012E for ; Thu, 22 Aug 2019 14:54: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR0_3YEYuAzk for ; Thu, 22 Aug 2019 14:54:12 -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 09B211200B1 for ; Thu, 22 Aug 2019 14:54:11 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id p12so15337623iog.5 for ; Thu, 22 Aug 2019 14:54:11 -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=9OHaDoMg1pJnYEKZIieELS5VqkAXsIJKyxm1eYRsRKw=; b=myjiVL2rXaaem3X6BkSwW9mDJ4KYqXNm7E/dCfZe8ZtKW2xkOutsi2HRRhfqwg/O61 1p9s6mYjoTQDrbXwGCS7MpjsrvtwTn5scqnnY9IoYQjWVQt9H9isq7/iV2/6jgwdFz6c YrmSQnIEK9rys/4VfaWoBkBD8ZltZmTnCQAyA= 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=9OHaDoMg1pJnYEKZIieELS5VqkAXsIJKyxm1eYRsRKw=; b=h60/DJIuwalxCoXck8iok+qi66qWbsBzKzl37QFgdl9vaf6GamTkobGJwT31HSHE6A VU2wj98HQtgCZWqtuJyI3PqpWDEE/kHgjKuanFJlavdfmUfa1X4nr/gXuI8g2pRMt8lH ve6xIfypaguptt2w1oeVgiJIPETVpAxwQEn8lUmvzfsyGT7t+NPVt9ibRw9ixXSvbfd/ t6RNyoQB9SR+HC4Pc3tz4UQahD24Z5/xMwTyB0E8MjdOZAHGy6gAmLH0ksNfeJBWlm1+ 1yyHEvGPF73zx3zITNjC5Y6f1ISpAHeJv5Pf8VhBvT4kOOhxyMTn811ZLNmSfCglqRkm m4qg== X-Gm-Message-State: APjAAAV1oKttBeOTGtBKBpocejcl6yb49C82F0XaSe8CpCShoYrEdnrV UeesTRZxkXJlK6jefnGDT1BFm9d8qJCMVsnZ7LbYjw== X-Google-Smtp-Source: APXvYqwKrpsxmOJ3tp13PORP+F/PA2INURHCnCbvqk0KMo+LkxREYn+pxXCarYr3zU0VBhm+iFC2iUGgOZLyjdspMIM= X-Received: by 2002:a5e:a502:: with SMTP id 2mr2496775iog.269.1566510851084; Thu, 22 Aug 2019 14:54:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulysse Carion Date: Thu, 22 Aug 2019 14:54:00 -0700 Message-ID: To: "Manger, James" Cc: JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] JSON Schema Language: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 21:54:15 -0000 > If you omit int53, then your code generation will never create a long des= pite this being a widely available & useful type. The issue, in my view, is that int64/uint64 is the widely-available and useful type. Not int53. To support int53 would require that code generators implement this psuedo-type at runtime. Consider that gRPC, which has a canonical representation in JSON and which also has int64/uint64, unconditionally renders these types as strings. I feel that this approach is more reasonable, as it removes the footgun of a datatype that most users will assume is equivalent to the familiar int64, but is not. On Tue, Aug 20, 2019 at 9:56 PM Manger, James wrote: > > Surely int53 is fine for code generation. When you see int53 in a schema,= generate a field of type long (in Java). > That alone will not enforce a 2^53 limit, but so what. > > When a schema has: > "numberOfSiblings": "int8" > "dayOfWeek" : "int8" > It doesn't mean that 120 is a sensible number of brothers & sisters, or -= 55 can be a day of the week. It just means that the valid values for these = fields can be represented with the range offered by int8. Apps still need t= o do their own validation beyond that. > > If you omit int53, then your code generation will never create a long des= pite this being a widely available & useful type. > > -- > James Manger > > -----Original Message----- > From: json On Behalf Of Ulysse Carion > Sent: Wednesday, 21 August 2019 5:06 AM > To: Richard Gibson > Cc: Carsten Bormann ; Pete Cordell = ; JSON WG > Subject: Re: [Json] JSON Schema Language: extensibility and unspecified p= roperties > > [External Email] This email was sent from outside the organisation =E2=80= =93 be cautious, particularly with links and attachments. > > > IMO, the schema should be about representing what the protocol needs > > rather than how it is represented on a target machine. > > This is a reasonable stance. But I don't think it's what I'm trying to > solve for. My focus has continually been on code generation from > schemas; the spec's expressive power is intentionally limited > specifically to enable code generation. Optimizing for code generation > is why I *am* concerning myself with how things are represented on > target machines. > > There are lots of good options for schemas languages that are focused > on being as expressive as protocols are complex -- you've written one > of these good options, Pete -- but I've been concerned with making a > schema language as inexpressive as mainstream type systems are simple. > > I'm not debating whether there are ways of representing int53 in many > languages. My objection is that I would be making up a type that > doesn't exist in existing programming languages natively or > idiomatically. If someone wants to do int53 bounds checks, they can > always use the float64 type, and then do bounds checking after schema > validation. Or they can write an extension. > From nobody Thu Aug 22 22:02: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 9014012008B for ; Thu, 22 Aug 2019 22:02:52 -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 8__HBEobOSL3 for ; Thu, 22 Aug 2019 22:02:50 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35DA9120045 for ; Thu, 22 Aug 2019 22:02:50 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46F8RC2s4Wzyf5; Fri, 23 Aug 2019 07:02:47 +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, 23 Aug 2019 07:02:46 +0200 Cc: "Manger, James" , JSON WG X-Mao-Original-Outgoing-Id: 588229365.252714-8560e3640600b25dc5b77f6d8fae5c4e Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ulysse Carion X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 05:02:53 -0000 On Aug 22, 2019, at 23:54, Ulysse Carion wrote: >=20 >> If you omit int53, then your code generation will never create a long = despite this being a widely available & useful type. >=20 > The issue, in my view, is that int64/uint64 is the widely-available > and useful type. Not int53. To support int53 would require that code > generators implement this psuedo-type at runtime. I=E2=80=99m not quite sure what =E2=80=9Cimplementing a pseudo-type=E2=80=9D= means, but is that hard? > Consider that gRPC, which has a canonical representation in JSON and > which also has int64/uint64, unconditionally renders these types as > strings. I feel that this approach is more reasonable, as it removes > the footgun of a datatype that most users will assume is equivalent to > the familiar int64, but is not. Now you are in the prescriptive area =E2=80=94 you no longer describe = JSON formats, but you impose your own rules on what these data formats = can be. Not so good.=20 Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 23 01:59: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 252681201EF for ; Fri, 23 Aug 2019 01:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZYy3joSUR4L for ; Fri, 23 Aug 2019 01:59:16 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FDB120125 for ; Fri, 23 Aug 2019 01:59:15 -0700 (PDT) Received: from client-0020.vpn.uni-bremen.de (client-0020.vpn.uni-bremen.de [134.102.107.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46FFh20NWFzyY4; Fri, 23 Aug 2019 10:59: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: Date: Fri, 23 Aug 2019 10:59:13 +0200 Cc: "Manger, James" , JSON WG X-Mao-Original-Outgoing-Id: 588243552.235635-dcda8b61585ac22971b9c8af75fb0bd8 Content-Transfer-Encoding: quoted-printable Message-Id: <50B22512-9D87-49E4-AF82-CDE342DB3E0D@tzi.org> References: To: Ulysse Carion X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSON Schema Language: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 08:59:18 -0000 On Aug 22, 2019, at 23:54, Ulysse Carion wrote: >=20 > int53 Oh, it=E2=80=99s int54, because the separate sign bit gives you one more = bit. (uint53 / nint53) =3D> int54 (I=E2=80=99m ignoring the fact here that nint53 and thus int54 has one = more position at the low end than I-JSON provides unambiguously. But -2**53 =3D=3D MININT54 can be represented in Javascript-limited = JSON, with the only slightly annoying aspect being that you don=E2=80=99t = really know whether it represents -2**53 or -2**53-1.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Aug 24 11:35: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 910F812006E for ; Sat, 24 Aug 2019 11:34:59 -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=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 I0NctLgREVK5 for ; Sat, 24 Aug 2019 11:34:57 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3E0120020 for ; Sat, 24 Aug 2019 11:34:57 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id j4so19464436iog.11 for ; Sat, 24 Aug 2019 11:34:57 -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=4K1S5uX3YWG6hKVjISaY6GhM5RY3AZL9caS8/B5+O+U=; b=E705uqiP6tn5h5Pxy6ULy6I/z223X6wncd7rHpOQRulT7G68xrdwMWOm0LblOSqmKx xKg1BzUq3m3zdIkq21x3Vp+wYz6lhdmBqe6mMBbES0KM7OrSavJiH2e6vPwZh6VAZR7A XGtRW8oLyRuXGQvmPPt9ted+/2IbJl2tGS0w8= 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=4K1S5uX3YWG6hKVjISaY6GhM5RY3AZL9caS8/B5+O+U=; b=bLWoVupnTcbuCRnv4AT4K3FCM9bzO23V7B/SD1CLP7Fz6R+DFpCvg4HEpU5NhajV31 m9NvwBCKnEpBxdhQToODzVkF8Hmp4fT7vJwdd0ki+HwhFlwcvIS++QsLS9YUjHl8eJMV lAEi3cq8m2OgdCZx4j3aRN4at3Vb+p6arfySo3lZDoLSUODJSIQdi/gmJgzf/atUYAi4 7erj61+OJOIOPGCh7cvF8Xb7Of9JmjQWrvzoq8enz7GpLBOvtjzquK4/YbZLFrSD0/e2 Nb4MnkBwLOmUZ7lHCwkLjZAlQ1ztoIY4Nr4A05xKyF9/zVIt6zRzjBiYKHRgBgXB+MGV gPmA== X-Gm-Message-State: APjAAAXeANH+NHxFuUI+L5eiAHc18peNHH48CmFlfwFeXcfFGwiJQlR5 czOweF/XraUJtkDbM1yjtqKOMGow7BmUDENs1YSmrVFBK48= X-Google-Smtp-Source: APXvYqxA5pW8LOtjZm8QXJjPQfvecHKqwc4GZgxdWS7Hz5XpzwGeyyl5JPEUi+02nzF4L11Wi3dbT4hXjZZ7H53z+h4= X-Received: by 2002:a02:a518:: with SMTP id e24mr10623899jam.44.1566671696410; Sat, 24 Aug 2019 11:34:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ulysse Carion Date: Sat, 24 Aug 2019 11:34:45 -0700 Message-ID: To: Carsten Bormann Cc: "Manger, James" , JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Json] JSON Schema Language: int53 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 18:35:00 -0000 > I=E2=80=99m not quite sure what =E2=80=9Cimplementing a pseudo-type=E2=80= =9D means, but is that hard? Not hard. It means creating some sort of type/struct/class that has ToLong/FromLong as methods, and at runtime checks that the values are in range. The problem with this approach (I've tried it, briefly) is that for real-world code that means you end up needing to jump through these ToLong/FromLong hoops in order to get work done. If added, this would be the only such inconvenient hoop to jump through. The fact that there's this hoop to jump through also reduces the strength of James's point -- that without int53, you would never codegen "long" from schemas. In fact, even with int53, you still don't generate "long", you generate a type that's similar but inconveniently different from it. Or, as James suggests, you can generate "long" and not worry about doing bounds checks. But then you lose the property that if you generate some datatype X from a schema S, that all instances of X, when serialized as JSON, satisfy S. > Now you are in the prescriptive area =E2=80=94 you no longer describe JSO= N formats, but you impose your own rules on what these data formats can be.= Not so good. I agree. I mentioned this only to clarify what I felt was a better approach for reconciling our desire for int64_t with the realities of I-JSON. There is no good way to have something that produces int64_t in the spec, in my view (gRPC inherited int64 from Protobuf, and that's why they were forced to be prescriptive). Better to be unopinionated, and have people implement int53 themselves on top of { "type": "float64" }. I'd prefer to miss a feature than to include a wart. I think that a lot of this conversation might be clarified if I just publish an I-D with what I have so far. Expect another thread soon. P.S.: I recognize your point about the type perhaps being better named "int54", Carsten. For the sake of continuity of conversation, I here used the "misnomer". Happy to change what we're calling it, as long as it doesn't confuse anyone. On Thu, Aug 22, 2019 at 10:02 PM Carsten Bormann wrote: > > On Aug 22, 2019, at 23:54, Ulysse Carion wrote: > > > >> If you omit int53, then your code generation will never create a long = despite this being a widely available & useful type. > > > > The issue, in my view, is that int64/uint64 is the widely-available > > and useful type. Not int53. To support int53 would require that code > > generators implement this psuedo-type at runtime. > > I=E2=80=99m not quite sure what =E2=80=9Cimplementing a pseudo-type=E2=80= =9D means, but is that hard? > > > Consider that gRPC, which has a canonical representation in JSON and > > which also has int64/uint64, unconditionally renders these types as > > strings. I feel that this approach is more reasonable, as it removes > > the footgun of a datatype that most users will assume is equivalent to > > the familiar int64, but is not. > > Now you are in the prescriptive area =E2=80=94 you no longer describe JSO= N formats, but you impose your own rules on what these data formats can be.= Not so good. > > Gr=C3=BC=C3=9Fe, Carsten > From nobody Wed Aug 28 12:57:31 2019 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9BC120862 for ; Wed, 28 Aug 2019 12:57:28 -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=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 53zm8855MSL3 for ; Wed, 28 Aug 2019 12:57:26 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 DF6EC120831 for ; Wed, 28 Aug 2019 12:57:25 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id 18so1992832ioe.10 for ; Wed, 28 Aug 2019 12:57:25 -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=4fjaes6es/5GXwztN06uBM6YfrnPUc1ui8J+hOGlDA0=; b=e1eOFKnAbzimp6LU1dcYtDerMxJ23gJAchh4YdNw1z4xk6ZMBQpxxsB0p+TzuafyWn OhDnhx1X/pJzm6zuVBlUxBswKybBhJWjQCSDrkKvZrYsXJW6L8qTiAyzW7Xbbl+4icr6 2UfGkJUFt5egFcDpknTZZAu7p88zlcn/qhmwA= 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=4fjaes6es/5GXwztN06uBM6YfrnPUc1ui8J+hOGlDA0=; b=irG+klawN0RngAXCbOgdAEy+DCCGOfGdYwUxvrYEf5/z4tzxCjQUdzt17uRBQ77z4P NbCJTSpWeOgU87qttLyK0QJhbkoY6JC5hhhPXGfGWbIht5IwpkrC4fY5V/EWX+bwWqbm /stIjrl9PbKWnczVBUB78rYodqpT2R4WgA8CxF1xV96TompV9jIM4Y771ozhv1cPHdUy qqz1q9famKl2Wdjqi/35dLr+4RPxTgStqOy5gIuSih/DtD36H91Y/JsiuE49x6NYB5Ev hLwhysL8IiMxtqpO2wGNTmky6Cmz8nmMQyWpa0FWDJsX+3mFyHNFNBCejNnBNpyqqqMU U1bQ== X-Gm-Message-State: APjAAAWa5rjb2yj+t22seSv9OQLRQ0clfg/VEFt7lBGC3w8k0oie923k 4KcnGHl0VJ70CCxNxgHMvjPA0yDjA0Qq2NrRKgvZ7bB7YkA= X-Google-Smtp-Source: APXvYqyNQxZAfDPP8DPhhm8W3u8jH8EsuZ8o1Ezo99cpTeUkiuui5Aw6vIW/g7S0Y3jS+duzPnPzqy9mLbHkRfSfAZk= X-Received: by 2002:a02:952d:: with SMTP id y42mr6279399jah.66.1567022244913; Wed, 28 Aug 2019 12:57:24 -0700 (PDT) MIME-Version: 1.0 From: Ulysse Carion Date: Wed, 28 Aug 2019 12:57:14 -0700 Message-ID: To: JSON WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Json] JSL: Clarifying purpose, and renaming it to JDDF 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, 28 Aug 2019 19:57:29 -0000 Hi folks, I want to continue to thank y'all for the attention to detail provided in past iterations of JSL. The new I-D is published here: https://tools.ietf.org/html/draft-ucarion-jddf-00 The name of JSON Schema Language has been changed to JSON Data Definition Format ("JDDF"). This is to avoid confusion with "JSON Schema". The JSON Schema folks asked that I changed the name, and I don't mind doing so. Sorry for the confusion. The most important changes are to the introduction. I've clarified what JDDF's niche is (code generation), as well as my position on what seems to be ideal for a schema language optimized for code generation: https://tools.ietf.org/html/draft-ucarion-jddf-00#section-1 I fear we may be at loggerheads on the question of {"type":"int53"}. I continue to prefer for its omission from the spec. James, Carsten -- might we ultimately have to agree to disagree on this question? It seems easier to later on add int53 than to later remove it. Best, Ulysse From nobody Wed Aug 28 22:42: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 A6437120271 for ; Wed, 28 Aug 2019 22:42: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, 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 Yje9Jvlp6YUj for ; Wed, 28 Aug 2019 22:42:19 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 6F241120020 for ; Wed, 28 Aug 2019 22:42:19 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id y135so1203927wmc.1 for ; Wed, 28 Aug 2019 22:42:19 -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=m8WejJiOJKhqbOCjY57r7Q9iN135oV5Xg4k54xgFVvc=; b=lbLp9fhJNQQxh/BnpdGaFO5tX6SHUSj5CzVgFeJ2a75w/gKZBvJHnjd1LIFpSYnlfH hPkz6DA8bz7cSCMURCoccddWqkdFKqGboRntLvnjqCTJsrIoIEBLWp6eHZmQ4CxdCrqi vaWLAuqyraSf92JhC4CPpOEqcYsUVaMaMiDIhz1cej5oqvUfLnyvt0oPa+1Z8hg3VpJH i5IEeRt6jkGmoE1jx2rNcgU/rufhcnmja1hEx9Astg4yvGpwK0ZHXPnw3j9V7MiaOXYx KTTrGURfDlr+rE/gXg6uLMf/OtiMKKPmo1JPO/SbtrzczpnnbJ3LxxpV+P5vRdyK39wN nlaA== 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=m8WejJiOJKhqbOCjY57r7Q9iN135oV5Xg4k54xgFVvc=; b=KHTeq2DMZ38LuAINOlr+VqjcL3jkiNsZnNb+oLW9QF7UqpBv3guU5YW76rZVH8AYTd Hk3AMHOgPWBLCMjP/rRka4+D1BuIcnohjdxP6OGz1QTSL3quHrddL1jWYPv6Pi8SQyH7 rmisiJPIytFvmfum3Lb2C4uXreAH03nNBkEQe5r/65xrtCi9XA94OJ3+rS7C3G1ZNZcs yKnBv1mdDCIHTOAqLfxIlFmeZe76Idr5TEiKuW0bIFMIQdg5uGMR0EpPkRlu4uJG4plx ZSdkoHcfNNlyjAEniZG4Va0mkTMnv5N0xSqLgmXMzkspqEtUfaFz1OiFPUfb5MF2HJKw feuA== X-Gm-Message-State: APjAAAVimo7PogstOz+Takz6sVe4znUqhdr696lPs0shSJp19CQXGeu7 Ye58hf+eRZhFHsQfU9KW9JvZ6q/k X-Google-Smtp-Source: APXvYqy4VSoTIzVNAR/PL2V75goEO+AbS+knACSI4gHgD7rnA//q+j9GuLJSkMl27YBw8B6BFInHQg== X-Received: by 2002:a1c:a546:: with SMTP id o67mr2872838wme.55.1567057336793; Wed, 28 Aug 2019 22:42:16 -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 b144sm3776431wmb.3.2019.08.28.22.42.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Aug 2019 22:42:15 -0700 (PDT) To: Ulysse Carion , JSON WG References: From: Anders Rundgren Message-ID: Date: Thu, 29 Aug 2019 07:42:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] JSL: Clarifying purpose, and renaming it to JDDF 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, 29 Aug 2019 05:42:22 -0000 "The principle of common patterns in JSON is why JDDF does not support 64-bit integers, as these are usually transmitted over JSON in a non- interoperable (i.e., ignoring the recommendations in Section 2.2 of [RFC7493]) or mutually inconsistent (e.g., using hexadecimal versus base64) ways" I understand the motivation but since the world outside of the JSON WG have proved to be fairly capable dealing with these issues, I don't agree with this design principle. IMO this is rather simple problem; make format/representation a separate item, unrelated to the number type itself. That some combinations may be ridiculous or very unlikely to be found in the wild shouldn't be a problem for a properly designed schema processor. There could though be reasonable (whatever that is...) defaults. I may have read the draft in too much haste but I didn't see any support for binary data. Yeah, supporting that would also put JDDF on a more difficult path and my stock of silver bullets is essentially empty :-) Anders On 2019-08-28 21:57, Ulysse Carion wrote: > Hi folks, > > I want to continue to thank y'all for the attention to detail provided > in past iterations of JSL. The new I-D is published here: > > https://tools.ietf.org/html/draft-ucarion-jddf-00 > > The name of JSON Schema Language has been changed to JSON Data > Definition Format ("JDDF"). This is to avoid confusion with "JSON > Schema". The JSON Schema folks asked that I changed the name, and I > don't mind doing so. Sorry for the confusion. > > The most important changes are to the introduction. I've clarified > what JDDF's niche is (code generation), as well as my position on what > seems to be ideal for a schema language optimized for code generation: > > https://tools.ietf.org/html/draft-ucarion-jddf-00#section-1 > > I fear we may be at loggerheads on the question of {"type":"int53"}. I > continue to prefer for its omission from the spec. James, Carsten -- > might we ultimately have to agree to disagree on this question? It > seems easier to later on add int53 than to later remove it. > > Best, > Ulysse > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Thu Aug 29 00:42: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 2297712082A for ; Thu, 29 Aug 2019 00:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAROPkAFpgAq for ; Thu, 29 Aug 2019 00:42:41 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85BD1120822 for ; Thu, 29 Aug 2019 00:42:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,442,1559484000"; d="scan'208";a="212818045" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 29 Aug 2019 17:42:30 +1000 Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcbvi.tcif.telstra.com.au with ESMTP; 29 Aug 2019 17:42:29 +1000 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsmsg3752.srv.dir.telstra.com (172.49.40.173) with Microsoft SMTP Server (TLS) id 8.3.485.1; Thu, 29 Aug 2019 17:41:45 +1000 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 29 Aug 2019 17:41:44 +1000 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.101.125) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 29 Aug 2019 17:41:44 +1000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VsRfHrbDU21ab1wBQYK0hHT+dVWsAFtR0CcAv7TYJA2d8jF9ITDeDbcBlUJx6Fz7boMGlaAr53tlc8/ZgvNaR7ymY+LdL9D2qa4dTbCM8KByHxm0he6k+2jVcU1/XW2wL3jZzd8xQI8ikPxDG6f+ZoK3M3eOzNeSJni3QZHkppb6Gdw6s8uv+iuYof9yL+2H1DII7stCbU8tp9Vo4GhDdipqem2TW/g5f6aPKjuGoAFUJ2a5w03bsitYbCXTQlTX/iIkvDbxmwCZtBkMsePbvRbygiZXc4wkEc3pwEWrVbx+l9AfEgvEQMn/ZFFkUqiUyejh+3jNuVf6IMTXRHOE8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HEXln+whisbLWCmJnf6badrKdWGP+ax2QtV2A7MJjbA=; b=oZUSgMwUE40dG2NfiI7BbIdRlrPKtu++Iqm9kKTG8OnJG35EJSkXgLUW0xk/GUYtVcla4lrfkkKMSPxtgUHfZPmw4L/SDFLaHEu/+TFXEm6iRWOTz2kaGGqlnSihzir/6pVzzNpeEfAWLFaQeNa0P/imyw5j1iIIIL82VjzQsIr9N8zbzRhw1zswRLZ86nfNmSj0tuDr0JklI7Gg/iRRw7+ZTeB5d0mCd3DVrs5T23bo0/6Q9Qt2qLX2pR1UkeSV2kcyjLW4QgljAYo0duzVsJF+qUoGpLcTYYPrdtaysV/f9ukVtHfHrtcFZ5LvkwbA0C3dFWMLYZiBh10+Fougdg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HEXln+whisbLWCmJnf6badrKdWGP+ax2QtV2A7MJjbA=; b=DxNucc16nvyaz9O/MLbgCxCaasw6ITojEDHKFZmPvwx0J0vZSgMsbmC54ABr11Hpbn1eE5e9oQKk1Y2/52vQytZrMI9D3mgtAkJ6a40t74n7UeJN8VQ4epwXgnqhWvSS/8najWNlEJHbKa5LfNIuGxzWO1BqtSXvMClSgQKUrWI= Received: from SY2PR01MB2764.ausprd01.prod.outlook.com (52.134.190.138) by SY2PR01MB3147.ausprd01.prod.outlook.com (52.134.191.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Thu, 29 Aug 2019 07:41:43 +0000 Received: from SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::3d38:e83c:295:b28d]) by SY2PR01MB2764.ausprd01.prod.outlook.com ([fe80::3d38:e83c:295:b28d%4]) with mapi id 15.20.2199.021; Thu, 29 Aug 2019 07:41:43 +0000 From: "Manger, James" To: Ulysse Carion , JSON WG Thread-Topic: [Json] JSL: Clarifying purpose, and renaming it to JDDF Thread-Index: AQHVXdry9oK6lPp0d0O1tpBiqjOWTKcRrocA Date: Thu, 29 Aug 2019 07:41:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.35.185.253] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ce648dd8-7527-41ef-3348-08d72c545660 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SY2PR01MB3147; x-ms-traffictypediagnostic: SY2PR01MB3147: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(396003)(346002)(366004)(376002)(136003)(189003)(199004)(8936002)(966005)(478600001)(229853002)(52536014)(5660300002)(66556008)(66476007)(71200400001)(71190400001)(3846002)(86362001)(6116002)(76116006)(66446008)(66066001)(66946007)(64756008)(8676002)(6506007)(2906002)(25786009)(74316002)(110136005)(26005)(446003)(11346002)(76176011)(186003)(305945005)(7696005)(14454004)(316002)(486006)(55016002)(7736002)(6306002)(6436002)(53936002)(9686003)(102836004)(33656002)(256004)(6246003)(476003)(99286004)(81156014)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:SY2PR01MB3147; H:SY2PR01MB2764.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BDAmjbUd75mwBQdgxr+BYC8XoN6lTxx84ffYzeM24wV+6Bv9CSp9YTSsj56s6XPr2n98hTdIRPd7EZj1SLLmfu7ypkFgzt/UgJmOxLlRDkGclNEHWz5e2CpDnwxLdR1E6tVHPnViZn8Vs9AnsTIJ8t6jbXsE+o6dFvnlh6GjHbW6QId4R9ocqrz/hx0C4XBtmd7hQt136gSbcJlYe8GPiwzd68x3LXKixo1ta3ABcUd/ui1ysdm9t5Q5w5Q/8MgP0fAS6wsobE8MVFNdw2LVC1/UlCRwfYGABri2qt4xD7WUysxsJaR6ropcM3s8aSn0EYRHZZPYYhm/PgFueSNV9Fw9kOIqsF4AQxe2VbBODyL1HZxozPO+j5MXdVZTYiWi7YIxS0GTY+Tu5pyuxhF9WbH9RD+RXhkOnxZ36YgbOk0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ce648dd8-7527-41ef-3348-08d72c545660 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 07:41:43.3265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cLCgJhsfG6ILb0OH6ghaKIxE7/3GjmsjBTL2aZqsadBfJcty6X3oUjvRrK9PeR0dgLWjoynM2OIHkYwVjv2drCYnd8Ph7ceyR8u4l1aMFjg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY2PR01MB3147 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [Json] JSL: Clarifying purpose, and renaming it to JDDF 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, 29 Aug 2019 07:42:50 -0000 PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdWNhcmlvbi1qZGRmLTAwDQo+IC4u Lg0KPiBJIGZlYXIgd2UgbWF5IGJlIGF0IGxvZ2dlcmhlYWRzIG9uIHRoZSBxdWVzdGlvbiBvZiB7 InR5cGUiOiJpbnQ1MyJ9Lg0KDQoNCkpEREYgb2ZmZXJzICJ0eXBlIjoidWludDgiIGJ1dCB2ZXJ5 IGNvbW1vbiBsYW5ndWFnZXMsIHN1Y2ggYXMgSmF2YSwgZG9uJ3QgaGF2ZSBhbiB1bnNpZ25lZCA4 LWJpdCB0eXBlLiBTbyBjb2RlIGdlbmVyYXRpb24gbWlnaHQgdXNlIGEgc2hvcnQgKDE2LWJpdCBz aWduZWQgaW50ZWdlcikgdG8gaGFuZGxlIHRoZSBbMCwgMjU1XSByYW5nZS4gVGhhdCBzZWVtcyB0 byBwdXQgdGhlIGNvZGUgaW4gYSB2ZXJ5IHNpbWlsYXIgc2l0dWF0aW9uIHRvIHVzaW5nIGEgbG9u ZyB3aGVuIHRoZSBKRERGIHNheXMgImludDU0Ii4gSW4gYm90aCBjYXNlcyB0aGUgbmF0aXZlIHR5 cGUgY2FuIGhvbGQgdmFsdWVzIHRoYXQgdGhlIHNjaGVtYSBkb2Vzbid0IGFsbG93LCByZXF1aXJp bmcgZXh0cmEgcGFyc2Uvc3RyaW5naWZ5IGZ1bmN0aW9ucyBpZiB5b3UgcmVhbGx5IHdhbnQgdG8g ZW5mb3JjZSB0aGUgc2NoZW1hJ3MgcnVsZXMuDQoNCj4+IEkgZGlkbid0IHNlZSBhbnkgc3VwcG9y dCBmb3IgYmluYXJ5IGRhdGENCg0KU3VnZ2VzdGVkIGV4dHJhIHR5cGVzOg0KKiAidHlwZSI6ICJp bnRTdHJpbmciIC0tIGFuIGludGVnZXIgZXhjaGFuZ2VkIGluIGRlY2ltYWwgbm90YXRpb24gYXMg YSBKU09OIHN0cmluZywgd2l0aCBubyBkZWNpbWFsIHBvaW50IG9yIGV4cG9uZW50LiAobWF5YmUg b25seSBvZmZlciAiaW50NjRTdHJpbmciIGluc3RlYWQsIGlmIGl0IGlzIG9ubHkgNjQtYml0IHZh bHVlcyB0aGF0IHR5cGljYWxseSB1c2UgdGhpcyBmb3JtYXQpDQoqICJ0eXBlIjogInVpbnRCNjR1 IiAtLSBhIChub24tbmVnYXRpdmUpIGludGVnZXIgKHBvdGVudGlhbGx5IGh1Z2UsIGFzIG9mdGVu IHVzZWQgaW4gY3J5cHRvZ3JhcGh5KSBleGNoYW5nZWQgYXMgYSBKU09OIHN0cmluZyBob2xkaW5n IHRoZSBiYXNlNjR1cmwtZW5jb2RpbmcgKHdpdGhvdXQgcGFkZGluZykgb2YgYW4gdW5zaWduZWQg YmlnLWVuZGlhbiByZXByZXNlbnRhdGlvbiBvZiB0aGUgaW50ZWdlci4gKG1heSBuZWVkIGEgY29t bWVudCBhYm91dCBncmFjZWZ1bGx5IGFjY2VwdGluZyBsZWFkaW5nIDAgYnl0ZXMpLg0KKiAidHlw ZSI6ICJieXRlc0I2NCIgLS0gYSBieXRlIGFycmF5IGV4Y2hhbmdlZCBhcyBhIEpTT04gc3RyaW5n IGhvbGRpbmcgaXRzIGJhc2U2NC1lbmNvZGluZw0KKiAidHlwZSI6ICJieXRlc0I2NHUiIC0tIGEg Ynl0ZSBhcnJheSBleGNoYW5nZWQgYXMgYSBKU09OIHN0cmluZyBob2xkaW5nIGl0cyBiYXNlNjR1 cmwtZW5jb2RpbmcgKHdpdGhvdXQgcGFkZGluZykNCg0KLS0NCkphbWVzIE1hbmdlcg0K From nobody Thu Aug 29 01:33: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 42852120124 for ; Thu, 29 Aug 2019 01:33:32 -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 K4JxLR0ypq0r for ; Thu, 29 Aug 2019 01:33:31 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056721200CC for ; Thu, 29 Aug 2019 01:33:31 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46JwqY3pGSzyY5; Thu, 29 Aug 2019 10:33:29 +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, 29 Aug 2019 10:33:28 +0200 Cc: Ulysse Carion , JSON WG X-Mao-Original-Outgoing-Id: 588760406.3132989-e5f6382d006c1476d9907f7058923e5e Content-Transfer-Encoding: quoted-printable Message-Id: <4644E5BE-096F-44BA-84DF-1EE74761ED9D@tzi.org> References: To: "Manger, James" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSL: Clarifying purpose, and renaming it to JDDF 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, 29 Aug 2019 08:33:32 -0000 > Suggested extra types: > * "type": "intString" -- an integer exchanged in decimal notation as a = JSON string, with no decimal point or exponent. (maybe only offer = "int64String" instead, if it is only 64-bit values that typically use = this format) > * "type": "uintB64u" -- a (non-negative) integer (potentially huge, as = often used in cryptography) exchanged as a JSON string holding the = base64url-encoding (without padding) of an unsigned big-endian = representation of the integer. (may need a comment about gracefully = accepting leading 0 bytes). > * "type": "bytesB64" -- a byte array exchanged as a JSON string = holding its base64-encoding > * =E2=80=9Ctype": "bytesB64u" -- a byte array exchanged as a JSON = string holding its base64url-encoding (without padding) The list sounds good (I=E2=80=99m assuming byesB64 is base64 classic = (Section 4 of RFC 4648) with padding); the names are a bit unwieldy =E2=80= =94 and give away the following observation: This mixes application type (int, uint, bytes) with representation = (there already is another representation in use for int and uint, and = this adds two alternative representations for bytes). Of course it is = OK to mix the two (generate the product of possibilities), but it also = can help to separate the two (and add a range constraint as a third, = while uint8 does this so succinctly?). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 29 01:44: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 EB927120103 for ; Thu, 29 Aug 2019 01:44:02 -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 X4M4viOPPd71 for ; Thu, 29 Aug 2019 01:44:01 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EDE01200D8 for ; Thu, 29 Aug 2019 01:44:01 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46Jx3g4w6KzyXf; Thu, 29 Aug 2019 10:43: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: <4644E5BE-096F-44BA-84DF-1EE74761ED9D@tzi.org> Date: Thu, 29 Aug 2019 10:43:58 +0200 Cc: JSON WG , Ulysse Carion X-Mao-Original-Outgoing-Id: 588761034.7030621-e6a7bca2a615aea122fae8488cacc927 Content-Transfer-Encoding: quoted-printable Message-Id: <43B2E14E-5FF2-4E29-9EB9-DCA805C89B67@tzi.org> References: <4644E5BE-096F-44BA-84DF-1EE74761ED9D@tzi.org> To: "Manger, James" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Json] JSL: Clarifying purpose, and renaming it to JDDF 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, 29 Aug 2019 08:44:03 -0000 On Aug 29, 2019, at 10:33, Carsten Bormann wrote: >=20 > representation =E2=80=A6 and adding something closer to a proposal to my observation: intString is an int[unlimited? 64?] in decimal. (Note that the below are all strings on the JSON side, too; nothing is = special requiring calling out the use of Strings, but it should be said = that they are decimal(*)). uintB64u is an uint_unlimited in (msb-first bytes and then) b64u = (Section 5/no padding). bytesB64 is a byte string in b64c (Section 4/padding). bytesB64u is a byte string in b64u. Note that there is no =E2=80=9Cdefault=E2=80=9D representation of byte = string in JSON, so this always needs a representation (possibly the JDDF = defines a default, which would be b64u). Gr=C3=BC=C3=9Fe, Carsten (*) should have a position on leading zeros=E2=80=A6 From nobody Thu Aug 29 05:38: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 AC616120121 for ; Thu, 29 Aug 2019 05:38:33 -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 Jh7nKGTB67cZ for ; Thu, 29 Aug 2019 05:38:31 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 38FC31200D5 for ; Thu, 29 Aug 2019 05:38:31 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id y8so3228043wrn.10 for ; Thu, 29 Aug 2019 05:38:31 -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=rDJCAYV+x0bM1X6OdXDDMG/waDvJDxUiDF587JKjOqo=; b=nWhqCBwibIJ7uxEYnbc2KL/P/1nSvLbEAdYKKUQume7hn8eYaVtYb9d4ftq4jnJsCK Yp6A17hCIGU1VtpTX7KdPBU6Z0mCtLsc8Bsd+K/MOi9urwXPmdhmfEUvi/KXZwaHB2iv VVJKPMTA61YVv9F2tDPC+RVq6ifQKZBYvw0TfFFCQgolXTEOdE06StujgZMkw7++2nAl YZ0QXgg/axBFdbh/V8OFrbUo9hahmw69wSDv6IhAp4MrJHuP2tl8wXf0mGNfdRFS5q0V uieuD2/jHmECgWa4a2pGDWUvpwnccrtygtu1QYS9lQW7swqBMtsP74C2JRvYdjpBwoEB ek5A== 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=rDJCAYV+x0bM1X6OdXDDMG/waDvJDxUiDF587JKjOqo=; b=QTSQR3CfSQO/Vb6V3zG3znbf+plFAmiQlO8a/CC3BJFr5yUowY9SA8s2aR42mA0/cT +2XEk1RFZwDi+ItvQx7mooRz8N8ka8M6aYWHZbcAH+nf92uF8kD+NoaxSir0XYuljHxl ocCpSSTPIarFk7ERl9dv/0NrsALEYN3U+cThr8MPIAduXDI0UoEaYeWK6K/nW5ikRCi5 eC/SaGlkkEEbt7/X4rZMOzCOpStgUKqoB/8Rkpt+adx+nMb3mRCbEuYXTcBEVbvQKwGp Rfqd7j6QIXYXCzMsRuNPokHq3RsdIlVgC6VcPvunZMaEopYjeXbaqw9jr+jAwe/mEpqU BFGw== X-Gm-Message-State: APjAAAVv3WczER/yTEL4XiUi8rIaTOAzv0sOC0/T4TyznvtkGRn9H++C WHNuCXTbu2Ir+GAsQfhLTpH8SsvWw+Bc11pXnwh2eDuK X-Google-Smtp-Source: APXvYqyXfOpBPR9/icIc42oAITaam91SbEvxKVOpcGEwmf9INXm3U+isVfrAZl+LSVDmqtS4UnBmtjtxbShb7BeWtrU= X-Received: by 2002:adf:ea03:: with SMTP id q3mr10961497wrm.219.1567082309629; Thu, 29 Aug 2019 05:38:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Cowan Date: Thu, 29 Aug 2019 08:38:15 -0400 Message-ID: To: Ulysse Carion Cc: JSON WG Content-Type: multipart/alternative; boundary="00000000000066501b059140c8cb" Archived-At: Subject: Re: [Json] JSL: Clarifying purpose, and renaming it to JDDF 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, 29 Aug 2019 12:38:45 -0000 --00000000000066501b059140c8cb Content-Type: text/plain; charset="UTF-8" Proposed schema types for JDDF purposes: Fixed-length strings and bounded strings: both useful in contexts where dynamic memory allocation is not allowed for performance, security, or low-memory reasons. Fixed-length and bounded arrays: same reasoning. Tuples: These are fixed-length JSON arrays where each element potentially has its own type. They can be translated into languages that don't have them natively (as Python does) using a struct/class with synthetic field names like element0, element1, ... or just _0, _1, .... On Wed, Aug 28, 2019 at 3:57 PM Ulysse Carion wrote: > Hi folks, > > I want to continue to thank y'all for the attention to detail provided > in past iterations of JSL. The new I-D is published here: > > https://tools.ietf.org/html/draft-ucarion-jddf-00 > > The name of JSON Schema Language has been changed to JSON Data > Definition Format ("JDDF"). This is to avoid confusion with "JSON > Schema". The JSON Schema folks asked that I changed the name, and I > don't mind doing so. Sorry for the confusion. > > The most important changes are to the introduction. I've clarified > what JDDF's niche is (code generation), as well as my position on what > seems to be ideal for a schema language optimized for code generation: > > https://tools.ietf.org/html/draft-ucarion-jddf-00#section-1 > > I fear we may be at loggerheads on the question of {"type":"int53"}. I > continue to prefer for its omission from the spec. James, Carsten -- > might we ultimately have to agree to disagree on this question? It > seems easier to later on add int53 than to later remove it. > > Best, > Ulysse > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --00000000000066501b059140c8cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Proposed schema types for JDDF purposes:

Fixed-length strings and bounded strings: both useful in contexts where d= ynamic memory allocation is not allowed for performance, security, or low-m= emory reasons.

Fixed-length and bounded arrays: sa= me reasoning.

Tuples:=C2=A0 These are fixed-length= JSON arrays where each element potentially has its own type.=C2=A0 They ca= n be translated into languages that don't have them natively (as Python= does) using a struct/class with synthetic field names like element0, eleme= nt1, ... or just _0, _1, ....


On Wed, Aug 28, 2019 at 3= :57 PM Ulysse Carion <ulysse@segment.com> wrote:
Hi folks,

I want to continue to thank y'all for the attention to detail provided<= br> in past iterations of JSL. The new I-D is published here:

https://tools.ietf.org/html/draft-ucarion-jddf-00

The name of JSON Schema Language has been changed to JSON Data
Definition Format ("JDDF"). This is to avoid confusion with "= ;JSON
Schema". The JSON Schema folks asked that I changed the name, and I don't mind doing so. Sorry for the confusion.

The most important changes are to the introduction. I've clarified
what JDDF's niche is (code generation), as well as my position on what<= br> seems to be ideal for a schema language optimized for code generation:

https://tools.ietf.org/html/draft-ucarion= -jddf-00#section-1

I fear we may be at loggerheads on the question of {"type":"= int53"}. I
continue to prefer for its omission from the spec. James, Carsten --
might we ultimately have to agree to disagree on this question? It
seems easier to later on add int53 than to later remove it.

Best,
Ulysse

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--00000000000066501b059140c8cb-- From nobody Sat Aug 31 08:39: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 B2A321200D7 for ; Sat, 31 Aug 2019 08:39: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_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 qVWa6yQp7EbK for ; Sat, 31 Aug 2019 08:39:25 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 81DCB1200CD for ; Sat, 31 Aug 2019 08:39:25 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id j16so9773181wrr.8 for ; Sat, 31 Aug 2019 08:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=gRwemPHarf01BNTXr0IqH9oq4I5PHIxHvN6g4KsVav0=; b=ZJN6NSR10mGgi0tUCdXNYhYiUYqNXcCk6ZmjicUrM6dLrS/LnguE+OnLxtDMaT6/Dg ZMMrxixoMKwLQV2niRgoPcRaSboc1GxQ/WIGQVDsiJxMinxbt/RId23UHimsHLZfMXof VZ5nw3ArorWejBj7J7ZTRkiapx4PhpIdePUasAaL8/fGEQIY+BFA7th5CRLJg2YX+VTZ hhlvv1mTJ93ScVJcMIkRE0Ob+UyRoah7pKNgv4MB/xAOFxKJyWhTwb6L3Hx6xHJ/zpcY Jhymxbm90YxlpcAlTynAH0u6eMaroriVDLfvEzbHNEk7O9MlHEbkUOCiixL6kRacDfhj HoBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=gRwemPHarf01BNTXr0IqH9oq4I5PHIxHvN6g4KsVav0=; b=c25nddq+0Mj+5QnoH/YsgVY3swiaGhSattq8g/UlNFI2093b2+NrAHsvDgHUyRj+ne OQl5VyNzUpybeL0n/qMJqGFJB0AnTc/EWXylqHA8ms79iD0zCbzEFFOtzOAiCS2bFjWb 2O8TNUhPNK/qCo/gXibQP0M4zRAB2yzIroronaqutUKoYltJy1yJzsEVOZnF8u8gvNUU 9T2kO+ao/W2AEwue1OD3p8RjscRFdLlKeXGzd1Zs0IDp1FGztuFkrcEVxLnnE1t93Zxu KbMzD0O+6JrMcqvaX3CHO3lvpFwNJg2tkPyQ9xJmpQgPL2Yg2BiWB7LLIw5rrzcFYkDm EMLA== X-Gm-Message-State: APjAAAXzGTaj0Ck5sHTnh+6BWOEy9fmFf3d0K0VyPybbFBd7oCr+4ekk rdXN/SSaaHfgTUpbMtvgY1722bHn X-Google-Smtp-Source: APXvYqzlv0S5GgIfrwObmxjR0GVLiu1G1u+r1dJ07K6VWDsovpHpEi8/Kda+rmGuSUsj/JZDld9Z8A== X-Received: by 2002:a5d:4b41:: with SMTP id w1mr23727953wrs.23.1567265963654; Sat, 31 Aug 2019 08:39: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 n14sm29495024wra.75.2019.08.31.08.39.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Aug 2019 08:39:22 -0700 (PDT) From: Anders Rundgren To: "json@ietf.org" Message-ID: Date: Sat, 31 Aug 2019 17:39:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 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] In "praise" of UTF-16 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, 31 Aug 2019 15:39:28 -0000 Hi JSON experts, Pardon the subject line, I'm by no means an UTF-16 aficionado. That UTF-16 has been deprecated by the industry at large for EXTERNAL representation of textual data is completely understandable. However, an I-D dealing with canonical JSON serialization is currently in the IETF ISE queue got criticism for using UTF-16 encoding INTERNALLY for sorting properties/keys. I don't see why since the only purpose of the sorting is creating a defined order.   That sorting on UTF-8 or UTF-32 would give another result is true but for the stated purpose that is of no importance. In addition, JSON itself also depends on UTF-16 encoding for \uhhhh constants and AFAIK nobody have complained about that. Example: A smiley Emoji has the Unicode value U+1F600 but would in a JSON escape sequence be represented as \ud83d\ude00 The reason for preferring UTF-16 in this particular case is simply because JavaScript, Windows and Java use UTF-16 as internal representation.  That's obviously a slight platform bias but the my Go and Python implementations show that the UTF-16 requirement in practice is a no-issue. According to the Unicode standard UTF-16 belongs to the set of supported fully interchangeable encodings. WDYT? thanx, Anders https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-06 From nobody Sat Aug 31 10:58: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 3DCF71200E5 for ; Sat, 31 Aug 2019 10:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=FbW+AXEq; dkim=pass (1536-bit key) header.d=taugh.com header.b=NegEvrnp 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 bQ5z2P-OkwSN for ; Sat, 31 Aug 2019 10:58:31 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 BB9D41200F1 for ; Sat, 31 Aug 2019 10:58:30 -0700 (PDT) Received: (qmail 2696 invoked from network); 31 Aug 2019 17:58:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a86.5d6ab544.k1908; i=printer-iecc.com@submit.iecc.com; bh=fIjZ3fjD/8JJEJCVc8636HJ2SUh7qQRX5g5k9s/ZCHo=; b=FbW+AXEqE9MJ0u87w7LbxNVHBkRMcqfDfNrevz5aLaZ0foKQIrAQLdJYSoW90jcHWX4TR19LD8e2+BmJf2N0FaWDLLztCu6qDBlxsxfQ3xzLj3ihfdSgWMHmRZyxH/oh2/utpGACJR8Yf/qxiwEFWjEOYaDYlOfehhXqRn7YscJuoXa211b+ci/k1jx8uVeUJgrmgcF5OsnSL8sB7X+QwG9VeahHaSivn+RN/YfDF0YjgUIMal+R0UJ/HVW505es DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a86.5d6ab544.k1908; olt=printer-iecc.com@submit.iecc.com; bh=fIjZ3fjD/8JJEJCVc8636HJ2SUh7qQRX5g5k9s/ZCHo=; b=NegEvrnpbcK98f6Vc9IVizgd8OG1eKLLr1HBAd7KGxVvsoIxV/Tq6ezwu7ZtJvLkaQdy7eyp9val6JLGUkyG0r1jY3QvKg02HW/ifojA9xRMr1Bv/mAoc/O8kBNlWIMFbQNak6Qjed1fTEZ4r5S2V+WWsl+o6mP+ioufPsaoIUb93WMmIMdLzwwd1gz3A4smaBZ4FdRz8ye/Q21dP7N1mJ20k0T7DD3DSDlXATgqsQW21SDILpCnGbE4e3D364KN Received: from ary.qy ([64.246.232.221]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP; 31 Aug 2019 17:58:28 -0000 Received: by ary.qy (Postfix, from userid 501) id 63FCF91C671; Sat, 31 Aug 2019 13:58:28 -0400 (EDT) Date: 31 Aug 2019 13:58:28 -0400 Message-Id: <20190831175828.63FCF91C671@ary.qy> From: "John Levine" To: json@ietf.org Cc: anders.rundgren.net@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Json] In "praise" of UTF-16 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, 31 Aug 2019 17:58:32 -0000 In article you write: >The reason for preferring UTF-16 in this particular case is simply because JavaScript, Windows and Java use UTF-16 as >internal representation.  That's obviously a slight platform bias but the my Go and Python implementations show that the >UTF-16 requirement in practice is a no-issue. I wish UTF-16 had never been invented, but since it was, and Javascript and JSON have a lot of historical connection to UTF-16, using it as the canonical sort order is OK. From nobody Sat Aug 31 11:21: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 B806B1200F9 for ; Sat, 31 Aug 2019 11:21:22 -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 yP7ReFx7D3Ia for ; Sat, 31 Aug 2019 11:21:20 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 D3A221200F1 for ; Sat, 31 Aug 2019 11:21:20 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id s21so20933545ioa.1 for ; Sat, 31 Aug 2019 11:21:20 -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=/Q2MpgUXLvCc8UKf2YIe9ucGlGsTeogjN+AyAw4ZxLY=; b=1OfEHamHNPltNCmY7VuczLwhxpUIIfNro6YOMAWYUpmWcjWERdVOs8ag7/FAKcNRpy AyMKQ7GVbgPdbKEHb0dY0MtCL0i6axX+JZpX8QWXQ86YdlXzE4IzLEuJ9SarKmhlH5S3 jF/DriTuCM/sxVB0/bTDq/0U3SBSip7W06CoaYuThKaJprrfWKKEiNI5l6GRhiS7BTY6 jYfJVVae50sPvh0QU+1aoGMcVx7Clkxm6EiBrj8UgLKvB8iRcEks41qdOXC5XljXoVmH 6fp8GlVmTyCS/a2j/l3UyxjLYRbS7EUQuAzr4ujLzAUfvtMSV6wjbbdC6i8paS2ziplI m8pw== 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=/Q2MpgUXLvCc8UKf2YIe9ucGlGsTeogjN+AyAw4ZxLY=; b=Fd+9Pq1d8aRVErIbyo99W6TT8QSKaXM6pT3afzNQ2ROBILskeyfELgT1njn5geFiae e+Xm84cxdfp5uwKBjQJU/SbnK3sx/zZc6V9FNs6v5E5J98moMks8FVmG47XJ0k3B/Erm fi+5ERZ7Bq3znd/LD1ZT16rwUitJ1rOFPLcWk9Tfs0QIL+loiL8Zw89Fa5Un/qy/MdlM o28A5COckqLzHVDx4hzOA3gus7P9epGnXxKyOi2Vlik95AwY8earZZPdC8b3TcAeDg+h vxDklJa61R74TY9DiRafoEEL5evAAYSAotJ8qD4LjE7CxtfyFARVXoLiRvVs5DB6d+FE 4XJg== X-Gm-Message-State: APjAAAXoN9bRdXIYbZMF4joFTrVVYH77ljEfrn8F5Mdftj1UKTf58o1K soRNP4L1VmYEaPdRNqscMXfre9k3mS6wDs04/fZ75g== X-Google-Smtp-Source: APXvYqxcrsy3rzvhFvlqQHE0l7Y75yD/Kuh/k5d/cXHvBXu3dgijIaV9aRcYy/9UMsj7rtu8nNPhcDsNXmhDift7/gc= X-Received: by 2002:a5d:940c:: with SMTP id v12mr13927273ion.233.1567275680100; Sat, 31 Aug 2019 11:21:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Sat, 31 Aug 2019 11:21:09 -0700 Message-ID: To: Anders Rundgren Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002d8b0d05916dce80" Archived-At: Subject: Re: [Json] In "praise" of UTF-16 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, 31 Aug 2019 18:21:23 -0000 --0000000000002d8b0d05916dce80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's incorrect to say that nobody complains about UTF-16, I do so all the time. But it doesn=E2=80=99t do any good. I don't see any problem with using UTF-16 this way. On Sat, Aug 31, 2019 at 8:39 AM Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > Hi JSON experts, > Pardon the subject line, I'm by no means an UTF-16 aficionado. > > That UTF-16 has been deprecated by the industry at large for EXTERNAL > representation of textual data is completely understandable. > > However, an I-D dealing with canonical JSON serialization is currently in > the IETF ISE queue got criticism for using UTF-16 encoding INTERNALLY for > sorting properties/keys. > I don't see why since the only purpose of the sorting is creating a > defined order. That sorting on UTF-8 or UTF-32 would give another resul= t > is true but for the stated purpose that is of no importance. > > In addition, JSON itself also depends on UTF-16 encoding for \uhhhh > constants and AFAIK nobody have complained about that. > Example: A smiley Emoji has the Unicode value U+1F600 but would in a JSON > escape sequence be represented as \ud83d\ude00 > > The reason for preferring UTF-16 in this particular case is simply becaus= e > JavaScript, Windows and Java use UTF-16 as internal representation. That= 's > obviously a slight platform bias but the my Go and Python implementations > show that the UTF-16 requirement in practice is a no-issue. > > According to the Unicode standard UTF-16 belongs to the set of supported > fully interchangeable encodings. > > WDYT? > > thanx, > Anders > https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-0= 6 > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --0000000000002d8b0d05916dce80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's incorrect to say that nobody complains about UTF-16,= I do so all the time. But it doesn=E2=80=99t do any good.

I don't see any problem with using U= TF-16 this way.

On Sat, Aug 31, 2019 at 8:39 AM Anders Rundgren &l= t;anders.rundgren.net@gmai= l.com> wrote:
Hi JSON experts,
Pardon the subject line, I'm by no means an UTF-16 aficionado.

That UTF-16 has been deprecated by the industry at large for EXTERNAL repre= sentation of textual data is completely understandable.

However, an I-D dealing with canonical JSON serialization is currently in t= he IETF ISE queue got criticism for using UTF-16 encoding INTERNALLY for so= rting properties/keys.
I don't see why since the only purpose of the sorting is creating a def= ined order.=C2=A0=C2=A0 That sorting on UTF-8 or UTF-32 would give another = result is true but for the stated purpose that is of no importance.

In addition, JSON itself also depends on UTF-16 encoding for \uhhhh constan= ts and AFAIK nobody have complained about that.
Example: A smiley Emoji has the Unicode value U+1F600 but would in a JSON e= scape sequence be represented as \ud83d\ude00

The reason for preferring UTF-16 in this particular case is simply because = JavaScript, Windows and Java use UTF-16 as internal representation.=C2=A0 T= hat's obviously a slight platform bias but the my Go and Python impleme= ntations show that the UTF-16 requirement in practice is a no-issue.

According to the Unicode standard UTF-16 belongs to the set of supported fu= lly interchangeable encodings.

WDYT?

thanx,
Anders
https://tools.ietf.org/htm= l/draft-rundgren-json-canonicalization-scheme-06

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--0000000000002d8b0d05916dce80--