Re: [Json] JSON Schema Language: int53

["Manger, James" <[e-mail]>]

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.