Better example of ignoring a readOnly constraint

versions/3.1.1.md

@@ -2775,7 +2775,9 @@ 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]].
+Fields that are both required and read-only are an example of when it is beneficial to ignore a `readOnly: true` constraint in a PUT, particularly if the value has not been changed.
+This allows correctly requiring the field on a GET and still using the same representation and schema with PUT.
+Even when read-only fields are not required, stripping them is burdensome for clients, particularly when the JSON data is complex or deeply nested.
 
 Note that the behavior of `readOnly` in particular differs from that specified by version 3.0 of this specification.