Skip to content

Commit e4cf7a4

Browse files
committed
Add note about RFC6570 type conversions
The spec doesn't address it, but implementations often have their own rules.
1 parent 1ce8613 commit e4cf7a4

File tree

1 file changed

+3
-0
lines changed

1 file changed

+3
-0
lines changed

versions/3.0.4.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3524,6 +3524,9 @@ Two cases do offer standards-based guidance:
35243524
* [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)
35253525
* [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
35263526

3527+
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.
3528+
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.
3529+
35273530
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.
35283531
The resulting strings would not require any further type conversion.
35293532

0 commit comments

Comments
 (0)