Skip to content
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

Jump to bottom

Add support for Draft 2020-12 #116

Closed
heynan0 opened this issue Sep 9, 2022 · 1 comment
Closed

Add support for Draft 2020-12 #116

heynan0 opened this issue Sep 9, 2022 · 1 comment

Comments

@heynan0
Copy link

heynan0 commented Sep 9, 2022 •
edited
Loading

Specification

http://json-schema.org/specification-links.html#2020-12

Identifier

{ "$schema": "https://json-schema.org/draft/2020-12/schema" }

Reference (based on this):

The identifier for Draft 2019-09 is https://json-schema.org/draft/2019-09/schema.

https://json-schema.org/understanding-json-schema/reference/schema.html#id4
@heynan0 heynan0 changed the title Add support for Draft 2022-12 Add support for Draft 2020-12 Sep 9, 2022
davishmcclurg added a commit that referenced this issue Jul 9, 2023
@davishmcclurg
Big rewrite
1b75f49 
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
@davishmcclurg
Big rewrite
3311ca4 
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
@davishmcclurg
Big rewrite
6de2a04 
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
@davishmcclurg
2.0.0
5d8f3c5 
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
@davishmcclurg
2.0.0
42b50b0 
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 davishmcclurg mentioned this issue Aug 1, 2023
Merged
davishmcclurg added a commit that referenced this issue Aug 19, 2023
@davishmcclurg
Big rewrite
2c09eb9 
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
@davishmcclurg
2.0.0
6f8e47e 
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
@davishmcclurg
2.0.0
db29755 
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
Copy link
Owner

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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@davishmcclurg @heynan0