Fix description vs document terminology

Author: mikekistler

versions/3.1.1.md

@@ -10,7 +10,7 @@ This document is licensed under [The Apache License, Version 2.0](https://www.ap
 
 The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to HTTP APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.
 
-An OpenAPI description can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.
+An OpenAPI Description can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.
 
 For examples of OpenAPI usage and additional documentation, please visit [[?OpenAPI-Learn]].
 
@@ -91,11 +91,11 @@ The OpenAPI Specification is versioned using a `major`.`minor`.`patch` versionin
 
 Occasionally, non-backwards compatible changes may be made in `minor` versions of the OAS where impact is believed to be low relative to the benefit provided.
 
-An OpenAPI description document compatible with OAS 3.\*.\* contains a required [`openapi`](#oas-version) field which designates the version of the OAS that it uses.
+An OpenAPI Description compatible with OAS 3.\*.\* contains a required [`openapi`](#oas-version) field which designates the version of the OAS that it uses.
 
 ### Format
 
-An OpenAPI description document that conforms to the OpenAPI Specification is itself a JSON object, which may be represented either in JSON or YAML format.
+An OpenAPI Description that conforms to the OpenAPI Specification is itself a JSON object, which may be represented either in JSON or YAML format.
 
 For example, if a field has an array value, the JSON array representation will be used:
 
@@ -117,18 +117,15 @@ In order to preserve the ability to round-trip between YAML and JSON formats, YA
 * Tags MUST be limited to those allowed by [YAML's JSON schema ruleset](https://yaml.org/spec/1.2/spec.html#id2803231), which defines a subset of the YAML syntax and is unrelated to [[JSON-Schema-2020-12|JSON Schema]].
 * Keys used in YAML maps MUST be limited to a scalar string, as defined by the [YAML Failsafe schema ruleset](https://yaml.org/spec/1.2/spec.html#id2802346).
 
-**Note:** While APIs may be described by OpenAPI documents in either YAML or JSON format, the API request and response bodies and other content are not required to be JSON or YAML.
+**Note:** While APIs may be described by OpenAPI Description in either YAML or JSON format, the API request and response bodies and other content are not required to be JSON or YAML.
 
 ### OpenAPI Description Structure
 
-An OpenAPI Description (OAD) MAY be made up of a single document or be divided into multiple, connected parts at the discretion of the author. In the latter case, [Reference Object](#reference-object), [Path Item Object](#path-item-object) and [Schema Object](#schema-object) `$ref` keywords, as well as the [Link Object](#link-object) `operationRef` keyword, are used.
+An OpenAPI Description (OAD) MAY be structured as a single JSON or YAML document or composed from elements distributed across multiple documents at the discretion of the author. In the latter case, [Reference Object](#reference-object), [Path Item Object](#path-item-object) and [Schema Object](#schema-object) `$ref` keywords, as well as the [Link Object](#link-object) `operationRef` keyword, are used.
 
-Any document consisting entirely of an [OpenAPI Object](#openapi-object) is known as a **syntactically complete OpenAPI document**.
-An OpenAPI document that does _not_ reference any other documents is known as a **self-contained OpenAPI document**.
-A single-document description is therefore _both_ syntactically complete _and_ self-contained.
-In a multi-document description, the document containing the OpenAPI Object where parsing begins for a specific API's description is known as that API's **entry OpenAPI document**, or simply **entry document**.
+In a multi-document OAD, the document containing the OpenAPI Object where parsing begins is known as that OAD's **entry document**.
 
-It is RECOMMENDED that the entry OpenAPI document be named: `openapi.json` or `openapi.yaml`.
+It is RECOMMENDED that the entry document of an OAD be named: `openapi.json` or `openapi.yaml`.
 
 #### Parsing Documents
 
@@ -157,10 +154,10 @@ It is the responsibility of an embedding format to define how to parse embedded
 
 #### Structural Interoperability
 
-When parsing an OAD, JSON or YAML objects are parsed into specific Objects (such as [Operation Objects](#operation-object), [Response Objects](#response-object), [Reference Objects](#reference-object), etc.) based on the parsing context. Depending on how references are arranged, a given JSON or YAML object can be parsed in multiple different contexts:
+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:
 
-* As a syntactically complete OpenAPI Description document
-* As the Object type implied by its parent Object within the document
+* The root object of the entry document is interpreted as an OpenAPI Object
+* As the Object type implied by its parent Object within the description
 * As a reference target, with the Object type matching the reference source's context
 
 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.
@@ -316,13 +313,13 @@ In the following description, if a field is not explicitly **REQUIRED** or descr
 
 #### OpenAPI Object
 
-This is the root object of the [OpenAPI document](#openapi-description).
+This is the root object of the [OpenAPI Description](#openapi-description).
 
 ##### Fixed Fields
 
 | Field Name | Type | Description |
 | ---- | :----: | ---- |
-| <a name="oas-version"></a>openapi | `string` | **REQUIRED**. This string MUST be the [version number](#versions) of the OpenAPI Specification that the OpenAPI document uses. The `openapi` field SHOULD be used by tooling to interpret the OpenAPI document. This is _not_ related to the API [`info.version`](#info-version) string. |
+| <a name="oas-version"></a>openapi | `string` | **REQUIRED**. This string MUST be the [version number](#versions) of the OpenAPI Specification that the OpenAPI Description uses. The `openapi` field SHOULD be used by tooling to interpret the OpenAPI Description. This is _not_ related to the API [`info.version`](#info-version) string. |
 | <a name="oas-info"></a>info | [Info Object](#info-object) | **REQUIRED**. Provides metadata about the API. The metadata MAY be used by tooling as required. |
 | <a name="oas-json-schema-dialect"></a> jsonSchemaDialect | `string` | The default value for the `$schema` keyword within [Schema Objects](#schema-object) contained within this OAS document. This MUST be in the form of a URI. |
 | <a name="oas-servers"></a>servers | [[Server Object](#server-object)] | An array of Server Objects, which provide connectivity information to a target server. If the `servers` field is not provided, or is an empty array, the default value would be a [Server Object](#server-object) with a [url](#server-url) value of `/`. |
@@ -350,7 +347,7 @@ The metadata MAY be used by the clients if needed, and MAY be presented in editi
 | <a name="info-terms-of-service"></a>termsOfService | `string` | A URI for the Terms of Service for the API. This MUST be in the form of a URI. |
 | <a name="info-contact"></a>contact | [Contact Object](#contact-object) | The contact information for the exposed API. |
 | <a name="info-license"></a>license | [License Object](#license-object) | The license information for the exposed API. |
-| <a name="info-version"></a>version | `string` | **REQUIRED**. The version of the OpenAPI document (which is distinct from the [OpenAPI Specification version](#oas-version) or the version of the API being described). |
+| <a name="info-version"></a>version | `string` | **REQUIRED**. The version of the OpenAPI Description (which is distinct from the [OpenAPI Specification version](#oas-version) or the version of the API being described). |
 
 This object MAY be extended with [Specification Extensions](#specification-extensions).
 
@@ -456,7 +453,7 @@ An object representing a Server.
 
 | Field Name | Type | Description |
 | ---- | :----: | ---- |
-| <a name="server-url"></a>url | `string` | **REQUIRED**. A URL to the target host. This URL supports Server Variables and MAY be relative, to indicate that the host location is relative to the location where the OpenAPI document is being served. Variable substitutions will be made when a variable is named in `{`braces`}`. |
+| <a name="server-url"></a>url | `string` | **REQUIRED**. A URL to the target host. This URL supports Server Variables and MAY be relative, to indicate that the host location is relative to the location where the entry document of the OpenAPI Description is being served. Variable substitutions will be made when a variable is named in `{`braces`}`. |
 | <a name="server-description"></a>description | `string` | An optional string describing the host designated by the URL. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. |
 | <a name="server-variables"></a>variables | Map[`string`, [Server Variable Object](#server-variable-object)] | A map between a variable name and its value. The value is used for substitution in the server's URL template. |
 
@@ -2227,7 +2224,7 @@ Because examples using these fields represent the final serialized form of the d
 The singular `example` field in the Parameter or Media Type Object is concise and convenient for simple examples, but does not offer any other advantages over using Example Objects under `examples`.
 
 Some examples cannot be represented directly in JSON or YAML.
-For all three ways of providing examples, these can be shown as string values with any escaping necessary to make the string valid in the JSON or YAML format of the OpenAPI Description document.
+For all three ways of providing examples, these can be shown as string values with any escaping necessary to make the string valid in the JSON or YAML format of the OpenAPI Description.
 With the Example Object, such values can alternatively be handled through the `externalValue` field.
 
 ##### Example Object Examples
@@ -2667,7 +2664,7 @@ description: Pets operations
 
 #### Reference Object
 
-A simple object to allow referencing other components in the OpenAPI document, internally and externally.
+A simple object to allow referencing other components in the OpenAPI Description, internally and externally.
 
 The `$ref` string value contains a URI [RFC3986](https://tools.ietf.org/html/rfc3986), which identifies the value being referenced.
 
@@ -3322,7 +3319,7 @@ However, the exact nature of such conversions are implementation-defined.
 
 ##### Examples
 
-For these examples, assume all schemas are in the entry OpenAPI document; for handling of `discriminator` in referenced documents see [Resolving Implicit Connections](#resolving-implicit-connections).
+For these examples, assume all schemas are in a single-document OpenAPI Description; for handling of `discriminator` in referenced documents see [Resolving Implicit Connections](#resolving-implicit-connections).
 
 In OAS 3.x, a response payload MAY be described to be exactly one of any number of types:
 
@@ -3346,7 +3343,7 @@ MyResponseType:
     propertyName: petType
 ```
 
-The expectation now is that a property with name `petType` _MUST_ be present in the response payload, and the value will correspond to the name of a schema defined in the OpenAPI description. Thus the response payload:
+The expectation now is that a property with name `petType` _MUST_ be present in the response payload, and the value will correspond to the name of a schema defined in the OpenAPI Description. Thus the response payload:
 
 ```json
 {
@@ -4065,7 +4062,7 @@ The extensions properties are implemented as patterned fields that are always pr
 
 The OpenAPI Initiative maintains several [[OpenAPI-Registry|extension registries]], including registries for [individual extension keywords](https://spec.openapis.org/registry/extension/) and [extension keyword namespaces](https://spec.openapis.org/registry/namespace/).
 
-Extensions are one of the best ways to prove the viability of proposed additions to the specification.  
+Extensions are one of the best ways to prove the viability of proposed additions to the specification.
 It is therefore RECOMMENDED that implementations be designed for extensibility to support community experimentation.
 
 Support for any one extension is OPTIONAL, and support for one extension does not imply support for others.
@@ -4084,9 +4081,9 @@ Two examples of this:
 
 ## Security Considerations
 
-### OpenAPI Document Formats
+### OpenAPI Description Formats
 
-OpenAPI description documents use JSON, YAML, and JSON Schema, and therefore share their security considerations:
+OpenAPI Descriptions use JSON, YAML, and JSON Schema, and therefore share their security considerations:
 
 * [JSON](https://www.iana.org/assignments/media-types/application/json)
 * [YAML](https://www.iana.org/assignments/media-types/application/yaml)
@@ -4095,15 +4092,19 @@ OpenAPI description documents use JSON, YAML, and JSON Schema, and therefore sha
 
 ### Tooling and Usage Scenarios
 
-In addition, OpenAPI description documents are processed by a wide variety of tooling for numerous different purposes, such as client code generation, documentation generation, server side routing, and API testing. OpenAPI description authors must consider the risks of the scenarios where the OpenAPI description may be used.
+In addition, OpenAPI Descriptions are processed by a wide variety of tooling for numerous different purposes, such as client code generation, documentation generation, server side routing, and API testing. OpenAPI Description authors must consider the risks of the scenarios where the OpenAPI Description may be used.
 
 ### Security Schemes
 
-An OpenAPI description describes the security schemes used to protect the resources it defines. The security schemes available offer varying degrees of protection. Factors such as the sensitivity of the data and the potential impact of a security breach should guide the selection of security schemes for the API resources. Some security schemes, such as basic auth and OAuth Implicit flow, are supported for compatibility with existing APIs. However, their inclusion in OpenAPI does not constitute an endorsement of their use, particularly for highly sensitive data or operations.
+An OpenAPI Description describes the security schemes used to protect the resources it defines. The security schemes available offer varying degrees of protection. Factors such as the sensitivity of the data and the potential impact of a security breach should guide the selection of security schemes for the API resources. Some security schemes, such as basic auth and OAuth Implicit flow, are supported for compatibility with existing APIs. However, their inclusion in OpenAPI does not constitute an endorsement of their use, particularly for highly sensitive data or operations.
 
 ### Handling External Resources
 
-OpenAPI description documents may contain references to external resources that may be dereferenced automatically by consuming tools. External resources may be hosted on different domains that may be untrusted. References in an OpenAPI document, or across OpenAPI documents within a multi-document OpenAPI description, may cause a cycle. Tooling must detect and handle cycles to prevent resource exhaustion.
+OpenAPI Descriptions may contain references to external resources that may be dereferenced automatically by consuming tools. External resources may be hosted on different domains that may be untrusted.
+
+### Handling Reference Cycles
+
+References in an OpenAPI Description may cause a cycle. Tooling must detect and handle cycles to prevent resource exhaustion.
 
 ### Markdown and HTML Sanitization