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

On Wednesday, July 10, 2013 5:45 AM, Sandro Hawke wrote
> On 07/09/2013 10:29 PM, Peter F. Patel-Schneider wrote:
> > 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 

Why is it not? Because JavaScript internally doesn't have integers?


> > JavaScript).  My message was an attempt to get some information on where this 
> > interpretation came from.

See my other mail.


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

Exactly.


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

Right. For PHP it depends on which platform it runs. The same is typically true for C/C++.


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

No, it is not and that won't change as such changes are explicitly out of scope for the revision of RFC4627.


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

Peter did that already and all answers I've seen so far confirm our interpretation. Here's the direct link to the thread:
    http://www.ietf.org/mail-archive/web/json/current/thrd2.html#01211


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 10 July 2013 14:41:30 UTC