You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The validate package suports two related but different use-cases:
validating swagger specs
validating data against schemas
I would say that validating swagger specs is itself broken in:
validating a swagger schema
running extra rules
This mix of features makes the validate package difficult to document, maintain and guarantee against regression, especially the very sensitive data against schema part, which is used by go-swagger model generator.
In my opinion, we should split the package in two parts:
a package dedicated to spec validation, and possibly json-schema validation (errors as go-openapi/validate/Result)
a package dedicated to data validation against json schema (errors from go-openapi/errors)
The validate package suports two related but different use-cases:
I would say that validating swagger specs is itself broken in:
This mix of features makes the validate package difficult to document, maintain and guarantee against regression, especially the very sensitive data against schema part, which is used by go-swagger model generator.
In my opinion, we should split the package in two parts:
We could achieve that without breaking the existing interfaces using Go 1.9 type aliasing (https://github.com/golang/proposal/blob/master/design/18130-type-alias.md). However, that would break our current commitment for compatibility with 1.8.
The text was updated successfully, but these errors were encountered: