Skip to content

Commit

Permalink
Add note about RFC6570 type conversions
Browse files Browse the repository at this point in the history
The spec doesn't address it, but implementations often have
their own rules.
  • Loading branch information
handrews committed May 25, 2024
1 parent 1ce8613 commit e4cf7a4
Showing 1 changed file with 3 additions and 0 deletions.
3 changes: 3 additions & 0 deletions versions/3.0.4.md
Original file line number Diff line number Diff line change
Expand Up @@ -3524,6 +3524,9 @@ Two cases do offer standards-based guidance:
* [RFC3987 §3.1](https://datatracker.ietf.org/doc/html/rfc3987#section-3.1) provides guidance for converting non-Unicode strings to UTF-8, particularly in the context of URIs (and by extension, the form media types which use the same encoding rules)
* [RFC6570 §2.3](https://www.rfc-editor.org/rfc/rfc6570#section-2.3) specifies which values, including but not limited to `null`, are considered _undefined_ and therefore treated specially in the expansion process when serializing based on that specification

Implementations of RFC6570 often have their own conventions for converting non-string values, but these are implementation-specific and not defined by the RFC itself.
This is one reason for the OpenAPI Specification to leave these conversions as implementation-defined: It allows using RFC6570 implementations regardless of how they choose to perform the conversions.

To control the serialization of numbers, booleans, and `null` (or other values RFC6570 deems to be undefined) more precisely, schemas can be defined as `type: string` and constrained using `pattern`, `enum`, `format`, and other keywords to communicate how applications must pre-convert their data prior to schema validation.
The resulting strings would not require any further type conversion.

Expand Down

0 comments on commit e4cf7a4

Please sign in to comment.