Dealing with "int64"

[cyberphone]

It is (quite) possible that I'm misunderstanding the specification but it seems to violate https://tools.ietf.org/html/rfc7493 authored by the current JSON editor.

FWIW, I'm working on a specification which builds on this RFC as well as ES6:
https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html#rfc.appendix.D

[awwright]

You're going to have to elaborate a bit. What's the problem, what are the relevant sections of the specifications, and how can we test that we've fixed the issue?

[awwright]

If the point is that JSON Schema can describe documents outside the I-JSON subset of JSON documents... well, that's not really a problem, is it?

[cyberphone]

@awwright It is possible that I got something wrong but here it is:
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#dataTypes
long is mapped to JSON Schema's integer which in turn is mapped to JSON Number which (in most cases) only provides 56 bits of precision.

[awwright]

@cyberphone JSON doesn't place any limits on the precision of numbers, it's truly an arbitrary precision number. JSON parsers might map onto an IEEE double, but that's up to that implementation to decide how to handle a precision overflow like that, it's not really a problem for JSON Schema.

There's some other JSON Schema projects where this may be a concern. For example, we split out tests that require more precision than an IEEE double can handle, into the "optional" tests. Is there anything like this?

[cyberphone]

For interoperability reasons there {c|s}hould (IMO) be an integer56 which would be compatible with just about any JSON implementation. There is AFAICT no way redirecting ECMAScript's JSON.parse() to a custom decoder for dealing with arbitrary Numbers

[awwright]

@cyberphone Ok. JSON Schema doesn't have a format for different precisions of integers, but OpenAPI does appear to define double , which could be intersected with type: "integer".

We could also examine adding formats for the various sets of numbers (64 bit integer, IEEE double, etc).

[cyberphone]

Origin of this request: OAI/OpenAPI-Specification#1517

[handrews]

The JSON Schema data model explicitly includes arbitrary-precision numbers.

JSON Schema also includes the JSON RFC as a normative reference, and that RFC of course addresses the large / high-precision number concerns. I see no reason for JSON Schema to do more with this.

Systems that are capable of handling 64-bit integers in their representation are compatible with the data model and should be able to make use of such numbers.

We can consider proposals for numeric formats, and for string-based number formats, including possibly defining formats such as "int64" to apply to both strings and numbers. We already have one proposal for string-based numbers, json-schema-org/json-schema-vocabularies#45.

If you want such formats, please file issue(s) requesting them. I doubt they will be considered until at least draft-09, unless you or someone else can manage the discussion and write the PRs (see also json-schema-org/json-schema-vocabularies#45)

Since we do not have a goal of being in compliance with RFC 7493, and the "int64" in question is an OpenAPI format and not ours, I'm going to close this out. If we want to talk about adding numeric formats, I'd like to start that discussion from a fresh proposal and not concerns about I-JSON and OpenAPI.