Re: [Json] Limitations on number size?

[Stephan Beal <[e-mail]>]

On Wed, Jul 10, 2013 at 1:44 AM, Peter F. Patel-Schneider <
[e-mail]> wrote:

> 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.
>

While i think we will all agree that, at a technically pedantic level,
you're absolutely right, JSON has been in heavy use for about 10(?) years
now with _relatively_ few instances of this causing a problem. Implementors
tend to use whatever default limits the platform provides (e.g. 32-bit on
32-bit platforms and 64 on 64-bit, and 6-digit precision in doubles seems
to be conventional in C libraries). People using high-precision/very
large/very small numbers are certainly aware of the limitations/portability
problems, and will (possibly after falling on their face with JSON) pick a
different format. That's all fine and good - i haven't seen anyone here
argue that JSON needs to be _the_ data format. It needs to be a _useful_
format for a wide range of applications, and it is that even if it's
hard-coded to be limited to 31-bit integer ranges. In my implementations i
have had to be very aware of system-level precision limits, but i simply
document them, add build options to use, e.g. 64-bit integers if available,
and leave it at that. Those details fall comfortably into the normal range
of "implementation defined" details, IMO, and do _not_ (IMO) fall into
JSON's realm of authority (JSON just needs to tell me the BNF for reading a
number, though one could argue that the BNF should/does also imply certain
limits). It would be impossible to enforce that arbitrary implementations
must support arbitrarily long numbers, just as it would be silly to
arbitrarily limit JSON to, say, 20-bit precision.

Using your case of 0 vs 0.0. The vast, vast majority of JSON consumers are
JavaScript, and JS doesn't differentiate between doubles and integers, so 0
is, in effect equivalent to 0.0. In fact, there are few real-world
applications using JSON where the two are _not_ equivalent (barring
scientific, high-precision, math-centric apps, of course, and those should
probably be looking for a different format which guarantees them their
desired ranges/limits).


-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal