Skip to content

Be more clear about format support (3.1.1) #3726

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Apr 25, 2024
Merged

Be more clear about format support (3.1.1) #3726

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
ceadbe1
Be more clear about `format` support
handrews Apr 20, 2024
0f800d5
Link format vocabularies to JSON Schema spec sections
handrews Apr 22, 2024
25d82a1
wording improvements from review
handrews Apr 23, 2024
c48dd1a
More minimal wording regarding "format" validation.
handrews Apr 24, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion versions/3.1.1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -146,7 +146,8 @@ Data types in the OAS are based on the types supported by the [JSON Schema Speci
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 2020-12.

<a name="dataTypeFormat"></a>As defined by the [JSON Schema Validation vocabulary](https://tools.ietf.org/html/draft-bhutton-json-schema-validation-00#section-7.3), data types can have an optional modifier property: `format`.
<a name="dataTypeFormat"></a>As defined by the [JSON Schema Validation specification](https://tools.ietf.org/html/draft-bhutton-json-schema-validation-00#section-7.3), data types can have an optional modifier property: `format`. Note that by default, JSON Schema draft 2020-12 validators _do not_ validate `format`, but instead treat it as an annotation. Support for `format` validation, either in best-effort form with the [default `format-annotation` vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-7.2.1), or with the less-commonly-implemented [`format-assertion` vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-7.2.2), varies among JSON Schema implementations.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<a name="dataTypeFormat"></a>As defined by the [JSON Schema Validation specification](https://tools.ietf.org/html/draft-bhutton-json-schema-validation-00#section-7.3), data types can have an optional modifier property: `format`. Note that by default, JSON Schema draft 2020-12 validators _do not_ validate `format`, but instead treat it as an annotation. Support for `format` validation, either in best-effort form with the [default `format-annotation` vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-7.2.1), or with the less-commonly-implemented [`format-assertion` vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-7.2.2), varies among JSON Schema implementations.
<a name="dataTypeFormat"></a>As defined by the [JSON Schema Validation specification](https://tools.ietf.org/html/draft-bhutton-json-schema-validation-00#section-7.3), data types can have an optional modifier property: `format`. Note that by default, JSON Schema draft 2020-12 validators _do not_ validate `format`, but instead treat it as an annotation. Support for `format` validation, either in best-effort form with the [default `format-annotation` vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-7.2.1), or with the less-commonly-implemented [`format-assertion` vocabulary](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-7.2.2), varies among JSON Schema validator implementations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand the JSON Schema specification correctly, the OpenAPI 3.1 schema declares that it is based on https://json-schema.org/draft/2020-12/schema, which declares that format is just an annotation and not an assertion and can be ignored by validators:

    "https://json-schema.org/draft/2020-12/vocab/format-annotation": true,

So ignoring format is correct behavior for validators and explicitly allowed by how OpenAPI 3.1 uses JSON Schema.

As long as we do not change that part of OpenAPI 3.1, calling out that format is more of a comment and less of an instruction will also remain valid.

@handrews is my interpretation correct?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ralfhandl Yes, that's correct. Perhaps it might be better to change the wording a bit as the wording I have here makes it sound like it's a tooling problem. It's actually that the spec changed between draft-04 and 2020-12 regarding how format is expected to be handled. Although it's slightly more complicated as there are two ways to get format validation: one is enabling a "best effort" validation mode that matches what has been historically implemented for the keyword, which can be done with the format-annotation vocabulary, but is done by the person running validation and can't be controlled by the schema or meta-schema. The other is the strict validation mode of the format-assertion vocabulary, which is not widely implemented in practice and requires making a meta-schema change that most people don't seem inclined to do (or support).

@mikekistler I think some wording changes here would make it more clear that this is not a transient thing, but the expected result of the specification.


OAS defines additional formats to provide fine detail for primitive data types.

The formats defined by the OAS are:
Expand Down