Add support for Draft 2020-12 #116
Comments
davishmcclurg
added a commit
that referenced
this issue
Jul 9, 2023
Lots of stuff here. The main goal is to support the newer JSON Schema drafts (2020-12 and 2019-09) including output formats and annotations. The biggest change is pulling individual keywords into separate classes which contain parsing and validation logic. All drafts now use the same `Schema` class with the new "vocabularies" concept handling behavior differences. Each draft has its own meta schema (meta.rb), vocabularies (vocab.rb), and, if necessary, keyword classes (vocab/*.rb). Most keywords are defined in the latest draft with previous drafts removing/adding things from there. Old drafts (4, 6, and 7) only have a single vocabulary because they predate the concept. `Schema` contains some logic but I tried to keep as much as possible in keyword classes. `Schema` and `Keyword` have a similar interface (`value`, `keyword`, `parent`, etc) and share some code using the `Output` module because it didn't feel quite right to have `Schema` be a subclass of `Keyword`. There are two basic methods for schemas and keywords: `#parse`: parses the provided definition (generates relevant subschemas, side effects, etc). Basically anything that can be done before data validation. `#validate`: iterates through the parsed schema/keywords, validates data, and returns a `Result` object (possibly with nested results). One exception is `Ref`, which doesn't resolve refs at parse time because of a circular dependency when generating meta schemas. Output formats (introduced in 2019-09) are supported via `Result`. I think the only tricky thing there is that nested results are returned as enumerators instead of arrays for performance reasons. This matches the "classic" behavior as well. 2019-09 also introduced "annotations" which are used for some validations (`unevaluatedProperties`, `unevaluatedItems`, etc) and are returned with successful results in a similar format to errors. The "classic" output format drops them to match existing behavior. Notes: - `Location` is used for performance reasons so that JSON pointer resolution can be cached and deferred until output time. - `instance_location` isn't cached between validations because it's possibly unbounded. - `ref_resolver` and `regexp_resolver` are lazily created for performanc reasons. Known breaking changes (so far): - Custom keyword output - `not` and `dependencies` output - Property validation hooks (`before_property_validation` and `after_property_validation`) are now called immediately surrounding `properties` validation. Previously, `before_property_validation` was called before all "object" validations (`dependencies`, `patternProperties`, `additionalProperties`, etc) and `after_property_validation` was called after. Related: - #27 - #44 - #116
davishmcclurg
added a commit
that referenced
this issue
Jul 23, 2023
Lots of stuff here. The main goal is to support the newer JSON Schema drafts (2020-12 and 2019-09) including output formats and annotations. The biggest change is pulling individual keywords into separate classes which contain parsing and validation logic. All drafts now use the same `Schema` class with the new "vocabularies" concept handling behavior differences. Each draft has its own meta schema (meta.rb), vocabularies (vocab.rb), and, if necessary, keyword classes (vocab/*.rb). Most keywords are defined in the latest draft with previous drafts removing/adding things from there. Old drafts (4, 6, and 7) only have a single vocabulary because they predate the concept. `Schema` contains some logic but I tried to keep as much as possible in keyword classes. `Schema` and `Keyword` have a similar interface (`value`, `keyword`, `parent`, etc) and share some code using the `Output` module because it didn't feel quite right to have `Schema` be a subclass of `Keyword`. There are two basic methods for schemas and keywords: `#parse`: parses the provided definition (generates relevant subschemas, side effects, etc). Basically anything that can be done before data validation. `#validate`: iterates through the parsed schema/keywords, validates data, and returns a `Result` object (possibly with nested results). One exception is `Ref`, which doesn't resolve refs at parse time because of a circular dependency when generating meta schemas. Output formats (introduced in 2019-09) are supported via `Result`. I think the only tricky thing there is that nested results are returned as enumerators instead of arrays for performance reasons. This matches the "classic" behavior as well. 2019-09 also introduced "annotations" which are used for some validations (`unevaluatedProperties`, `unevaluatedItems`, etc) and are returned with successful results in a similar format to errors. The "classic" output format drops them to match existing behavior. Notes: - `Location` is used for performance reasons so that JSON pointer resolution can be cached and deferred until output time. - `instance_location` isn't cached between validations because it's possibly unbounded. - `ref_resolver` and `regexp_resolver` are lazily created for performanc reasons. Known breaking changes (so far): - Custom keyword output - `not` and `dependencies` output - Property validation hooks (`before_property_validation` and `after_property_validation`) are now called immediately surrounding `properties` validation. Previously, `before_property_validation` was called before all "object" validations (`dependencies`, `patternProperties`, `additionalProperties`, etc) and `after_property_validation` was called after. Related: - #27 - #44 - #116
davishmcclurg
added a commit
that referenced
this issue
Jul 27, 2023
Lots of stuff here. The main goal is to support the newer JSON Schema drafts (2020-12 and 2019-09) including output formats and annotations. The biggest change is pulling individual keywords into separate classes which contain parsing and validation logic. All drafts now use the same `Schema` class with the new "vocabularies" concept handling behavior differences. Each draft has its own meta schema (meta.rb), vocabularies (vocab.rb), and, if necessary, keyword classes (vocab/*.rb). Most keywords are defined in the latest draft with previous drafts removing/adding things from there. Old drafts (4, 6, and 7) only have a single vocabulary because they predate the concept. `Schema` contains some logic but I tried to keep as much as possible in keyword classes. `Schema` and `Keyword` have a similar interface (`value`, `keyword`, `parent`, etc) and share some code using the `Output` module because it didn't feel quite right to have `Schema` be a subclass of `Keyword`. There are two basic methods for schemas and keywords: `#parse`: parses the provided definition (generates relevant subschemas, side effects, etc). Basically anything that can be done before data validation. `#validate`: iterates through the parsed schema/keywords, validates data, and returns a `Result` object (possibly with nested results). One exception is `Ref`, which doesn't resolve refs at parse time because of a circular dependency when generating meta schemas. Output formats (introduced in 2019-09) are supported via `Result`. I think the only tricky thing there is that nested results are returned as enumerators instead of arrays for performance reasons. This matches the "classic" behavior as well. 2019-09 also introduced "annotations" which are used for some validations (`unevaluatedProperties`, `unevaluatedItems`, etc) and are returned with successful results in a similar format to errors. The "classic" output format drops them to match existing behavior. Notes: - `Location` is used for performance reasons so that JSON pointer resolution can be cached and deferred until output time. - `instance_location` isn't cached between validations because it's possibly unbounded. - `ref_resolver` and `regexp_resolver` are lazily created for performanc reasons. Known breaking changes (so far): - Custom keyword output - `not` and `dependencies` output - Property validation hooks (`before_property_validation` and `after_property_validation`) are now called immediately surrounding `properties` validation. Previously, `before_property_validation` was called before all "object" validations (`dependencies`, `patternProperties`, `additionalProperties`, etc) and `after_property_validation` was called after. Related: - #27 - #44 - #116
davishmcclurg
added a commit
that referenced
this issue
Jul 31, 2023
Features: - Draft 2020-12 support - Draft 2019-09 support - Output formats - Annotations - OpenAPI 3.1 schema support - OpenAPI 3.0 schema support - `insert_property_defaults` in conditional subschemas - Error messages - Non-string schema and data keys See individual commits for more details. Closes: - #27 - #44 - #55 - #91 - #94 - #116 - #123
davishmcclurg
added a commit
that referenced
this issue
Aug 1, 2023
Features: - Draft 2020-12 support - Draft 2019-09 support - Output formats - Annotations - OpenAPI 3.1 schema support - OpenAPI 3.0 schema support - `insert_property_defaults` in conditional subschemas - Error messages - Non-string schema and data keys See individual commits for more details. Closes: - #27 - #44 - #55 - #91 - #94 - #116 - #123
Merged
davishmcclurg
added a commit
that referenced
this issue
Aug 19, 2023
Lots of stuff here. The main goal is to support the newer JSON Schema drafts (2020-12 and 2019-09) including output formats and annotations. The biggest change is pulling individual keywords into separate classes which contain parsing and validation logic. All drafts now use the same `Schema` class with the new "vocabularies" concept handling behavior differences. Each draft has its own meta schema (meta.rb), vocabularies (vocab.rb), and, if necessary, keyword classes (vocab/*.rb). Most keywords are defined in the latest draft with previous drafts removing/adding things from there. Old drafts (4, 6, and 7) only have a single vocabulary because they predate the concept. `Schema` contains some logic but I tried to keep as much as possible in keyword classes. `Schema` and `Keyword` have a similar interface (`value`, `keyword`, `parent`, etc) and share some code using the `Output` module because it didn't feel quite right to have `Schema` be a subclass of `Keyword`. There are two basic methods for schemas and keywords: `#parse`: parses the provided definition (generates relevant subschemas, side effects, etc). Basically anything that can be done before data validation. `#validate`: iterates through the parsed schema/keywords, validates data, and returns a `Result` object (possibly with nested results). One exception is `Ref`, which doesn't resolve refs at parse time because of a circular dependency when generating meta schemas. Output formats (introduced in 2019-09) are supported via `Result`. I think the only tricky thing there is that nested results are returned as enumerators instead of arrays for performance reasons. This matches the "classic" behavior as well. 2019-09 also introduced "annotations" which are used for some validations (`unevaluatedProperties`, `unevaluatedItems`, etc) and are returned with successful results in a similar format to errors. The "classic" output format drops them to match existing behavior. Notes: - `Location` is used for performance reasons so that JSON pointer resolution can be cached and deferred until output time. - `instance_location` isn't cached between validations because it's possibly unbounded. - `ref_resolver` and `regexp_resolver` are lazily created for performanc reasons. Known breaking changes (so far): - Custom keyword output - `not` and `dependencies` output - Property validation hooks (`before_property_validation` and `after_property_validation`) are now called immediately surrounding `properties` validation. Previously, `before_property_validation` was called before all "object" validations (`dependencies`, `patternProperties`, `additionalProperties`, etc) and `after_property_validation` was called after. Related: - #27 - #44 - #116
davishmcclurg
added a commit
that referenced
this issue
Aug 19, 2023
Features: - Draft 2020-12 support - Draft 2019-09 support - Output formats - Annotations - OpenAPI 3.1 schema support - OpenAPI 3.0 schema support - `insert_property_defaults` in conditional subschemas - Error messages - Non-string schema and data keys - Schema bundling See individual commits for more details. Closes: - #27 - #44 - #55 - #91 - #94 - #116 - #123 - #136
davishmcclurg
added a commit
that referenced
this issue
Aug 20, 2023
Features: - Draft 2020-12 support - Draft 2019-09 support - Output formats - Annotations - OpenAPI 3.1 schema support - OpenAPI 3.0 schema support - `insert_property_defaults` in conditional subschemas - Error messages - Non-string schema and data keys - Schema bundling See individual commits for more details. Closes: - #27 - #44 - #55 - #91 - #94 - #116 - #123 - #136
|
Released in 2.0.0. Draft 2020-12 is now the default draft. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Specification
http://json-schema.org/specification-links.html#2020-12
Identifier
Reference (based on this):
https://json-schema.org/understanding-json-schema/reference/schema.html#id4
The text was updated successfully, but these errors were encountered: