Re: [xml-dev] The JSON Data Interchange Format (ECMA standard, October 2

[Michael Kay <mike@saxonica.com>]

My reading is that the statement "JSON is based on a subset of ECMAScript " is a statement about the history and origins of the spec, and has no normative effect.

But perhaps this has caused confusion in the past and this is why the new ECMA 404 has a clarifying paragraph on the subject.

Michael Kay
Saxonica

On 17 Oct 2013, at 14:54, David Lee wrote:

> 
>> I would find it humors, if it were not so true, so I find it sad that the people writing this actually belive it.
>> 
>> That the JSON representation of numbers is sufficient for data interchange ... 
>> -->  Simple integers like anything greater then 2^53 cannot be represented in JSON.  
> 
> That's not correct. Neither the spec at www.json.org, nor the new ECMA spec, nor RFC 4627, imposes any limit on the size of a number. There may be JSON implementations that impose limits, just as some XML implementations may impose limits on the size of an xs:integer value, but that's their choice.
> 
> Michael Kay
> Saxonica
> ------------
> 
> It may not be "correct" for some meaning of "correct" but it is my best interpretation of json.org
> which says 
> 
> "is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999."
> And not providing any clarification links to:
> 
> http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
> 
> Very clearly says, in 8.5
> 
> -=----- QUOTE --------------
> 8.5 The Number Type
> The Number type has exactly 18437736874454810627 (that is, 264253+3) values, representing the double-precision 64-bit format IEEE 754 values as specified in the IEEE Standard for Binary Floating-Point Arithmetic, except that the 9007199254740990 (that is, 2532) distinct ―Not-a-Number‖ values of the IEEE Standard are represented in ECMAScript as a single special NaN value. (Note that the NaN value is produced by the program expression NaN.) In some implementations, external code might be able to detect a difference between various Not-a-Number values, but such behaviour is implementation-dependent; to ECMAScript code, all NaN values are indistinguishable from each other.
> -----------------
> 
> 
> My reading of "subset" is that unless stated otherwise the ECMA spec referenced takes precident.
> What is your reading ?
> 
> 
> 
> 
>