Skip to content

Commit b0f7253

Browse files
lornajanehandrews
authored andcommitted
Update versions/3.1.1.md
1 parent 8346834 commit b0f7253

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

versions/3.1.1.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -159,7 +159,7 @@ It is the responsibility of an embedding format to define how to parse embedded
159159
JSON or YAML objects within an OAD are interpreted as specific Objects (such as [Operation Objects](#operation-object), [Response Objects](#response-object), [Reference Objects](#reference-object), etc.) based on their context. Depending on how references are arranged, a given JSON or YAML object can be interpreted in multiple different contexts:
160160

161161
* As the root object of the [entry document](#openapi-description-structure), which is always interpreted as an OpenAPI Object
162-
* As the Object type implied by its parent Object within the OpenAPI Description
162+
* As the Object type implied by its parent Object within the document
163163
* As a reference target, with the Object type matching the reference source's context
164164

165165
If the same JSON/YAML object is parsed multiple times and the respective contexts require it to be parsed as _different_ Object types, the resulting behavior is _implementation defined_, and MAY be treated as an error if detected. An example would be referencing an empty Schema Object under `#/components/schemas` where a Path Item Object is expected, as an empty object is valid for both types. For maximum interoperability, it is RECOMMENDED that OpenAPI Description authors avoid such scenarios.

0 commit comments

Comments
 (0)