Output formatting #27
Comments
|
Very interested in this feature! Just a heads up to let you know people are looking forward to using this. |
|
@jfeltesse-mdsol good to know! Is the current output not working for you? I'm curious to hear how the spec's output format will be more useful. |
|
It's about future proofing. Related to this we have other languages in use at my company and while making a cross-language shared wrapper library is probably not worth it, reviewing and maintaining other languages is going to be much easier if everyone processes the same kind of data structures, as standardized by the spec. |
|
@davishmcclurg This feature is also very interesting for me! |
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. Use JSONSchemer.schema(schema).validate(data, :output_format => 'basic') |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Implement the JSON Schema spec's "basic" output format: json-schema-org/json-schema-spec#679
The text was updated successfully, but these errors were encountered: