Re: [Json] JSON Schema Language: extensibility and unspecified properties

[Ulysse Carion <[e-mail]>]

> However, it seems bizarre to support int8, int16, and int32, but not JSON’s generic interoperable integers.

Supposing we add int53 to JSL, do you picture code generators
producing int64_t/long for {"type": "int53" }? Does that mean that,
before serializing an int64_t to something marked as int53 in JSL, the
application must first do an extra bounds check? Today, it's fairly
easy to generate code from JSL where serializing is an infallible
affair. But with int53, that property would be lost, because most type
systems cannot express int53.

I'm inclined to think this is something better handled by extensions.
Perhaps someone can define a "intt53" property to do something like:

{ "type": "number", "int53": true }

The person writing the extension would document that the "int53"
property indicates whether a number is meant to represent a number in
the I-JSON range. Applications which don't understand this keyword
will still do something reasonable -- validate for some sort of
number, and code generate a "double" -- but applications which care
about this can handle this case specially. It also signals an intent
about how the number will be used.

I expect this sort of approach is how JSL may need to handle
big-number encoding schemes. There are so many different ways approach
that problem, and I think JSL is most useful if it establishes an
uncontroversial foundation, and then lets additional, out-of-spec
keywords tighten the schema further in a way which most folks don't
care about, and hence don't want to have to implement.

Does that seem like a reasonable approach?

> Actually, that’s something JSON can’t deal with.

By this you mean that JSON prescribes "all numbers are doubles", and
so integers aren't really a good thing to try to foist onto JSON's
syntax?

> MS-Excel has repeatedly taught me that my university phone number is 2.1863921e7, but people still manage to call me :-)

Could you expand what you mean here? I realize no joke is funny enough
to survive explanation, but I'm afraid I'm perhaps missing your point.

On Sun, Aug 11, 2019 at 1:06 PM Carsten Bormann <[e-mail]> wrote:
>
> On Aug 11, 2019, at 19:33, Ulysse Carion <[e-mail]> wrote:
> >
> >> This is a nice demonstration that it was a mistake to remove uint53.
> >
> > Perhaps. But perhaps instead I should just use {"type": "number"}, and
> > accept that JSL isn't going to be able to express certain things about
> > numbers?
>
> Sure, that is one way of handling it.
> However, it seems bizarre to support int8, int16, and int32, but not JSON’s generic interoperable integers.
>
> > Re-reading https://tools.ietf.org/html/rfc7071, it seems it constrains
> > the timestamps to not have a fractional part at the JSON syntax level.
>
> Oops.
> (I’d consider this an erratum, though, as Section 2.4 of RFC 4627 does not define “integer”.)
>
> > That’s another thing JSL can't deal with.
>
> Actually, that’s something JSON can’t deal with.
>
> > But I'm not sure if in
> > practice that’s such a big deal.
>
> MS-Excel has repeatedly taught me that my university phone number is 2.1863921e7, but people still manage to call me :-)
>
> Grüße, Carsten
>