Added capability to specify min/max bounds in OAS.

[bombaywalla]

For a schema with a type of "integer" or "number", you can now specify any or all of the following additional optional assertions: minimum, maximum, exclusiveMinimum, exclusiveMaximum. As per OpenAPI 3.1.0.

With tests.

Addresses #229

[oliyh]

Nice!

One approach you could use would be to derive a function for each constraint (e.g. <, >) and then invert some-fn to compose them. That way you compile the minimal function at schema-read time, not at schema checking at request time.

Doesn't the built in Int type ensure that you will get numbers by the time it hits your bounds function? Is the check that the value is a number redundant?

Thanks

[bombaywalla]

Doesn't the built in Int type ensure that you will get numbers by the time it hits your bounds function? Is the check that the value is a number redundant?

I believe I am checking to see whether the values of minimum, maximum, etc are numbers, not the value of the leaf item itself.

[bombaywalla]

One approach you could use would be to derive a function for each constraint (e.g. <, >) and then invert some-fn to compose them. That way you compile the minimal function at schema-read time, not at schema checking at request time.

Are you suggesting that, at schema-read time, I create a single bounds-checking function (say f) from all the bounds assertions and then have the schema be just one (s/constrained s/Int f) rather than nested s/constraineds? If so, I agree that would save some time at runtime. I can work on that.

Would you please clarify what you mean by "invert some-fn to compose them"?
Thanks.

[oliyh]

Are you suggesting that, at schema-read time, I create a single bounds-checking function (say f) from all the bounds assertions and then have the schema be just one (s/constrained s/Int f) rather than nested s/constraineds?

Yes, exactly this. Ignore the some-fn comment, I was thinking about the composition of f but you can do it how you like.

Thanks again for your contribution

[bombaywalla]

I updated this PR to handle the recent changes in master, so there are no conflicts.
It should be ready to merge into master after review.