Re: [Json] JSON Schema Language: int53

[Ulysse Carion <[e-mail]>]

> If you omit int53, then your code generation will never create a long despite this being a widely available & useful type.

The issue, in my view, is that int64/uint64 is the widely-available
and useful type. Not int53. To support int53 would require that code
generators implement this psuedo-type at runtime.

Consider that gRPC, which has a canonical representation in JSON and
which also has int64/uint64, unconditionally renders these types as
strings. I feel that this approach is more reasonable, as it removes
the footgun of a datatype that most users will assume is equivalent to
the familiar int64, but is not.



On Tue, Aug 20, 2019 at 9:56 PM Manger, James
<[e-mail]> wrote:
>
> Surely int53 is fine for code generation. When you see int53 in a schema, generate a field of type long (in Java).
> That alone will not enforce a 2^53 limit, but so what.
>
> When a schema has:
>   "numberOfSiblings": "int8"
>   "dayOfWeek" : "int8"
> It doesn't mean that 120 is a sensible number of brothers & sisters, or -55 can be a day of the week. It just means that the valid values for these fields can be represented with the range offered by int8. Apps still need to do their own validation beyond that.
>
> If you omit int53, then your code generation will never create a long despite this being a widely available & useful type.
>
> --
> James Manger
>
> -----Original Message-----
> From: json <[e-mail]> On Behalf Of Ulysse Carion
> Sent: Wednesday, 21 August 2019 5:06 AM
> To: Richard Gibson <[e-mail]>
> Cc: Carsten Bormann <[e-mail]>; Pete Cordell <[e-mail]>; JSON WG <[e-mail]>
> Subject: Re: [Json] JSON Schema Language: extensibility and unspecified properties
>
> [External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.
>
> > IMO, the schema should be about representing what the protocol needs
> > rather than how it is represented on a target machine.
>
> This is a reasonable stance. But I don't think it's what I'm trying to
> solve for. My focus has continually been on code generation from
> schemas; the spec's expressive power is intentionally limited
> specifically to enable code generation. Optimizing for code generation
> is why I *am* concerning myself with how things are represented on
> target machines.
>
> There are lots of good options for schemas languages that are focused
> on being as expressive as protocols are complex -- you've written one
> of these good options, Pete -- but I've been concerned with making a
> schema language as inexpressive as mainstream type systems are simple.
>
> I'm not debating whether there are ways of representing int53 in many
> languages. My objection is that I would be making up a type that
> doesn't exist in existing programming languages natively or
> idiomatically. If someone wants to do int53 bounds checks, they can
> always use the float64 type, and then do bounds checking after schema
> validation. Or they can write an extension.
>