Re: [Json] Limitations on number size?

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

[I'm picking up this discussion rather late, but the issue has come up in 
JSON-LD, so I'm putting my oar in.]

My informed understanding of JSON, from reading all the relevant documents, 
was (and again is) also that JSON numbers are ECMAScript numbers are IEEE 
floating point doubles (minus some odd bits).  I was astonished to find out 
that some people disagree, apparently to the point that they believe that 0 is 
different from .0

Not being clear on the primitive data types in JSON is a very bad thing, in my 
opinion.

Peter F. Patel-Schneider


From: Jacob Davies <jacob at well.com>
To: "json at ietf.org" <json at ietf.org>
Date: Wed, 5 Jun 2013 10:51:58 -0700

On Tue, Jun 4, 2013 at 9:05 PM, Nico Williams <nico at cryptonector.com> wrote:

     It might be nice to be able to specify some ranges that MUST be
     supported by decoders, but in practice I think we can't (and probably
     shouldn't try to) even do that.


My past reading of the number section and the many references to _javascript_ 
in the spec led me to believe that the number type was _javascript_'s number 
type, and that compliance required you to accept & emit numbers only in that 
range (i.e. IEEE 754 64-bit numbers minus NaN and infinities).

Implementation limits on the length of strings or size of arrays or objects 
were not specified either, but those are large enough in most languages that 
you're unlikely to run into them unexpectedly; if you are thinking of sending 
a terabyte of text in string or an object with a trillion keys it has probably 
occurred to you that some special interoperability concerns will apply. But 
just sending large 64-bit integers as numbers in a JSON string will cause you 
interoperability problems with _javascript_ and a lot of other JSON parsers, 
and my experience & some quick searches indicate this has been a common bug 
(or misunderstanding, perhaps) in implementations.

I wouldn't say a size restriction should be specified either. But I think it 
might be worth noting this particular interoperability concern in the 
specification rather than just as a best practice.