OpenAPI incompatible with I-JSON

https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#dataTypes

Apparently long maps (through JSON Schema) into JSON Number.

This is in conflict with I-JSON: https://tools.ietf.org/html/rfc7493

IMO, I-JSON is right. Promising 64 bits of precision when only 53 bit are readily available leads to unnecessary problems.

Suggested solution:

• Keep long but add “deprecated”
• Add int53 mapped into number
• Add int64 mapped into string

Related: https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html#json.bignumbers

[darrelmiller]

I think that there seem to be several competing visions here as to what JSON Schema and OpenAPI should be

Perhaps there are different visions of what JSON Schema and OpenAPI are trying to do, but it seems to me that the vision of the OpenAPI TSC is aligned with that of JSON Schema working group.

Let me try and use an analogy to see if we can agree on the different perspectives. Consider two different human languages, let’s say French and English. It seems to me, that what is being asked for in this thread is for OAS to define precise rules for describing how French words can be translated to English words. As nice as that idea sounds, there are lots of edge cases where it just wouldn’t work.

The way I see OpenAPI is that it is attempting to be an Esperanto for HTTP APIs. When people in France consume OpenAPI, then need to understand what is the highest fidelity way of translating Esperanto to French. When English people consume OpenAPI they translate in a way that makes the most sense from Esperanto.

It is not possible for the OpenAPI specification to accurately describe how to translate its typing concepts into every possible implementation language. It is the responsibility of the implementations to do the thing that makes the most sense in their native language. The hope is that the terms integer, boolean, string and number are universal enough that implementations can translate that concept into something native. Every time somebody tacks on a format there is a possibility that some platform may have to jump through hoops to make that happen.

I’m don’t want to even try to answer the question what does type: integer and format: int64 map to. It sort of depends if it is a URL parameter, a part of JSON payload, a HTML form, or a chunk of some binary blob. What I am relying on is that two tools on two different platforms will correctly translate the wire value to an internal native value that is consistent with the OpenAPI description.

The funny thing about interoperability that we have learned over the past 20 years is the more constrained you try and make the interface definition in order to avoid interoperability problems, the more interoperability problems you end up having in the real world. WSDL and XSD went to enormous lengths to be precise about interfaces and wire formats and datatypes and was significantly less effective at interoperability than far more loose alternatives.

[cyberphone]

We can close the thread now. You may have reasons revisiting it the day you begin supporting Decimal (monetary data) and BigNum which are distinct datatypes. Format-wise they can surely traverse through JSON Number but the value/gain seems limited and it will likely be incompatible with JavaScript which is about to be enriched with BigNum. I would consider doing a short research effort regarding the current use of Decimal/BigNum in conjunction with JSON. Microsoft uses a JSON Object in .NET for representing BigInteger so apparently interoperability isn’t that great for us poor JSON users 😞

OpenAPI obviously has a mission to fill here 😁