Feature: Support for OpenAPI defined formats

[scop]

OpenAPI defines some additional formats over the JSON schema validation spec:
https://github.com/OAI/OpenAPI-Specification/blob/3.1.0/versions/3.1.0.md#dataTypes

Would there be interest in adding support for those int32/int64/float/double formats ones built in in this project? I have some half done implementations that I could complete and submit.

---

Aside, implementing those exposes a small problem with the way formats are mapped currently: for example the int32 and int64 formats cannot be restricted to apply only to integer types. The format validator function cannot decide that based on the value type alone, thus those functions will be available and executed for number types as well; the type of the received value will be e.g. json.Number or float64 for both, and it might be valid for both as far as the type goes. Not that big of a problem, avoidable by simply not writing schemas that would use these formats for numbers, but I thought I'd mention it. Changing the format validator registration to also consider the type instead of just the format name would be a fix, if deemed worth fixing.

[santhosh-tekuri]

as per specification format keyword returns true if the type of value is not the expected type.
see tests. you can see that in-built formats return true if the value of not of string type.

we also have an example format odd-number which applies for number values

[scop]

Yes, string is easy, and the linked tests deal with strings. But distinguishing between number and integer within formats is not always possible with the current setup.

If I'm missing something, could you elaborate how the mentioned odd-number example would be constrained so that it would be applied only to JSON things with type integer, and not number? Currently, it applies to whatever gets unmarshaled to json.Number, float64, int, int32, int64. That includes both integer and number JSON types. (Aside, I'm unsure in which cases we'd get int/int32/int64 there, AFAIU the stdlib JSON decoder only ever emits json.Number or float64.)

Any thoughts on the main topic here, i.e. the OpenAPI formats?

[santhosh-tekuri]

i am not sure exact behaviour in that example. possibly strconv.ParseInt returns err if it is not integer. but example ignores the error. i did not think through had, as it is an example to show the api usage.

if you want to check if the value is integer, you can see how it is done here

also json spec validates 23.0 as valid integer even though it has fraction part. this is recently fixed. the spec tests are here

regarding the openapi formats, you can use strconv.ParseInt with bitSize set to 32 or 64. i guess it returns error if it overflows or underflows(not sure, to be verified)

[scop]

Unfortunately strconv.ParseInt and a few other things that operate on ints are not usable for this purpose, because they fail the .0 fraction part case. Anyway I take that comment so that the formats might be welcome here, so opened #76 for int32, int64 (float, double to follow later).

Anyway re those int checks, they're easy, too. But they won't work in preventing formats that are defined for integer to be applied to values that are specified in a schema to be number, but happen to be integer in the validated doc, too.

[santhosh-tekuri]

i am not sure whether you should provide openapi formats by default. if user is trying to validate openapi file, he will use openapi library for that. he/she never uses this library directly. that openapi library internally will use this library for validation. in such case it is better to let the openapi library provide implementation for openapi specific format.

will hold this issue/pull request in case i change my mind later...

[scop]

I submitted this for a reason ;). I'm using this particular library with OpenAPI, because no OpenAPI lib that I've found comes close to what I like to see. It's been a while, but in particular IIRC there wasn't one that would support OpenAPI 3.1. Another use case is that OA 3.1 supports actual JSON schema, and things modeled in the schemas can be used with other things than OA, such as message queue payloads, etc. It's not at all sure if an OA lib would be sanely applicable to such use cases, whereas this one is.

[SVilgelm]

I have played with openapi v3.1 and created a lib that uses this library for validation: https://github.com/sv-tools/openapi