Re: [Json] JSON Schema Language is nearly done: int53

Ulysse Carion <ulysse@segment.com> Thu, 01 August 2019 03:55 UTC

Return-Path: <ulysse@segment.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF3B12013B for <json@ietfa.amsl.com>; Wed, 31 Jul 2019 20:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=segment.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFz_IuyCmVMh for <json@ietfa.amsl.com>; Wed, 31 Jul 2019 20:55:38 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75BB120136 for <json@ietf.org>; Wed, 31 Jul 2019 20:55:38 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id q22so21456261iog.4 for <json@ietf.org>; Wed, 31 Jul 2019 20:55:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=segment.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q4p8yTGHfiXikjl7w+qq6gihCxoUI1zqCay5cK8rxI4=; b=r6JUuSI1YPL+uVJz3orjp9lNmz3d06lBIoqTQad5MJgXsChVWxrlFVL71hSQIrwyiS uMXNxbbxOQIJ45d9cf55nyEy2dyWaTNh2LooRObF9BIgkyBP5wrplvNezH16tA60sasU 0vuOEiXocJZZvekAZMxCF3PUjcFJeNk4h/7PU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q4p8yTGHfiXikjl7w+qq6gihCxoUI1zqCay5cK8rxI4=; b=a1H31d1N9rJKBJnsx5rnWRypOAy+OELHg0GrQKQh9iL49/EClVvARaF77zHUJppGAq qwFkB+TZTLNDQsWyIbomNzx6w6r4E2mRIrPpRZQ36HSXMyEFco1E23i9QmqwvKXZjxDd j9BGY11Tcbya+UjFbnNXjvqWPqZsb+GsbtPNeOjeiGnrlfZSazbS7daWu2kxODF1Bv7W 7OlecCz3WmsExyGqIvBUKD2ZfWIW/2lcvy//xJIDH6iEY/p6dTs3ph2y8tUh0smMd1fd 0QmLQFUNApPg8BvVckQe1iP2f5WDrBNsIuR+NCrzEXvazf2LjOZ4IOVoizHr6WDF1A7F /qjQ==
X-Gm-Message-State: APjAAAWcUfytCwjsRsjRNVu9xZ1Hihwn42+pPvX0zOe9+zS86fqnrIsi reexWAcBijHg2O9orNLHv/QY89Bimx+RdQVM98CRIQ==
X-Google-Smtp-Source: APXvYqyB8L6XFtGbs3t51wXlKauqMBZjDLvatrgPaiJb2YKBaOTC96nnR6hQkCA4+FLn+Rhf4Lar0eNWAeJtwG9v4kg=
X-Received: by 2002:a02:bb08:: with SMTP id y8mr84851029jan.51.1564631737464; Wed, 31 Jul 2019 20:55:37 -0700 (PDT)
MIME-Version: 1.0
References: <SY2PR01MB27642C6983E387C397B11581E5DD0@SY2PR01MB2764.ausprd01.prod.outlook.com> <CAJK=1RjhuCYJe4-BSB++8+-dHG3LV8TdqsnFEPAoAkfJ1mOE3A@mail.gmail.com> <SY2PR01MB2764AD4523625006B1F3DFEBE5DC0@SY2PR01MB2764.ausprd01.prod.outlook.com> <aeb4dfcc-4227-2d8e-d1dc-914d078450fe@gmail.com> <SY2PR01MB2764600E16BA7A19025964EFE5DF0@SY2PR01MB2764.ausprd01.prod.outlook.com> <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com>
In-Reply-To: <7f663d84-eb38-271f-12c3-a0f4a2261090@gmail.com>
From: Ulysse Carion <ulysse@segment.com>
Date: Wed, 31 Jul 2019 20:55:26 -0700
Message-ID: <CAJK=1RjqqtZvdWBJNXR6ebKFT1KSkNJHQjiydQ7RJX6aPyB+9g@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: "Manger, James" <James.H.Manger@team.telstra.com>, JSON WG <json@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eaa078058f063679"
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/QqxZtxbZ_xiHLPj7p7_HCww9CCo>
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" <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: Thu, 01 Aug 2019 03:55:42 -0000

Replying to Anders and James at once:

> The purpose of fixed sized integers in data formats is not to save bytes,
it is about valid ranges and compatibility with languages like Java and C++.

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

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

This is my view as well.

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

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

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

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

This has been discussed in this thread before. Rough consensus suggests
that it's better to simply require a zero fractional part in the number
value, rather than impose constraints at the JSON parser level.

On Wed, Jul 31, 2019 at 12:14 AM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2019-07-31 08:56, Manger, James wrote:
> >> Dropping int64 is hardly an option, neither is BigInteger.   int53 is a
> special that for example fits UNIX "epoch".
> >
> > Dropping int64 or BigInteger from *programming languages* is not an
> option. But dropping the ability for a JSON schema to suggest that
> arbitrary values of those types should be serialized to JSON numbers would
> be sensible.
> >
> >> Arbitrarily sized integers are used by tons of applications based on
> JSON messaging and is available for most platforms including JS.
> >
> > Sure, but they are not serialized to a JSON number. They are serialized
> to a JSON string of some form (eg "65537.00" or "AQAB").
>
> This is where we (as a community of users) have a problem.  Jackson (now
> adopted by MSFT) indeed serializes BigInteger as JSON Number.  Other
> parties like Oracle have taken another (presumable unique) approach by
> using JSON number for int53-compliant BigIntegers and string notation for
> BigIntegers that doesn't fits int53.  I believe Oracle are considering a
> redesign though.
>
> The following lines in Chrome shows this division in clear:
>
> var big = 5n;
> JSON.stringify(big)
>
>  > VM887:1 Uncaught TypeError: Do not know how to serialize a BigInt
>      at Object.stringify (<anonymous>)
>      at <anonymous>:1:6
>
> Anders
>
> >
> >> That there are multiple ways of formatting integers in JSON is
> unfortunately a reality all JSON tool maker must (in some way) address.
> >
> > Are you referring to 123, 123.0, 12.3E+1 and 1.23e2 as the multiple
> ways? Or 123, "123", "123.00", and "ew==" as the multiple ways?
> >
> >> I would reverse the integer syntax and claim that integers SHOULD
> conform to standard integer (not JSON) syntax since a standard should not
> break the multitude of JSON tools that already implement this.
> >
> > It sounds like you want JSON serializers to never use the fraction or
> exponent notations when a schema says a field is an integer. That's adding
> a distinction that doesn't exist in JSON so it will break things. A tool
> parsing JSON *without knowing the schema* may well use a double for a
> number, which it may then serialize in exponent notation even if it is an
> integer. For instance, in Java Double.toString(123000000) returns "1.23E8".
> > Mind you, I suspect 1.23E8 will break many implementations that expect
> an integer so perhaps we should require the no-fraction-no-exponent form.
> >
> > This is a separate issue to this thread, however, which was whether a
> JSON schema should offer "int53" as a type, and if it should offer
> "{u}int{8|16|32}" as types.
> >
> > --
> > James Manger
> >
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>