Interesting.

Validation is certainly useful - we have been using kin-openapi to validate input based on the spec.

The schema object is getting unwieldy. It would be nice to simply refer to the inner spec to fetch the validations.

I'm thinking of a V2 version of this library, which greatly simplifies much of this complexity. V1 was a learning experience.

Do you have any examples of how this all ties together? It's hard to see from just the change to Schema.

This allowed us to have a simple template that uses ozzo-validation to (recursively) run validation on all structs generated.

https://github.com/curvegrid/oapi-codegen/blob/3caaaef2b6edc5abb7f54dd15f122fd06d1871c7/pkg/codegen/templates/typedef.tmpl#L14-L67

So, the idea here is to use the oapi spec to generate validation annotations so that you can use to validate struct conformance agains the spec using ozzo-validation?

I was thinking of going into a different direction with this. Already, using the validation middleware, we will ensure on the server side that client requests are correct, but what is missing is the following.

1 - We need a swagger aware function to bind a request body to a destination schema, which handles default values. This will make sure that your schema is conformant
2- When marshaling responses, we need to do the same thing, use the spec to populate default objects. This thing could also error out if your generated response is non conformant.

Right now we're returning from the server the exact struct generated for the client (from #231), combined with OAPI spec annotation (and some of our own x-go-type custom types that performs validation not specified on the spec) to ensure proper output (at least on the dev builds).
As for request bodies, we extended the Context to have body-parsing functions (GetJSONBody parses the body, runs the validation and return it). I think this kind of behavior is not one-fits-all (for example, each server might have their own way of handling errors from validation; or different validation libraries are used etc.)
This is why I think not being opinionated about a validation solution is the way to go here...

Superceded by #365 (we use fields directly from the openapi3.Schema struct now)