Re: [Json] Limitations on number size?

["Peter F. Patel-Schneider" <[e-mail]>]

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