From 9e1e71d74ee2ba8d654cd17fc884f19f74bbf0fa Mon Sep 17 00:00:00 2001
From: Ralf Handl <ralf.handl@sap.com>
Date: Tue, 24 Sep 2024 17:57:35 +0200
Subject: [PATCH] format-markdown

---
 versions/3.1.1.md | 31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/versions/3.1.1.md b/versions/3.1.1.md
index 54a2f32199..7ba6d54dbb 100644
--- a/versions/3.1.1.md
+++ b/versions/3.1.1.md
@@ -2775,7 +2775,7 @@ The `readOnly` and `writeOnly` keywords are annotations, as JSON Schema is not a
 Validation of these keywords MAY be done by checking the annotation, the read or write direction, and (if relevant) the current value of the field.
 [JSON Schema Validation Draft 2020-12 §9.4](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-9.4) defines the expectations of these keywords, including that a resource (described as the "owning authority") MAY either ignore a `readOnly` field or treat it as an error.
 
-An example of  where ignoring a "written" `readOnly` field might be appropriate is a PUT request where the field is included but the value has not been changed, since the alternative of leaving out the field would result in the field's deletion per [[RFC7231]].
+An example of where ignoring a "written" `readOnly` field might be appropriate is a PUT request where the field is included but the value has not been changed, since the alternative of leaving out the field would result in the field's deletion per [[RFC7231]].
 
 Note that the behavior of `readOnly` in particular differs from that specified by version 3.0 of this specification.
 
@@ -2808,7 +2808,7 @@ An example is included in the "Schema Object Examples" section below, and furthe
 
 The Schema Object's `enum` keyword does not allow associating descriptions or other information with individual values.
 
-Implementations MAY support recognizing a `oneOf` or `anyOf` where each subschema in the keyword's array consists of a `const` keyword and annotations such as `title` or `description` as an enumerated type with additional information.  The exact behavior of this pattern beyond what is required by JSON Schema is implementation-defined.
+Implementations MAY support recognizing a `oneOf` or `anyOf` where each subschema in the keyword's array consists of a `const` keyword and annotations such as `title` or `description` as an enumerated type with additional information. The exact behavior of this pattern beyond what is required by JSON Schema is implementation-defined.
 
 ###### XML Modeling
 
@@ -2919,20 +2919,23 @@ additionalProperties:
 
 ```json
 {
-  "oneOf": [{
-    "const": "RGB",
-    "title": "Red, Green, Blue",
-    "description": "Specify colors with the red, green, and blue additive color model"
-  }, {
-    "const": "CMYK",
-    "title": "Cyan, Magenta, Yellow, Black",
-    "description": "Specify colors with the cyan, magenta, yellow, and black subtractive color model"
-  }]
+  "oneOf": [
+    {
+      "const": "RGB",
+      "title": "Red, Green, Blue",
+      "description": "Specify colors with the red, green, and blue additive color model"
+    },
+    {
+      "const": "CMYK",
+      "title": "Cyan, Magenta, Yellow, Black",
+      "description": "Specify colors with the cyan, magenta, yellow, and black subtractive color model"
+    }
+  ]
 }
 ```
 
 ```yaml
-  oneOf:
+oneOf:
   - const: RGB
     title: Red, Green, Blue
     description: Specify colors with the red, green, and blue additive color model
@@ -4520,7 +4523,7 @@ This keeps it outside of the processes governed by this specification.
 
 ## Appendix F: Resolving Security Requirements in a Referenced Document
 
-This appendix shows how to retrieve an HTTP-accessible multi-document OpenAPI Description (OAD) and resolve a [Security Requirement Object](#security-requirement-object) in the referenced (non-entry) document.  See [Resolving Implicit Connections](#resolving-implicit-connections) for more information.
+This appendix shows how to retrieve an HTTP-accessible multi-document OpenAPI Description (OAD) and resolve a [Security Requirement Object](#security-requirement-object) in the referenced (non-entry) document. See [Resolving Implicit Connections](#resolving-implicit-connections) for more information.
 
 First, the [entry document](#openapi-description-structure) is where parsing begins. It defines the `MySecurity` security scheme to be JWT-based, and it defines a Path Item as a reference to a component in another document:
 
@@ -4565,7 +4568,7 @@ paths:
     $ref: 'other#/components/pathItems/Foo'
 ```
 
-This entry document references another document, `other`, without using a file extension.  This gives the client the flexibility to choose an acceptable format on a resource-by-resource basis, assuming both representations are available:
+This entry document references another document, `other`, without using a file extension. This gives the client the flexibility to choose an acceptable format on a resource-by-resource basis, assuming both representations are available:
 
 ```HTTP
 GET /api/description/other HTTP/1.1