Re: [Json] JSON Schema Language: int53

Carsten Bormann <cabo@tzi.org> Fri, 23 August 2019 05:02 UTC

Return-Path: <cabo@tzi.org>
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 <json@ietfa.amsl.com>; 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 <json@ietfa.amsl.com>; 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 <json@ietf.org>; 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 <cabo@tzi.org>
In-Reply-To: <CAJK=1RiDf6SpWEad4w05ihHCAXviprzS_EXTv+aGmCWpkkoRGg@mail.gmail.com>
Date: Fri, 23 Aug 2019 07:02:46 +0200
Cc: "Manger, James" <James.H.Manger@team.telstra.com>, JSON WG <json@ietf.org>
X-Mao-Original-Outgoing-Id: 588229365.252714-8560e3640600b25dc5b77f6d8fae5c4e
Content-Transfer-Encoding: quoted-printable
Message-Id: <E1702435-9D6F-484F-B291-F5CFCDC343B1@tzi.org>
References: <SY2PR01MB2764698C2B0DE6811B9FDAFBE5AA0@SY2PR01MB2764.ausprd01.prod.outlook.com> <CAJK=1RiDf6SpWEad4w05ihHCAXviprzS_EXTv+aGmCWpkkoRGg@mail.gmail.com>
To: Ulysse Carion <ulysse@segment.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/z6o3NVmyOmBYRoPaA1M6yknLeqQ>
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" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2019 05:02:53 -0000

On Aug 22, 2019, at 23:54, Ulysse Carion <ulysse@segment.com> 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’m not quite sure what “implementing a pseudo-type” 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 — you no longer describe JSON formats, but you impose your own rules on what these data formats can be.  Not so good. 

Grüße, Carsten