Re: [Json] Limitations on number size?

[Nico Williams <[e-mail]>]

On Thu, Jul 11, 2013 at 5:56 PM, Tim Bray <[e-mail]> wrote:
> On Thu, Jul 11, 2013 at 3:41 PM, Francis Galiegue <[e-mail]>
> wrote:
>> I agree, but then it is up to the protocols to define that. Say you
>> want to exchange prices over JSON, then it makes sense to require that
>> numbers be limited to two digits after the decimal point and, why not,
>> require that scientific notation not be used. (and 0.01 cannot be
>> represented reliably with a 64bit IEEE 754 floating point number, too)

Right, we could do that.  We thought we would do that for all JSON
applications, and it turns out we can't quite do it.  It'd be nice,
then, to have a reference (or three) subset(s) of JSON, to facilitate
interoperable application protocol specifications that want to use
JSON.

> Well yeah, but most programmers want to use generic non-app-sensitive
> libraries to deserialize JSON into structs or objects or database records or
> whatever, and if you send a 78-digit number that will usually break.  So as
> long as you have pre-agreement and a flexible enough library, you’re
> probably good.  This is the main reason I thought I-JSON was worth defining,
> to maximize the chance that you can use a nice simple library at both ends
> and have the lowest possible chance of breakage. -T

+1.

I think we've reached a conclusion.  It's time to confirm it.  I
believe that conclusion is: RFC4627 is what it is, we can't agree
exactly on what that is, and while we can explain some/many of the
ways that it's been interpreted, we really need a
very-likely-to-interop subset (even or more than one such subsets) of
the JSON defined in that RFC.

Nico
--