v3.1.0-rc1 Release (#2370)

* 3.1.0 prep

* Update README

* Allow specification extensions in discriminator object

* Note that specification extensions beginning x-oas- are reserved

* security; add mutualTLS securityScheme type

* 832 add info.summary (#1779)

* Fix: #832. Add info.summary.

* Fix: summary is shord, description is verbose.

Be consistent with other definitions of summary and description.

* fix OIDC url and OAuth2 requirements

Signed-off-by: Axel Nennker <axel.nennker@telekom.de>

* Update Schema Object to proper JSON Schema

* update vocab and arbitrary props

* another go at arbitrary keywords

* feedback from @handrews

* Support style, explode, allowReserved encoding for multipart/form-data (#2066)

* Extend style, explode, allowReserved in encoding to multipart-formdata (#2018)

* Update versions/3.1.0.md

Co-Authored-By: Ron <ron@swagger.io>

* Replace details of multipart/form-data format with referce to RFC 7578

* Update versions/3.1.0.md

Co-Authored-By: Darrel <darrmi@microsoft.com>

* default should match json schema

* removed json schema keyworld list, its just all of em.

* redundant $ref reference

* Correct Styles Values for spaceDelimited and pipeDelimited, as based on Style Examples, they support objects.

* Add support for webhooks as a top-level element (#2103)

* Add webhooks as a top-level element to the spec

* Add the changes from #2048 and signpost webhooks

* Add an example of webhooks

* Relocate and expand on webhooks section following feedback

* Better wording to describe expectations on API consumers

* Clearer wording for why the paths element is here

* Update language to make callbacks clearer

* Align the OAS 3.1 nullable language with the 3.0.3 (#2115)

This adapts the language from PR #2046, with minimal wording tweaks
to account for type now being able to have multiple values (type arrays).

* allow, but discourage, requestBody for GET, HEAD, DELETE (#2117)

* Reference Object and Schema Object use of $ref updates for 2019-09 / OAS 3.1 (#2107)

* Checkpoint of draft

* Fix typo.

Co-Authored-By: Darrel <darrmi@microsoft.com>

* Fix plural anchor

Co-Authored-By: Mike Ralphson <mike.ralphson@gmail.com>

* Remove superfluous specification

Co-Authored-By: Phil Sturgeon <me@philsturgeon.uk>

Co-authored-by: Darrel <darrmi@microsoft.com>
Co-authored-by: Mike Ralphson <mike.ralphson@gmail.com>
Co-authored-by: Phil Sturgeon <me@philsturgeon.uk>

* Fix table cell formatting containing `nullable` description (#2152)

* Add SPDX identifier field to license object, fixes #1599 (#2105)

* Add information about objects to the description too

* Make paths object optional (#1781)

* Make paths object optional

* Adding reusable Path Item Objects

Under `components`

* Adopt DM's suggested change to OpenAPI doc definition

* Cleanup use of specification and definition where we mean document

* multipartite>composite, define ACL

* Add ' | Reference Object' to callbacks/webhooks

Co-authored-by: Ron <ron@swagger.io>

* Fwd port v3.0.3 dev to v3.1.0 dev (#2163)

* fix typo in Callback Object

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* retain typo in v3.0.2; fix for v3.0.3 (#1899)

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Clarify empty Security Requirement Object usage and validity (#1886)

* Clarify empty Security Requirement Object usage and validity

* Reorder sentences to make clearer.

* Remove wrong text.

* Removed unneeded text.

Co-authored-by: Ron <ron@swagger.io>
Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Ron's wording for Darrels feedback

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* ted updates

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Replace 'application' by 'API' within the 'Info Object' definition. (#2004)

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Path Templating Clarification - proposed fix for #1830. (#1831)

* Proposed fix for #1830. Each variable expression in a path must have a corresponding path parameter.

* #1830 - Removed 'at least once' to defer the question about repeated references to a single path parameter.

* Update #1830 fix with suggestion from Darrel

@darrelmiller suggestions we use "template expression" instead of "variable expression" to align with RFC6570. Good idea.

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* yaml.org supports https, but www.yaml.org is misconfigured

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Updated text for OperationRef

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* fix a typo in the Security Filtering section (#1837)

* fix a typo in the Security Filtering section

* Security filtering slight reword

Co-authored-by: Mike Ralphson <mike.ralphson@gmail.com>
Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Make ABNF for runtime expressions complete

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Explain unclear semantics of property `$ref` in Path Item Object (#1964)

* Explain unclear semantics of property `$ref` in Path Item Object

Currently, as explained in #1038 (comment) the description of `$ref` in [Path Item Object](https://github.com/OAI/OpenAPI-Specification/blob/3.0.2/versions/3.0.2.md#pathItemObject) is unclear about the semantics behing it. I took the explaination from issue #1038 to make it more clear.

* Update versions/3.1.0.md

Co-authored-by: Ron <ron@swagger.io>
Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Clarify constraints on Security Scheme Object Scheme Property (#1880)

* Wording around scheme extensions

* Clarified that securitySchemeScheme is only a SHOULD be registered scheme

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* fix difference between yaml and json in Response Object Examples

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Server Variable Object clarifications (#1809)

* Server Variable Object clarifications

* Toned language down for proper semver versioning

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Fix formatting errors in example (#2132)

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Update 3.0.3 for release (#2149)

* Update README.md for release

* Update release date for 3.0.3

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Update versions/3.1.0.md

Co-Authored-By: Darrel <darrmi@microsoft.com>
Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Fixed typo

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* explicit 'forward slash'

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* fix #2053: `style` keyword is not supported inside Schema object

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* OpenAPI not Open API

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* backticks

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* minor clarification for operationId usage in link objects (#1733)

* minor clarification

it's a bit confusing that both the id and the reference are called "operationId", so this tweak makes the text a bit more explicit.

* use right terminology

Co-Authored-By: Mike Ralphson <mike.ralphson@gmail.com>

Co-authored-by: Ron <ron@swagger.io>
Co-authored-by: Mike Ralphson <mike.ralphson@gmail.com>
Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Update 3.1.0.md

fixed typo

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Removed confusing comment

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Clarify the spec to allow optional or unspecified OAuth scopes (#1888)

* Referencing issue #513. Clarify the spec to accommodate OAuth schemes where scope may be unspecified (optional scope) or where scope is not used at all.

* Removed the provision for default scope represented as empty string. This introduces some ambiguities in the Security Requirement Object that would need to be addressed.

* For #513, adjusting language and removing examples

For #513, adjusting language and removing examples as suggested by @webron.

* removed unnecessary example header

Co-authored-by: Ron <ron@swagger.io>
Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* The examples keyword is not supported inside schema (#2042)

* examples not supported inside schema

* figured it out

* a tiny little edit

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Fix 'Security Scheme Object' definition with OAuth 2.0 grant types. (#2006)

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

* Fix formatting errors in example (#2132)

Signed-off-by: Mike Ralphson <mike.ralphson@gmail.com>

Co-authored-by: seiya <r108338@yahoo.co.jp>
Co-authored-by: Adam Leventhal <ahl@transposit.com>
Co-authored-by: Sebastián Ramírez <tiangolo@gmail.com>
Co-authored-by: Ron <ron@swagger.io>
Co-authored-by: Phil Sturgeon <me@philsturgeon.uk>
Co-authored-by: Patrice Krakow <patrice.krakow@gmail.com>
Co-authored-by: Ted Epstein <ted.epstein@reprezen.com>
Co-authored-by: Darrel Miller <darrmi@microsoft.com>
Co-authored-by: Carsten Brandt <mail@cebe.cc>
Co-authored-by: Henry Andrews <andrews_henry@yahoo.com>
Co-authored-by: Sergej <sergej2705@users.noreply.github.com>
Co-authored-by: nasa9084 <nasa.9084.bassclarinet@gmail.com>
Co-authored-by: Erik Wilde <dret@users.noreply.github.com>

* security; widen use of scopes array to other securityScheme types (#1829)

Co-authored-by: Ron <ron@swagger.io>

* Allow summary and description as $ref siblings (#2181)

* HTTP not REST (#1946)

Co-authored-by: Phil Sturgeon <me@philsturgeon.uk>

* Missing updates

While going over the changes for the release notes, found two issues:
- The TOC entry for `Relative references in URIs` was not modified to match the change in the spec.
- The `Paths Object` had an extra sentence that should have not been there (referencing sub-documents and overlays).

* Remove boolean compatibility for exclusive* (#2226)

This brings exclusiveMinimum, exclusiveMaximum, minimum, and
maximum, into full modern JSON Schema compatibility.

There are no edits directly mentioning minimum and maximum,
but removing the boolean form simplifies their processing
by making it context-independent.

* Update "format" and "content*" for new JSON Schema (#2200)

* Update "format" and "content*" for new JSON Schema

This removes OAS formats and examples that are now superfluous
as they are part of the 2019-09 JSON Schema draft.

Similarly it deprecates the "byte" and "binary" formats in favor
of JSON Schema's "contentEncoding" and "contentMediaType" keywords,
and updates various related exapmles and other guidance.

It also removes confusingly blank rows in the OAS format table.

* "format" is an annotation

* Fix broken table, type, in Encoding Object

Broke some things while updating for "content*"

* Fix format of `format`

Backticks, not double quotes.

* Remove unneeded detail on "format"

This was just duplicating info from the JSON Schema spec.

Co-authored-by: Darrel <darrmi@microsoft.com>

* Remove "byte" and "binary" formats altogether.

Instead of just deprecating.  The "content*" keywords now
cover these use cases.

* Harmonize JSON Schema content* + Media Type Object

Includes harmonizing with the Encoding Object.  In general,
OpenAPI objects set the media type, although there is a case
for `contentMediaType` with multipart/form-data.  Otherwise,
`contentEncoding` replaces the now-removed custom formats.

A possibly controversial change is to indicate unencoded binary
data by omitting `type` (or omitting the schema altogether), as
binary data does not conform to JSON string requirements.

This could still be done with `type: string` if that is preferred.
It's going to be a bit weird either way.

I can add wording in the next JSON Schema draft to clarify
whichever approach makes more sense.

* Fix typos from review

* Remove stray {}

* Fix inconsistencies contentMediaType and Encoding Object

Co-authored-by: Darrel <darrmi@microsoft.com>

* [3.1.0-dev] drop OAS semver requirement (#2243)

* drop OAS semver requirement

* Update versions/3.1.0.md

Co-authored-by: Darrel <darrmi@microsoft.com>

* Remove "nullable" entirely (#2246)

* Update version for release (#2269)

* $schema Guidance (#2266)

* chore: explain how $schema might work

* reordered and made it specifically only schema resources

* Update versions/3.1.0.md

Co-authored-by: Karen Etheridge <ether@cpan.org>

* Update versions/3.1.0.md

Co-authored-by: Ben Hutton <relequestual@gmail.com>

* new approach

Co-authored-by: Phil Sturgeon <me@philsturgeon.uk>
Co-authored-by: Karen Etheridge <ether@cpan.org>
Co-authored-by: Ben Hutton <relequestual@gmail.com>

* v3.1.0: rephrase data-type section because `format` keyword can be used for any data type. (#2302)

* The JSON schema specification states the format keyword can be used for any data type, not just primitive types

* The JSON schema specification states the format keyword can be used for any data type, not just primitive types

* Added change to address #2287 (#2328)

Co-authored-by: Darrel Miller <darrel.miller@microsoft.com>

* Make Server Variable Object's properties more strict (#2335)

Followup to #1809, now that we allow breaking changes.

* docs(Components): fix typo in schemas field type (#2337)

* Fix indentation of a YAML comment

* Removed required constraint on responses object (#2329)

Co-authored-by: Darrel Miller <darrel.miller@microsoft.com>

* 3.1.0-rc1 Release prep (#2369)

* Update 3.1.0.md

* Merge branch 'master' into v3.1.0-dev

Co-authored-by: Mike Ralphson <mike.ralphson@gmail.com>
Co-authored-by: Roberto Polli <robipolli@gmail.com>
Co-authored-by: Axel Nennker <axel.nennker@telekom.de>
Co-authored-by: Phil Sturgeon <me@philsturgeon.uk>
Co-authored-by: Mike Kistler <mkistler@us.ibm.com>
Co-authored-by: Darrel <darrmi@microsoft.com>
Co-authored-by: Arhimenrius <arhimenrius@gmail.com>
Co-authored-by: Lorna Jane Mitchell <lorna@lornajane.net>
Co-authored-by: Henry Andrews <andrews_henry@yahoo.com>
Co-authored-by: Alan Crosswell <alan@crosswell.us>
Co-authored-by: Helen Kosova <hkosova@users.noreply.github.com>
Co-authored-by: seiya <r108338@yahoo.co.jp>
Co-authored-by: Adam Leventhal <ahl@transposit.com>
Co-authored-by: Sebastián Ramírez <tiangolo@gmail.com>
Co-authored-by: Patrice Krakow <patrice.krakow@gmail.com>
Co-authored-by: Ted Epstein <ted.epstein@reprezen.com>
Co-authored-by: Carsten Brandt <mail@cebe.cc>
Co-authored-by: Sergej <sergej2705@users.noreply.github.com>
Co-authored-by: nasa9084 <nasa.9084.bassclarinet@gmail.com>
Co-authored-by: Erik Wilde <dret@users.noreply.github.com>
Co-authored-by: Marsh Gardiner <marsh.gardiner@gmail.com>
Co-authored-by: Phil Sturgeon <me@philsturgeon.com>
Co-authored-by: Karen Etheridge <ether@cpan.org>
Co-authored-by: Ben Hutton <relequestual@gmail.com>
Co-authored-by: Sebastien Rosset <serosset@cisco.com>
Co-authored-by: Darrel Miller <darrel.miller@microsoft.com>
Co-authored-by: Vladimir Gorej <vladimir.gorej@gmail.com>
Co-authored-by: Helen Kosova <helen.kosova@smartbear.com>

Author: 27 people

README.md

@@ -19,9 +19,9 @@ This GitHub project is the starting point for OpenAPI. Here you will find the in
 
 The current version of the OpenAPI specification is [OpenAPI Specification 3.0.3](versions/3.0.3.md).
 
-## Current Release Candidate Version - 3.1.0-RC0
+## Current Release Candidate Version - 3.1.0-RC1
 
-We invite the community to review and provide feedback for the current release candidate ([OpenAPI Specification 3.1.0-RC0](versions/3.1.0.md). Changes related to the upcoming 3.1.0 release should be submitted at [the development branch](https://github.com/OAI/OpenAPI-Specification/tree/v3.1.0-dev).
+We invite the community to review and provide feedback for the current release candidate ([OpenAPI Specification 3.1.0-RC1](versions/3.1.0.md). Changes related to the upcoming 3.1.0 release should be submitted at [the development branch](https://github.com/OAI/OpenAPI-Specification/tree/v3.1.0-dev).
 
 ### Previous Versions
 

versions/3.1.0.md

@@ -1,6 +1,6 @@
 # OpenAPI Specification
 
-#### Version 3.1.0-rc0
+#### Version 3.1.0-rc1
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP 14](https://tools.ietf.org/html/bcp14) [RFC2119](https://tools.ietf.org/html/rfc2119) [RFC8174](https://tools.ietf.org/html/rfc8174) when, and only when, they appear in all capitals, as shown here.
 
@@ -73,7 +73,7 @@ A self-contained or composite resource which defines or describes an API or elem
 ##### <a name="pathTemplating"></a>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.
 
-Each template expression in the path MUST correspond to a path parameter that is included in the [Path Item](#path-item-object) itself and/or in each of the Path Item's [Operations](#operation-object).
+Each template expression in the path MUST correspond to a path parameter that is included in the [Path Item](#path-item-object) itself and/or in each of the Path Item's [Operations](#operation-object). An exception is if the path item is empty, for example due to ACL constraints, matching path parameters are not required.
 
 ##### <a name="mediaTypes"></a>Media Types
 Media type definitions are spread across several resources.
@@ -139,17 +139,12 @@ It is RECOMMENDED that the root OpenAPI document be named: `openapi.json` or `op
 
 ### <a name="dataTypes"></a>Data Types
 
-Primitive data types in the OAS are based on the types supported by the [JSON Schema Specification Draft 2019-09](http://json-schema.org/draft/2019-09/json-schema-core.html#rfc.section.4.2). 
+Data types in the OAS are based on the types supported by the [JSON Schema Specification Draft 2019-09](http://json-schema.org/draft/2019-09/json-schema-core.html#rfc.section.4.2). 
 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](#schemaObject), which is a superset of JSON Schema Specification Draft 2019-09.
 
-<a name="dataTypeFormat"></a>Primitives have an optional modifier property: `format`, which is defined by JSON Schema.
-OAS uses several known additional formats to define in fine detail the data type being used.
-However, to support documentation needs, the `format` property is an open `string`-valued property, and can have any value.
-Additional formats MAY be used even though undefined by either JSON Schema or this specification.
-Types that are not accompanied by a `format` property 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.
-
-Note that by default, JSON Schema validators will not attempt to validate the `format` keyword.  https://json-schema.org/draft/2019-09/release-notes.html#format-vocabulary
+<a name="dataTypeFormat"></a>As defined by JSON Schema, data types can have an optional modifier property: `format`.
+OAS defines additional formats to provide fine detail for primitive data types.
 
 The formats defined by the OAS are:
 
@@ -429,8 +424,8 @@ An object representing a Server Variable for server URL template substitution.
 
 Field Name | Type | Description
 ---|:---:|---
-<a name="serverVariableEnum"></a>enum | [`string`] | An enumeration of string values to be used if the substitution options are from a limited set. The array SHOULD NOT be empty.
-<a name="serverVariableDefault"></a>default | `string` |  **REQUIRED**. The default value to use for substitution, which SHALL be sent if an alternate value is _not_ supplied. Note this behavior is different than the [Schema Object's](#schemaObject) treatment of default values, because in those cases parameter values are optional. If the [`enum`](#serverVariableEnum) is defined, the value SHOULD exist in the enum's values.
+<a name="serverVariableEnum"></a>enum | [`string`] | An enumeration of string values to be used if the substitution options are from a limited set. The array MUST NOT be empty.
+<a name="serverVariableDefault"></a>default | `string` |  **REQUIRED**. The default value to use for substitution, which SHALL be sent if an alternate value is _not_ supplied. Note this behavior is different than the [Schema Object's](#schemaObject) treatment of default values, because in those cases parameter values are optional. If the [`enum`](#serverVariableEnum) is defined, the value MUST exist in the enum's values.
 <a name="serverVariableDescription"></a>description | `string` | An optional description for the server variable. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation.
 
 This object MAY be extended with [Specification Extensions](#specificationExtensions).
@@ -445,7 +440,7 @@ All objects defined within the components object will have no effect on the API
 
 Field Name | Type | Description
 ---|:---|---
-<a name="componentsSchemas"></a> schemas | Map[`string`, [Schema Object](#schemaObject) | An object to hold reusable [Schema Objects](#schemaObject).
+<a name="componentsSchemas"></a> schemas | Map[`string`, [Schema Object](#schemaObject)] | An object to hold reusable [Schema Objects](#schemaObject).
 <a name="componentsResponses"></a> responses | Map[`string`, [Response Object](#responseObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Response Objects](#responseObject).
 <a name="componentsParameters"></a> parameters | Map[`string`, [Parameter Object](#parameterObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Parameter Objects](#parameterObject).
 <a name="componentsExamples"></a> examples | Map[`string`, [Example Object](#exampleObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Example Objects](#exampleObject).
@@ -850,7 +845,7 @@ Field Name | Type | Description
 <a name="operationId"></a>operationId | `string` | Unique string used to identify the operation. The id MUST be unique among all operations described in the API. The operationId value is **case-sensitive**. Tools and libraries MAY use the operationId to uniquely identify an operation, therefore, it is RECOMMENDED to follow common programming naming conventions.
 <a name="operationParameters"></a>parameters | [[Parameter Object](#parameterObject) \| [Reference Object](#referenceObject)] | A list of parameters that are applicable for this operation. If a parameter is already defined at the [Path Item](#pathItemParameters), the new definition will override it but can never remove it. The list MUST NOT include duplicated parameters. A unique parameter is defined by a combination of a [name](#parameterName) and [location](#parameterIn). The list can use the [Reference Object](#referenceObject) to link to parameters that are defined at the [OpenAPI Object's components/parameters](#componentsParameters).
 <a name="operationRequestBody"></a>requestBody | [Request Body Object](#requestBodyObject) \| [Reference Object](#referenceObject) | The request body applicable for this operation.  The `requestBody` is fully supported in HTTP methods where the HTTP 1.1 specification [RFC7231](https://tools.ietf.org/html/rfc7231#section-4.3.1) has explicitly defined semantics for request bodies.  In other cases where the HTTP spec is vague (such as [GET](https://tools.ietf.org/html/rfc7231#section-4.3.1), [HEAD](https://tools.ietf.org/html/rfc7231#section-4.3.2) and [DELETE](https://tools.ietf.org/html/rfc7231#section-4.3.5)), `requestBody` is permitted but does not have well-defined semantics and SHOULD be avoided if possible.
-<a name="operationResponses"></a>responses | [Responses Object](#responsesObject) | **REQUIRED**. The list of possible responses as they are returned from executing this operation.
+<a name="operationResponses"></a>responses | [Responses Object](#responsesObject) | The list of possible responses as they are returned from executing this operation.
 <a name="operationCallbacks"></a>callbacks | Map[`string`, [Callback Object](#callbackObject) \| [Reference Object](#referenceObject)] | A map of possible out-of band callbacks related to the parent operation. The key is a unique identifier for the Callback Object. Each value in the map is a [Callback Object](#callbackObject) that describes a request that may be initiated by the API provider and the expected responses.
 <a name="operationDeprecated"></a>deprecated | `boolean` | Declares this operation to be deprecated. Consumers SHOULD refrain from usage of the declared operation. Default value is `false`.
 <a name="operationSecurity"></a>security | [[Security Requirement Object](#securityRequirementObject)] | A declaration of which security mechanisms can be used for this operation. 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. To make security optional, an empty security requirement (`{}`) can be included in the array. This definition overrides any declared top-level [`security`](#oasSecurity). To remove a top-level security declaration, an empty array can be used.
@@ -1485,7 +1480,7 @@ In addition, specific media types MAY be specified:
 # multiple, specific media types may be specified:
 requestBody:
   content:
-      # a binary file of type png or jpeg
+    # a binary file of type png or jpeg
     image/jpeg: {}
     image/png: {}
 ```
@@ -2336,6 +2331,14 @@ As such, inline schema definitions, which do not have a given id, *cannot* be us
 The [xml](#schemaXml) property allows extra definitions when translating the JSON definition to XML.
 The [XML Object](#xmlObject) contains additional information about the available options.
 
+###### Picking Schema Vocabularies
+
+It is important for tooling to be able to detect what meta-schema any given resource wishes to be processed with: JSON Schema Core, JSON Schema Validation, OpenAPI Schema Object, or some custom meta schema.
+
+`$schema` MAY be present in any Schema Object, and if present MUST be used to determine which dialect should be used when processing the schema.
+
+When `$schema` is not present, the default the following dialect MUST be assumed: `$schema: "https://spec.openapis.org/oas/3.1/schema-object"`.
+
 ##### Schema Object Examples
 
 ###### Primitive Sample
@@ -3419,6 +3422,7 @@ Two examples of this:
 
 Version   | Date       | Notes
 ---       | ---        | ---
+3.1.0-rc0 | 2020-10-08 | rc1 of the 3.1 specification
 3.1.0-rc0 | 2020-06-18 | rc0 of the 3.1 specification
 3.0.3     | 2020-02-20 | Patch release of the OpenAPI Specification 3.0.3
 3.0.2     | 2018-10-08 | Patch release of the OpenAPI Specification 3.0.2