Re: [Json] Schemas & so on

[Phillip Hallam-Baker <[e-mail]>]

On Tue, May 3, 2016 at 5:45 PM, John Cowan <[e-mail]> wrote:

> Joe Hildebrand (jhildebr) scripsit:
>
> > You need to test integers larger than 2^53 with the JSON implementation
> > in ECMAscript then.  RFC 7159, section 6 says
>
> Indeed, and browsers are surely not the only JSON implementations to
> treat all numbers as IEEE 64-bit binary floats.
>
> If we are going to have a type for integers representable as floats,
> then it should be called int54 according to the usual conventions,
> with the caveat that -(2**53) cannot be represented, because floats
> are not two's-complement.
>

I agree. I use -MaxInt as a Not a Number value in my code anyway...

Right now however, JSON isn't really suited to use as a data exchange
format for scientific use. Which is one of the things I tried to address in
JSON-B (Binary) and JSON-D (Data).

The JSON has unallocated code points that can be used to useful extend the
serialization to add additional encodings. For length delimited strings,
binary data etc. CBOR introduced a completely different data model with the
result that the JOSE working group had to be followed by a CBOR specific
one.

Binary encoding of floats is the simplest and most reliable method of
ensuring that they round trip. And that is essential if an encoding is
going to be viable for data exchange. JSON-B has binary encodings for the
IEEE 32 and 64 bit floats for that reason and JSON-D adds in the higher
precision Intel formats that use the whole 64 bits for the mantissa.

That said, binary encoding means losing the 'text file' property of JSON.
If I was going to use JSON for scientific purposes, I might well add in a
base16 or base64 encoding for floats.


Using the unused code points for extension has the advantage that even
though each serialization option requires a different encoder, a single
decoder can recognize all four variations (JSON, JSON-B, JSON-C, JSON-D).
That simplifies protocol implementation as it is only necessary for a
service to say what it will accept, it is not necessary for a client to tag
what it actually sends. It also allows encapsulation to work as you would
expect.