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

[Ulysse Carion <[e-mail]>]

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

On Mon, Aug 19, 2019 at 5:52 PM Richard Gibson <[e-mail]> wrote:
>
> An "int53" type or other means of requiring that a JSON number have zero fractional part and magnitude no greater than 2^53.
>
> On Mon, Aug 19, 2019 at 4:46 PM Ulysse Carion <[e-mail]> wrote:
>>
>> > But is the portability argument not sufficient for including such a constraint, as it was for I-JSON?
>>
>> What constraint are you referring to here?
>> On Sun, Aug 18, 2019 at 6:32 PM Richard Gibson <[e-mail]> wrote:
>> >
>> > On Sat, Aug 17, 2019 at 9:35 PM Ulysse Carion <[e-mail]> wrote:
>> >>
>> >> no mainstream language I know of has support for integers strictly up to 2^53
>> >
>> >
>> > From a certain point of view, nearly all mainstream languages do so, because that is the maximum value in the range of contiguous IEEE 754 binary64 integers and thus the upper bound on portable integers (which is why RFC 7493 section 2.2 limits I-JSON numbers to being strictly less than it). But you're right that languages have no int53-specific type, because those with specific integer types have at least the larger range of int64 and those without them have the larger reduced-precision range of binary64. But is the portability argument not sufficient for including such a constraint, as it was for I-JSON?