RE: What's a Number? Was: TJSON

Hi All:

As Anders says, "number" as defined on many platforms is fraught with pitfalls.

W3C has spent considerable energy on this topic.

Please see:  W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes[1].  
Side note:  Importantly, while the spec has XML in the title, the types do not validate XML structures.  Part 2 is ONLY about mapping "strings" to value spaces - number types, date types, etc.  There are ways to compose new types as well.  But composition is NOT required in XML - types can be "born binary" or created in other ways.

The XML Schema WG, under the tutelage of some really smart mathematicians, attempted to create a "precisionDecimal" type for version 1.1.  Lacking consensus, the WG provided a "cookbook" so that you could use the Datatypes to create your own precision decimal type [2].

This type is based on IEEE 754 - 2008.  I would suggest that a green-field effort on redoing the work in Datatypes (2012) is nuts.  IMO.  If people are >serious< about creating new Datatypes, the core definitions could easily support either a simple basic type system for JSON [3], or even one that allows composition of new types, depending on taste for complexity.  But the tenets are sound, and have been hammered for about a decade and a half.

Best regards,
David

[1] https://www.w3.org/TR/xmlschema11-2/ 
[2] https://www.w3.org/TR/xsd-precisionDecimal/ 
[3] I've seen versions of JSON schema that allow exactly this kind of type reference.

> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com]
> Sent: Friday, November 04, 2016 1:12 AM
> To: Tony Arcieri
> Cc: Interledger Community Group
> Subject: What's a Number? Was: TJSON
> 
> There's probably a single data type in JSON that cause 99% of the problems
> and that's numbers.
> 
> The scientific people want 80-bits IEEE
> The Java/Python/C# folks want true 64-bit integers The crypto geeks want
> really big integers The financial guys want big decimals
> 
> These problems stem from JavaScript and they all have the same
> solution/workaround; put the data in a JSON "string".
> 
> Does this limitation/deficiency motivate a [sort of] new JSON?
> 
> In my book it does not but it seems that a lot of other people think it is a
> great idea so I can only wish you good luck!
> 
> Anders

Received on Friday, 4 November 2016 15:05:11 UTC