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

On 07/09/2013 10:29 PM, Peter F. Patel-Schneider wrote:
>
> 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. 

Yes, that's another good test, along these lines.

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

I tested two systems and showed they behaved a particular way. That does 
not imply that all systems behave that way.  More importantly, it 
doesn't imply that by definition all conformant systems MUST behave that 
way.

In particular, Markus tells me that PHP's JSON support does not behave 
this way.

The question is, according to the JSON WG (and presumably their 
forthcoming standard), is PHP's implementation non-conformant?  Or is 
PHP's approach of using suitable native numbers just fine?

Looking a little more, I see Python's standard library fails test 2.  It 
distinguishes doubles and ints.

Looking a little more, I see a bunch of competing JSON libraries for C, 
C++, and Java.  I'm not going to try to install and test them, but I see 
things like:

    JSON (JavaScript Object Notation) <http://www.json.org/> is a
    lightweight data-interchange format. It can represent integer, real
    number, string, an ordered sequence of value, and a collection of
    name/value pairs.
    -- http://jsoncpp.sourceforge.net/

I suspect with a couple hours (which I don't have right now) one might 
find that they all distinguish between ints and doubles.  They seem to 
focus a lot on making it easy to re-constitute objects -- so the 
consumer is expecting something about the data being read, maybe even 
expecting an int32 in one place and an int16 in another. Statically 
typed languages have some challenges here that Python and PHP and 
JavaScript don't have....

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

Well, I doubt it would hurt to ask them, if we did it clearly and 
politely, and they might even appreciate the change in topic.

If my conjecture about all these libraries is correct, however, they 
might laugh a little at our naivety.

     -- Sandro