Openapi-specification: NaN, Infinity, and -Infinity for numbers

[ralfhandl]

Somehow the authors of the JSON specification forgot the special number values NaN, Infinity, and -Infinity. As a workaround we represent these double values as JSON string values, and declare the corresponding properties as
"type": ["number","string"],
"format":"double"

Is there a best practice to deal with this, and could that become part of the OpenAPI specification or an accompanying document?

[ePaul]

Can you tell us some more about the use cases where you actually need those values? In my uses I either needed (relatively small) integers or money values, and never a NaN or an infinity would make any sense. Of course I can guess that you have uses for them, but I would like to know some examples.

[ralfhandl]

These values can occur when requesting computed results, e.g. during Data Aggregation. Failing a request just because some properties have "funny" values wouldn't be acceptable, and mapping these special values to null would also mean loss of information.

[DavidBiesack]

In statistics and data analysis an IoT, missing values are quite common. For example, in a data vector contains values for each of N sources, a NaN indicates no data from that source i, while there may be data from other items in the vector. (This is different from a named value in a JSON object not being present.)

[ralfhandl]

@DavidBiesack would it be sufficient for you to represent "unknown", "NaN", "-Infinity", and "Infinity" all as null, or would it make sense to differentiate between these four special values?

[DavidBiesack]

NaN, -Infinitity and Infinity all have different meaning, so we should not coalesce them into one canonical value.

SAS analytics and data representations actually support 28 _different_ missing values which can encode different reasons _why_ a value is missing. (See MISSING! - Understanding and Making the Most of Missing Data for an explanation.) A period . corresponds to NaN but we also support distinct ._ and .A through .Z values, and SAS data analysis compensates for these when doing summary statistics such as min, max, mean, standard deviation, covariance, etc.

Note: I'm not asking that we account specifically for SAS-specific representations in OAS. I'm just voicing that it is important (to us) to allow for string representations for numerics, whether as in the OP or in some other way.

[whitlockjc]

Wouldn't this be more of a JSON Schema addition? I realize that OAI specifications are not fully JSON Schema compliant but when it comes to formats and types, they pretty much are. That being said, most JSON Schema validators allow custom formats and you could easily achieve this using a custom format.

I'm not -1 on this but having a little context never hurt.

[ralfhandl]

@whitlockjc From a JSON Schema perspective double and float are Swagger-specific "custom" formats, so the OpenAPI specification seems to be the right place to potentially extend the definition and validation rules of these "custom" formats.

This extension could be as weak as "double and float are IEEE 754 binary64 resp. binary32 floating point numbers which MAY include non-numeric special values represented as JSON strings, e.g. NaN, in which case the type array MUST include string".

[webron]

Tackling PR: #741