Re: [Json] JSON Schema Language is nearly done: int53

[Anders Rundgren <[e-mail]>]

On 2019-07-31 08:56, Manger, James wrote:
>> Dropping int64 is hardly an option, neither is BigInteger.   int53 is a special that for example fits UNIX "epoch".
> 
> Dropping int64 or BigInteger from *programming languages* is not an option. But dropping the ability for a JSON schema to suggest that arbitrary values of those types should be serialized to JSON numbers would be sensible.
> 
>> Arbitrarily sized integers are used by tons of applications based on JSON messaging and is available for most platforms including JS.
> 
> Sure, but they are not serialized to a JSON number. They are serialized to a JSON string of some form (eg "65537.00" or "AQAB").

This is where we (as a community of users) have a problem.  Jackson (now adopted by MSFT) indeed serializes BigInteger as JSON Number.  Other parties like Oracle have taken another (presumable unique) approach by using JSON number for int53-compliant BigIntegers and string notation for BigIntegers that doesn't fits int53.  I believe Oracle are considering a redesign though.

The following lines in Chrome shows this division in clear:

var big = 5n;
JSON.stringify(big)

 > VM887:1 Uncaught TypeError: Do not know how to serialize a BigInt
     at Object.stringify (<anonymous>)
     at <anonymous>:1:6

Anders

> 
>> That there are multiple ways of formatting integers in JSON is unfortunately a reality all JSON tool maker must (in some way) address.
> 
> Are you referring to 123, 123.0, 12.3E+1 and 1.23e2 as the multiple ways? Or 123, "123", "123.00", and "ew==" as the multiple ways?
> 
>> I would reverse the integer syntax and claim that integers SHOULD conform to standard integer (not JSON) syntax since a standard should not break the multitude of JSON tools that already implement this.
> 
> It sounds like you want JSON serializers to never use the fraction or exponent notations when a schema says a field is an integer. That's adding a distinction that doesn't exist in JSON so it will break things. A tool parsing JSON *without knowing the schema* may well use a double for a number, which it may then serialize in exponent notation even if it is an integer. For instance, in Java Double.toString(123000000) returns "1.23E8".
> Mind you, I suspect 1.23E8 will break many implementations that expect an integer so perhaps we should require the no-fraction-no-exponent form.
> 
> This is a separate issue to this thread, however, which was whether a JSON schema should offer "int53" as a type, and if it should offer "{u}int{8|16|32}" as types.
> 
> --
> James Manger
>