Re: [Json] Limitations on number size?

"Peter F. Patel-Schneider" <pfpschneider@gmail.com> Tue, 09 July 2013 23:44 UTC

Return-Path: <pfpschneider@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 5E25E21F9C84 for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 16:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.416
X-Spam-Level:
X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599]
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 R9Zn+AsjgwLm for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 16:44:05 -0700 (PDT)
Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id C1F7021F9BF9 for <json@ietf.org>; Tue, 9 Jul 2013 16:44:05 -0700 (PDT)
Received: by mail-oa0-f54.google.com with SMTP id o6so8807991oag.13 for <json@ietf.org>; Tue, 09 Jul 2013 16:44:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mHCK5yYHe/zGV43wgSG5GEaH8x+DczJl0fPkQ2XUqnY=; b=KYCWyveCl50gn+khGtXaT5qbNJt9mFZHp0/hSmbXQZz6lBhJCQ8PrV12N7VDkL1iNo YYDOCQWEuATDHI5b24rQht2WZALIB5op1aJrfsbC0jN3HBbsW0hz4I6jjXFxVZmLDmqr rVadgJO72GvM6zbRXzdzfIgvzAWIJG2sIS+kTku8wZWmgFe/Y+8avg4vHT11h/dWSGt8 8mUBZgCpOBNGQMhb2XpiobBSgf35T5rrheH0zDACuPT36pCP7GbsRh8pOQi8ZFvxjw2q rNKBGExk30FKPYOz3TEyqZY7yImEcYlbYA9gsH6WeqnHbu5QD7x9V3emBvKgqvNtlvTl Ht7A==
X-Received: by 10.60.95.198 with SMTP id dm6mr25989183oeb.44.1373413445236; Tue, 09 Jul 2013 16:44:05 -0700 (PDT)
Received: from [192.168.1.102] (out-on-158.wireless.telus.com. [207.219.69.158]) by mx.google.com with ESMTPSA id mt3sm41615045oeb.1.2013.07.09.16.44.03 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 16:44:04 -0700 (PDT)
Message-ID: <51DCA042.4000303@gmail.com>
Date: Tue, 09 Jul 2013 16:44:02 -0700
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <51DC0F95.7010407@gmail.com> <hf8ot8hnpa93pi3t54c4d5qcc3p5tnb3ca@hive.bjoern.hoehrmann.de> <CAK3OfOgTNaLpRthrRcU4Bo+3z1aXUOOn0Ord7RBPN8z6TtiiWw@mail.gmail.com> <51DC7F87.6060503@gmail.com> <CAGrxA24v5L7oCGxEOwecJSLCNiLrSWSt=jFJMA0M9E8fztNLag@mail.gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com>
In-Reply-To: <20130709231139.GC8043@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, Tatu Saloranta <tsaloranta@gmail.com>, "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 23:44:06 -0000

On 07/09/2013 04:11 PM, Nico Williams wrote:
> On Tue, Jul 09, 2013 at 03:58:58PM -0700, Peter F. Patel-Schneider wrote:
>> Where then am I supposed to go to find out what a JSON number
>> represents?   There are many possibilities (float only, rational
>> [...]
> Today there is no specification to tell you that.  We're working on it.
> Here.  Right now.  With your input :)
>
> We seem to be concluding that there's no way to unify JSON.  So it may
> be that in the end you'll find two or more sets of guidance and you'll
> have to select one (or all, deferring the choice to run-time).

That's a very unhappy situation.   My interest in JSON is to consume data in 
JSON documents (mostly to use as input into representation systems that also 
use the W3C semantic web languages RDF and OWL). If JSON is ambiguous (e.g., 
as to whether 0.0 and 0 encode/stand for/represent the same thing) then JSON 
isn't very suitable for transmitting data, at least for me.
>
>> The only suitable guidance provided in RFC4627 is via ECMAScript and
>> ECMAScript is firmly IEEE floating point double only.
> It's not the only possible guidance.  You read RFC4627, you realize it's
> underspecified and look for guidance.  There's none from the IETF.
> There's search engines and if you look at enough JSON implementations
> (probably just two, at least of which must not be part of an ECMAScript
> implementation) you should note the divergent interpretations of the
> spec.
>
> Your [reasonable] mistake is to assume that because RFC4627 was inspired
> by ECMAScript notation then when ECMAScript adds a specification for
> JSON the latter must be authoritative.

Aah, but that's not what I did.  I didn't look at (the new-ish) section 15.12 
of ECMAScription version 5.1 at all.  Instead I looked at sections 7.8.3 
(numeric literals) and 8.5 (numbers) of ECMAScript version 3, which is 
referenced from, and pre-dates, RFC 4627.  I found indications that JSON 
numbers were derived from ECMAScript numeric literals, so I made the easy 
conclusion that the values represented by JSON numbers were supposed to be 
ECMAScript numbers, i.e., IEEE floating point double.

>   But standards development
> organizations don't usually recognize invasions into each others' turfs
> without prior agreements, and so... here we are.

I had no need, or even desire, to look at a subsequent non-IETF work.
>
> Now, why should anyone trying to implement JSON need to know about SDO
> politics?  Well, because there's no way to reconcile all the different
> JSONs now -- the ships have sailed.  Sooner or later anyone dealing with
> JSON will notice this, and then the question of who "owns" JSON comes
> up, and then one discovers this whole mess.  (Then one weeps.  Lather,
> rinse, repeat.)
>
>> So why are you surprised that I came up with this conclusion?
> I'm not now, but once would have been.
>
> Nico
Peter F. Patel-Schneider