Re: What are JSON numbers; was Re: Updated JSON-LD spec to more closely align w/ RDF data model

On 07/09/2013 06:41 PM, Sandro Hawke wrote:
> On 07/09/2013 08:36 PM, Peter F. Patel-Schneider wrote:
>> I've been looking through the IETF JSON mailing list, and haven't been 
>> finding anything about mixed JSON numbers (i.e., some JSON numbers are 
>> integers and some are floats).
>>
>> I would appreciate pointers that support this interpretation of what JSON 
>> numbers mean.
>
> Just to be on the safe side, maybe we can ask that group to see if they have 
> consensus on some test cases for us.
>
> Presumably every conformant JSON parser produces the same parser-output when 
> parsing '{"test1":1}' as it does when parsing ' {"test1": 1}' (which has a 
> space after the colon).   This is a test of whether whitespace is 
> significant after the colon; presumably it is not.
>
> Here are some more tests about differences that might or might not be 
> required to be significant:
>
> Is the the parser-output required to be the same for each of these two lines:
>
> Test 1 -- one vs two zeros after the decimal
>
>     {"test1":1.0}
>     {"test1":1.00}
>
> Test 2 -- zero vs one zeros after the decimal
>
>     {"test2":1}
>     {"test2":1.0}
>
> Test 3 -- a difference too small to be represented in the mantissa of an 
> IEEE double
>
>     {"test3":1.0000000000000000}
>     {"test3":1.0000000000000001}
>
> Test 4 -- a difference which CAN be represented in IEEE double
>
>     {"test4":1.0000000000000001}
>     {"test4":1.0000000000000002}
>
> Firefox and Node both produce the same results for tests 1-3 and a different 
> results for test 4, in keeping with what we'd expect from JavaScript's use 
> of Double for every number.
>
> Also, is this is valid JSON?   (The exponent is too big for Double)
>
>     {"test5":1e309}
>
> Firefox and Node both treat this as if it said {"test5":null}
>
> I think Markus is saying the JSON spec will be non-constraining on all these 
> points, effectively saying a conformant JSON parser MAY produce different 
> output from the two lines even in test1.
>
>       -- Sandro
>

Strangely enough, the JSON spec itself is silent or incoherent on lots of 
things about numbers, including whether 1.00E1 is the same as 10.0E0.   So 
going only from RFC 4627, a JSON parser MAY produce different output from lots 
of things that sane people would think have to be the same.  My firm belief 
was that one could find out what SHOULD happen with JSON if RFC 4627 was 
silent or incoherent by looking at ECMAScript version 3, which is described as 
the basis of JSON.  (To be more precise, JSON is described as being derived 
from ECMAScript, version 3.)  However, I have been told that not only is that 
not correct, but that there have been active efforts to sever the link between 
JSON and ECMAScript.

So where does that leave JSON numbers, and JSON-LD?   The JSON-LD people are 
firmly behind one peculiar interpretation, which as you show above, is not the 
one used by Firefox or Node (or, I expect, any JSON interpretation based on 
JavaScript).  My message was an attempt to get some information on where this 
interpretation came from.

It appears that the way to find out what anything in JSON means is to examine 
JSON implementations and find out what they do. However, cat is apparently a 
fully-compliant JSON parser, so even determining what JSON implementations 
exist is not an easy task.

peter

PS:  The IETF JSON working group is bogged down on how many Unicode surrogate 
characters can dance on the top of a JSON string, so asking them for consensus 
on anything might not be very useful.

Received on Wednesday, 10 July 2013 02:30:01 UTC