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

[Carsten Bormann <[e-mail]>]

On Aug 13, 2019, at 07:03, Ulysse Carion <[e-mail]> wrote:
> 
>> 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.

Many type systems don’t have a uint8, either.

> 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.

Again, the same is true for uint8.

(This opens the whole “types vs. subtypes” discussion.)

> 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?

Integer is a mathematical concept.  JSON does not have a problem with that.

The problem comes in when applications arbitrarily restrict the syntax.

Not allowing a fractional or exponent part is akin to requiring two spaces of indentation before or a newline after a number.

It gets worse when syntax variations are assigned different application semantics.
(E.g., I’m aware of at least one “JSON-based” syntax where a string that starts with “\u0073” has semantics different from a string that starts with “s”.)

You can’t do that to a format like JSON and still be part of the JSON ecosystem, because generic JSON decoders discard these syntax features, and generic JSON encoders generally can’t produce them.

>> 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.

Well, my phone number is 21863921, but some spreadsheets consider this a large number and turn it into an NR3 number…

Grüße, Carsten