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

[Ulysse Carion <[e-mail]>]

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

On Tue, Aug 20, 2019 at 7:34 AM Richard Gibson <[e-mail]> wrote:
>
> Exactly. binary64 is an obvious option since it is the source of the bounds, but int64 is equally capable of fulfilling the role. Just like int8 imposes constraints on a value without requiring any particular machine-local treatment or representation (which should remain irrelevant to the schema language itself), so too would int53.
>
> On Tue, Aug 20, 2019 at 7:54 AM Pete Cordell <[e-mail]> wrote:
>>
>> On 20/08/2019 04:26, Ulysse Carion wrote:
>> >> An "int53" type or other means of requiring that a JSON number have zero fractional part and magnitude no greater than 2^53.
>> >
>> > Ah -- in that case, I think it fails the other part of the criterion I
>> > put forward: having "a clear mapping to programming languages in
>> > widespread use today." In case the language is unclear, my thinking
>> > was that both (1) and (2) need to be satisfied for something to be
>> > included in the spec.
>> >
>> > At least on my view, int53's correspondence is unclear -- should it be
>> > a double/f64, or a long/int64_t, with a runtime check to make sure
>> > it's in-bounds? That's not very idiomatic. Better, in my view, to
>> > stick to uncontroversial things?
>>
>> IMO, the schema should be about representing what the protocol needs
>> rather than how it is represented on a target machine.
>>
>> An implementation may choose to store an int8 in a 32-bit integer. As
>> long as it does suitable bounds checking at the appropriate points
>> nothing outside the machine need know that it has chosen to do that.
>>
>> There may be cases where there is a need for something that is larger
>> than int32 but more inter-operable than int64. int53 satisfies that need
>> in many cases.
>>
>> Mapping it to either double/f64 or long/int64_t is a local
>> implementation choice.
>>
>> Pete.
>> --
>> ---------------------------------------------------------------------
>> Pete Cordell
>> Codalogic Ltd
>> C++ tools for C++ programmers, http://codalogic.com
>> Read & write XML in C++, http://www.xml2cpp.com
>> ---------------------------------------------------------------------