Closed macisamuele closed 5 years ago
I don't think what you're doing here is semantically correct. That first slash has a meaning: it identifies the value as a JSON pointer (RFC 6901). JSON schema does provide the possibility to define relative references without using JSON pointers, by using id
(documentation - note that Swagger 2 is using JSON Schema draft v4, where $id
was still called id
).
So what should happen in this case is that we should raise an error for the value #definitions/text
, probably by saying that we can't find that reference.
Going to drop this for now. I'm not 100% sure about the change after more carefully reading the JSON pointer RFC
While investigating internal issues I did noticed that the result of spec flattening is dependent on how the references looks like.
Specs like
would be flattened in something like
instead of
Note the duplicate definition of
text
(aslfile:.|..definitions..text
andlfile:.|definitions..text
)This is caused by the fact that the original spec have two equivalent but not equal references to
text
(#/definitions/text
and#definitions/text
).The goal of this PR is to ensure that once we're building a
bravado_core.spec.Spec
object we're performing some form of minimal normalisation of URIs such that duplication of definitions is reduced in case of flattening