Re: [Json] Limitations on number size?

Tatu Saloranta <tsaloranta@gmail.com> Tue, 09 July 2013 20:12 UTC

Return-Path: <tsaloranta@gmail.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 A326C21F8C38 for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 13:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWEFuXm6bTO4 for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 13:12:26 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id E0E7711E8158 for <json@ietf.org>; Tue, 9 Jul 2013 13:12:25 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id y10so10262495wgg.2 for <json@ietf.org>; Tue, 09 Jul 2013 13:12:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+9K9FNuJC5GR6XgREAG/C0rctUtJzvwI9Gj5entRJHY=; b=vJFukl00Z7bZ8HLctqVUg5wW4nr1uQGzURwQiZjc/ObXCywMM3Rm656idEG8Gi2k76 u8Q9WYcNjgbTU8ks/vP9+GjqOo+WouGZH5zOoBaguf6/a5YRxa5cHpgllx7ZJJFZxC6W GtMxUOBQE8R5D1BGudfmqXdXKQAnShAr5JesN/JRLXsJ7mhyMi1z2RFRwUrqw9s7DIZv u/Rxy54OzR7Fy0lBcsRWwWvsfFPx1LURZ8aKEIJq5G/PszNSpxhU1Lf+SYtbs1NAc+w1 xxnz8mYx1h4IAJbkM4bEAWoy8KXKZTrshz946+BocY8/TJEsc91KZZixLlUke+uk3UI9 GE8Q==
MIME-Version: 1.0
X-Received: by 10.180.9.212 with SMTP id c20mr14977774wib.55.1373400744776; Tue, 09 Jul 2013 13:12:24 -0700 (PDT)
Received: by 10.227.34.199 with HTTP; Tue, 9 Jul 2013 13:12:24 -0700 (PDT)
In-Reply-To: <51dc5295.0548420a.0e8f.ffffb53bSMTPIN_ADDED_BROKEN@mx.google.com>
References: <51DC0F95.7010407@gmail.com> <hf8ot8hnpa93pi3t54c4d5qcc3p5tnb3ca@hive.bjoern.hoehrmann.de> <CAK3OfOgTNaLpRthrRcU4Bo+3z1aXUOOn0Ord7RBPN8z6TtiiWw@mail.gmail.com> <51dc5295.0548420a.0e8f.ffffb53bSMTPIN_ADDED_BROKEN@mx.google.com>
Date: Tue, 9 Jul 2013 13:12:24 -0700
Message-ID: <CAGrxA26FeQKoZZssZhHJ5OWiJn_Wq2pfKHRj45jweE3hQeEVtw@mail.gmail.com>
From: Tatu Saloranta <tsaloranta@gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Content-Type: multipart/alternative; boundary=001a11c1879c86db3304e119c7cf
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Limitations on number size?
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 09 Jul 2013 20:12:26 -0000

On Tue, Jul 9, 2013 at 11:11 AM, Markus Lanthaler
<markus.lanthaler@gmx.net>wrote;wrote:

> > On Tuesday, July 09, 2013 6:38 PM, Nico Williams wrote:
> > On Tue, Jul 9, 2013 at 11:23 AM, Bjoern Hoehrmann <derhoermi@gmx.net>
> > wrote:
> > > I think it is well-understood that if you need particularily small,
> > > big, precise or otherwise unusual numbers in JSON then it's best to
> > > encode them as strings so you can do the string-to-number conversion
> > > at a higher level than whatever JSON library you might be using
> > today.
> >
> > <semifacetious>
> > If that's what we should always do then why can't parsers do it
> > automatically?
> > </semifacetious>
>
> Some parsers have options to support that. PHP, e.g. has a
> JSON_BIGINT_AS_STRING flag
>


Ditto for Java: usually coercion from JSON String to number is supported;
and ability to force output of all or some numeric types as Strings as well.
Additional settings to enable (or not) use of unlimited-length numeric
types.

Things are actually bit easier with data-binding, because expected target
type is the metadata that informs whether to truncate this (or error out),
or to keep full fidelity.

-+ Tatu +-