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

[David Lee <dlee@calldei.com>]

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