Latest changes to v3.1.1

ralfhandl · ralfhandl · commit 3030ae382447 · 2024-09-02T17:20:26.000+02:00
diff --git a/versions/3.2.0.md b/versions/3.2.0.md
@@ -28,6 +28,10 @@ A "schema" is a formal description of syntax and structure.
 This document serves as the [schema](#schema) for the OpenAPI Specification format; a non-authoritative JSON Schema based on this document is also provided on [spec.openapis.org](https://spec.openapis.org) for informational purposes.
 This specification also _uses_ schemas in the form of the [Schema Object](#schema-object).
 
+### Object
+
+When capitalized, the word "Object" refers to any of the Objects that are named by section headings in this document.
+
 ### Path Templating
 
 Path templating refers to the usage of template expressions, delimited by curly braces (`{}`), to mark a section of a URL path as replaceable using path parameters.
@@ -135,8 +139,8 @@ Implementations MAY support complete-document parsing in any of the following wa
 * Detecting OpenAPI or JSON Schema documents using media types
 * Detecting OpenAPI documents through the root `openapi` field
 * Detecting JSON Schema documents through detecting keywords or otherwise successfully parsing the document in accordance with the JSON Schema specification
-* Detecting a document containing a referenceable object at its root based on the expected type of the reference
-* Allowing users to configure the type of documents that might be loaded due to a reference to a non-root object
+* Detecting a document containing a referenceable Object at its root based on the expected type of the reference
+* Allowing users to configure the type of documents that might be loaded due to a reference to a non-root Object
 
 Implementations that parse referenced fragments of OpenAPI content without regard for the content of the rest of the containing document will miss keywords that change the meaning and behavior of the reference target.
 In particular, failing to take into account keywords that change the base URI introduces security risks by causing references to resolve to unintended URIs, with unpredictable results.
@@ -199,27 +203,36 @@ Note that no aspect of implicit connection resolution changes how [URIs are reso
 
 ### Data Types
 
-Data types in the OAS are based on the types supported by the [JSON Schema Specification Draft 2020-12](https://tools.ietf.org/html/draft-bhutton-json-schema-00#section-4.2.1).
-Note that `integer` as a type is also supported and is defined as a JSON number without a fraction or exponent part.
-Models are defined using the [Schema Object](#schema-object), which is a superset of JSON Schema Specification Draft 2020-12.
+Data types in the OAS are based on the types defined by the [JSON Schema Validation Specification Draft 2020-12](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.1.1):
+"null", "boolean", "object", "array", "number", "string", or "integer".
+Models are defined using the [Schema Object](#schema-object), which is a superset of the JSON Schema Specification Draft 2020-12.
+
+JSON Schema keywords and `format` values operate on JSON "instances" which may be one of the six JSON data types, "null", "boolean", "object", "array", "number", or "string", with certain keywords and formats only applying to a specific type. For example, the `pattern` keyword and the `date-time` format only apply to strings, and treat any instance of the other five types as _automatically valid._ This means JSON Schema keywords and formats do **NOT** implicitly require the expected type. Use the `type` keyword to explicitly constrain the type.
+
+Note that the `type` keyword allows `"integer"` as a value for convenience, but keyword and format applicability does not recognize integers as being of a distinct JSON type from other numbers because [[RFC7159|JSON]] itself does not make that distinction. Since there is no distinct JSON integer type, JSON Schema defines integers mathematically. This means that both `1` and `1.0` are [equivalent](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00#section-4.2.2), and are both considered to be integers.
+
+#### Data Type Format
 
-<a name="data-type-format"></a>As defined by the [JSON Schema Validation specification](https://tools.ietf.org/html/draft-bhutton-json-schema-validation-00#section-7.3), data types can have an optional modifier keyword: `format`. As described in that specification, `format` is treated as a non-validating annotation by default; the ability to validate `format` varies across implementations.
+As defined by the [JSON Schema Validation specification](https://tools.ietf.org/html/draft-bhutton-json-schema-validation-00#section-7.3), data types can have an optional modifier keyword: `format`. As described in that specification, `format` is treated as a non-validating annotation by default; the ability to validate `format` varies across implementations.
 
 The OpenAPI Initiative also hosts a [Format Registry](https://spec.openapis.org/registry/format/) for formats defined by OAS users and other specifications. Support for any registered format is strictly OPTIONAL, and support for one registered format does not imply support for any others.
 
 Types that are not accompanied by a `format` keyword follow the type definition in the JSON Schema. Tools that do not recognize a specific `format` MAY default back to the `type` alone, as if the `format` is not specified.
+For the purpose of [JSON Schema validation](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-7.1), each format should specify the set of JSON data types for which it applies. In this registry, these types are shown in the "JSON Data Type" column.
 
 The formats defined by the OAS are:
 
-| [`type`](#data-types) | [`format`](#data-type-format) | Comments |
+| `format` | JSON Data Type | Comments |
 | ---- | ---- | ---- |
-| `integer` | `int32` | signed 32 bits |
-| `integer` | `int64` | signed 64 bits (a.k.a long) |
-| `number` | `float` | |
-| `number` | `double` | |
-| `string` | `password` | A hint to obscure the value. |
+| `int32` | number | signed 32 bits |
+| `int64` | number | signed 64 bits (a.k.a long) |
+| `float` | number | |
+| `double` | number | |
+| `password` | string | A hint to obscure the value. |
 
-#### Working With Binary Data
+As noted under [Data Type](#data-types), both `type: number` and `type: integer` are considered to be numbers in the data model.
+
+#### Working with Binary Data
 
 The OAS can describe either _raw_ or _encoded_ binary data.
 
@@ -253,8 +266,8 @@ The following table shows how to migrate from OAS 3.0 binary data descriptions,
 
 | OAS < 3.1 | OAS 3.1+ | Comments |
 | ---- | ---- | ---- |
-| `type: string`<br />`format: binary` | `contentMediaType: image/png` | if redundant, can be omitted, often resulting in an empty [Schema Object](#schema-object) |
-| `type: string`<br />`format: byte` | `type: string`<br />`contentMediaType: image/png`<br />`contentEncoding: base64` | note that `base64url` can be used to avoid re-encoding the base64 string to be URL-safe |
+| <code style="white-space:nowrap">type: string</code><br /><code style="white-space:nowrap">format: binary</code> | <code style="white-space:nowrap">contentMediaType: image/png</code> | if redundant, can be omitted, often resulting in an empty [Schema Object](#schema-object) |
+| <code style="white-space:nowrap">type: string</code><br /><code style="white-space:nowrap">format: byte</code> | <code style="white-space:nowrap">type: string</code><br /><code style="white-space:nowrap">contentMediaType: image/png</code><br /><code style="white-space:nowrap">contentEncoding: base64</code> | note that `base64url` can be used to avoid re-encoding the base64 string to be URL-safe |
 
 ### Rich Text Formatting
 
@@ -312,9 +325,9 @@ This is the root object of the [OpenAPI document](#openapi-description).
 | <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 `/`. |
 | <a name="oas-paths"></a>paths | [Paths Object](#paths-object) | The available paths and operations for the API. |
-| <a name="oas-webhooks"></a>webhooks | Map[`string`, [Path Item Object](#path-item-object) \| [Reference Object](#reference-object)] ] | The incoming webhooks that MAY be received as part of this API and that the API consumer MAY choose to implement. Closely related to the `callbacks` feature, this section describes requests initiated other than by an API call, for example by an out of band registration. The key name is a unique string to refer to each webhook, while the (optionally referenced) Path Item Object describes a request that may be initiated by the API provider and the expected responses. An [example](../examples/v3.1/webhook-example.yaml) is available. |
+| <a name="oas-webhooks"></a>webhooks | Map[`string`, [Path Item Object](#path-item-object) \| [Reference Object](#reference-object)] ] | The incoming webhooks that MAY be received as part of this API and that the API consumer MAY choose to implement. Closely related to the `callbacks` feature, this section describes requests initiated other than by an API call, for example by an out of band registration. The key name is a unique string to refer to each webhook, while the (optionally referenced) Path Item Object describes a request that may be initiated by the API provider and the expected responses. An [example](https://learn.openapis.org/examples/v3.1/webhook-example.html) is available. |
 | <a name="oas-components"></a>components | [Components Object](#components-object) | An element to hold various schemas for the document. |
-| <a name="oas-security"></a>security | [[Security Requirement Object](#security-requirement-object)] | A declaration of which security mechanisms can be used across the API. The list of values includes alternative Security Requirement Objects that can be used. Only one of the Security Requirement Objects need to be satisfied to authorize a request. Individual operations can override this definition. To make security optional, an empty security requirement (`{}`) can be included in the array. |
+| <a name="oas-security"></a>security | [[Security Requirement Object](#security-requirement-object)] | A declaration of which security mechanisms can be used across the API. The list of values includes alternative Security Requirement Objects that can be used. Only one of the Security Requirement Objects need to be satisfied to authorize a request. Individual operations can override this definition. The list can be incomplete, up to being empty or absent. To make security explicitly optional, an empty security requirement (`{}`) can be included in the array. |
 | <a name="oas-tags"></a>tags | [[Tag Object](#tag-object)] | A list of tags used by the document with additional metadata. The order of the tags can be used to reflect on their order by the parsing tools. Not all tags that are used by the [Operation Object](#operation-object) must be declared. The tags that are not declared MAY be organized randomly or based on the tools' logic. Each tag name in the list MUST be unique. |
 | <a name="oas-external-docs"></a>externalDocs | [External Documentation Object](#external-documentation-object) | Additional external documentation. |
 
@@ -1556,9 +1569,9 @@ application/json:
 
 ##### Considerations for File Uploads
 
-In contrast to OpenAPI 2.0, `file` input/output content in OpenAPI 3 is described with the same semantics as any other schema type.
+In contrast to OpenAPI 2.0, `file` input/output content in OAS 3.x is described with the same semantics as any other schema type.
 
-In contrast to OpenAPI 2.0, the `format` keyword has no effect on the content-encoding of the schema. Instead, JSON Schema's `contentEncoding` and `contentMediaType` keywords are used. See [Working With Binary Data](#working-with-binary-data) for how to model various scenarios with these keywords, and how to migrate from the previous `format` usage.
+In contrast to OAS 3.0, the `format` keyword has no effect on the content-encoding of the schema in OAS 3.1. Instead, JSON Schema's `contentEncoding` and `contentMediaType` keywords are used. See [Working With Binary Data](#working-with-binary-data) for how to model various scenarios with these keywords, and how to migrate from the previous `format` usage.
 
 Examples:
 
@@ -1576,6 +1589,12 @@ content:
   application/octet-stream: {}
 ```
 
+```yaml
+# arbitrary JSON without constraints beyond being syntactically valid:
+content:
+  application/json: {}
+```
+
 These examples apply to either input payloads of file uploads or response payloads.
 
 A `requestBody` for submitting a file in a `POST` operation may look like the following example:
@@ -2082,7 +2101,7 @@ To describe incoming requests from the API provider independent from another API
 
 | Field Pattern | Type | Description |
 | ---- | :----: | ---- |
-| <a name="callback-expression"></a>{expression} | [Path Item Object](#path-item-object) \| [Reference Object](#reference-object) | A Path Item Object, or a reference to one, used to define a callback request and expected responses. A [complete example](../examples/v3.0/callback-example.yaml) is available. |
+| <a name="callback-expression"></a>{expression} | [Path Item Object](#path-item-object) \| [Reference Object](#reference-object) | A Path Item Object, or a reference to one, used to define a callback request and expected responses. A [complete example](https://learn.openapis.org/examples/v3.0/callback-example.html) is available. |
 
 This object MAY be extended with [Specification Extensions](#specification-extensions).
 
@@ -2188,7 +2207,7 @@ This object MAY be extended with [Specification Extensions](#specification-exten
 In all cases, the example value SHOULD be compatible with the schema of its associated value.
 Tooling implementations MAY choose to validate compatibility automatically, and reject the example value(s) if incompatible.
 
-#### Working With Examples
+##### Working with Examples
 
 Example Objects can be used in both [Parameter Objects](#parameter-object) and [Media Type Objects](#media-type-object).
 In both Objects, this is done through the `examples` (plural) field.
@@ -2686,7 +2705,7 @@ $ref: '#/components/schemas/Pet'
 $ref: Pet.yaml
 ```
 
-##### Relative Documents With Embedded Schema Example
+##### Relative Documents with Embedded Schema Example
 
 ```json
 {
@@ -3730,7 +3749,7 @@ Please note that as of 2020, the implicit flow is about to be deprecated by [OAu
 | <a name="security-scheme-type"></a>type | `string` | Any | **REQUIRED**. The type of the security scheme. Valid values are `"apiKey"`, `"http"`, `"mutualTLS"`, `"oauth2"`, `"openIdConnect"`. |
 | <a name="security-scheme-description"></a>description | `string` | Any | A description for security scheme. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation. |
 | <a name="security-scheme-name"></a>name | `string` | `apiKey` | **REQUIRED**. The name of the header, query or cookie parameter to be used. |
-| <a name="security-scheme-in"></a>in | `string` | `apiKey` | **REQUIRED**. The ___location of the API key. Valid values are `"query"`, `"header"` or `"cookie"`. |
+| <a name="security-scheme-in"></a>in | `string` | `apiKey` | **REQUIRED**. The ___location of the API key. Valid values are `"query"`, `"header"`, or `"cookie"`. |
 | <a name="security-scheme-scheme"></a>scheme | `string` | `http` | **REQUIRED**. The name of the HTTP Authentication scheme to be used in the [Authorization header as defined in RFC7235](https://tools.ietf.org/html/rfc7235#section-5.1). The values used SHOULD be registered in the [IANA Authentication Scheme registry](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml). The value is case-insensitive, as defined in [RFC7235](https://datatracker.ietf.org/doc/html/rfc7235#section-2.1). |
 | <a name="security-scheme-bearer-format"></a>bearerFormat | `string` | `http` (`"bearer"`) | A hint to the client to identify how the bearer token is formatted. Bearer tokens are usually generated by an authorization server, so this information is primarily for documentation purposes. |
 | <a name="security-scheme-flows"></a>flows | [OAuth Flows Object](#oauth-flows-object) | `oauth2` | **REQUIRED**. An object containing configuration information for the flow types supported. |
@@ -4302,7 +4321,7 @@ when expanded with the data given earlier, we get:
 ?a=x%2By&b=x%2Fy&c=x%5Ey&words=math,is,fun
 ```
 
-#### Expansion With Non-RFC6570-Supported Options
+#### Expansion with Non-RFC6570-Supported Options
 
 But now let's say that (for some reason), we really want that `/` in the `b` formula to show up as-is in the query string, and we want our words to be space-separated like in a written phrase.
 To do that, we'll add `allowReserved: true` to `formulas`, and change to `style: "spaceDelimited"` for `words`:
