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

[Anders Rundgren <[e-mail]>]

On 2019-08-01 05:55, Ulysse Carion wrote:
> Replying to Anders and James at once:
> 
>  > The purpose of fixed sized integers in data formats is not to save bytes, it is about valid ranges and compatibility with languages like Java and C++.
> 
> Agreed. The numerical types are about writing correct software more easily in modern programming languages, not about optimizing bytes.
> 
>  > 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.
> 
> This is my view as well.

I don't understand what exactly would be dropped here...

> 
>  > 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.
> 
> It's precisely this sort of complication that motivates dropping numbers above int32/uint32 from the JSL spec. The spec remains useful without them.
> 
> The same goes for monetary data types. There are too many options, and it's better for the spec to stick to relatively uncontroversial things.

I have only found two open standards using monetary types and they used the same notion.  There is always a possibility creating a unique solution using JSON Number or JSON String.

> 
>  > 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 has been discussed in this thread before. Rough consensus suggests that it's better to simply require a zero fractional part in the number value,

> rather than impose constraints at the JSON parser level.

Right, JSL *seems* to presume that you build it on top of a standard JSON parser.  By doing that you inherit platform specific quirks that do not have a natural place in a universal JSON schema processor.

For documentation and code-gen purposes this idea should work just fine, but for run-time data validation it does not and that is the only case where the integer syntax issue would show up.

AFAICT you cannot even do range checking in a reliable manner using "any" JSON parser. Chrome:

JSON.parse('{"g":2e400}')
 > {g: Infinity}

I don't think mathematicians in general consider 2e400 as infinity :)

Before I became a JSON convert, I used XSD (XML Schema Definitions) extensively.  XSD didn't have the limitations of JSL (with respect to numbers), although it was designed 20 years ago. Unfortunately numbers in JSON are more difficult than in XML since there are two entirely different ways to textually represent numbers.

-- Anders



> 
> On Wed, Jul 31, 2019 at 12:14 AM Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     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
>      >
> 
>     _______________________________________________
>     json mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/json
>