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
In the discussions around JSON Schema and OpenAPI Specification 3.1, we need to clarify the determination of the base URI for each of the embedded JSON Schema resources.
The OAS document has its own media type, and its own rules for determining a base URI. These fall under RFC 3986's "base URI embedded in the document" approach. We should probably update our own section 8.2.1 Initial Base URI to note that, in the case of a JSON Schema resource embedded in a document of another media type, the initial base URI is determined according to the rules of that media type.
This is philosophically consistent with what's already there, I believe, and would clarify an important use case. And would mean that specifications like OAS 3.1 would not have to call it out as a special case.
OR, are we saying this is two cases of "5.1.1. Base URI Embedded in Content", and we need to determine if the JSON Schema $id or the base URI as determined by OAS is the one by which relative references should be resolved?
I think I'm clear that it's the first, but we need to specify that the initial base URI is defined by the enclosing document should it not be defined by the JSON Schema document object (which I read as per RFC 3986 5.1.2 anyway).
In the discussions around JSON Schema and OpenAPI Specification 3.1, we need to clarify the determination of the base URI for each of the embedded JSON Schema resources.
The OAS document has its own media type, and its own rules for determining a base URI. These fall under RFC 3986's "base URI embedded in the document" approach. We should probably update our own section 8.2.1 Initial Base URI to note that, in the case of a JSON Schema resource embedded in a document of another media type, the initial base URI is determined according to the rules of that media type.
This is philosophically consistent with what's already there, I believe, and would clarify an important use case. And would mean that specifications like OAS 3.1 would not have to call it out as a special case.
Also paging @webron @darrelmiller @philsturgeon
The text was updated successfully, but these errors were encountered: