2.2.0 #176
Merged
2.2.0 #176
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`BINARY` is an alias of `ASCII_8BIT` and I think the name makes things more clear (particularly for the `binary` format). See: https://bugs.ruby-lang.org/issues/18576
And use `String#b` to get duped binary string.
Noticed this issue when looking into: #166
`custom_keywords` isn't passed to nested schemas (similar to formats, hooks, and ref resolution) so they need to be read from the root schema instead. Noticed this while looking into: #166
Never meant to expose `Location` hashes. Looks like this was an oversight when they were introduced. Noticed this while looking into: #166
This uses all adjacent (same schema) results to calculate unevaluated
keys/items, whether the keywords validated successfully or not.
Previously, it only considered valid results, which causes confusing
errors:
```ruby
schemer = JSONSchemer.schema({
'properties' => {
'x' => {
'type' => 'integer'
}
},
'unevaluatedProperties' => false
})
schemer.validate({ 'x' => 'invalid' }).map { _1.fetch_values('schema_pointer', 'error') }
# =>
# [["/properties/x", "value at `/x` is not an integer"],
# ["/unevaluatedProperties", "value at `/x` does not match schema"]]
```
The overall validation result shouldn't be affected, since the only
additional keywords that it considers are failed ones (meaning the
entire schema fails regardless of the unevaluated keys/items).
Duplicate/unhelpful error messages are reduced, though, which is the
main reason for making this change.
Generally, this interpretation doesn't align with my reading of the
spec, but there's been a lot of [discussion][0] around it and I think it
makes sense from a user experience perspective. Hopefully it will get
clarified in a future draft.
Closes: #157
Related:
- json-schema-org/json-schema-spec#1172
- https://github.com/orgs/json-schema-org/discussions/67
- https://github.com/orgs/json-schema-org/discussions/57
- https://github.com/json-schema-org/json-schema-spec/blob/2cb7c7447f9b795c9940710bf0eda966a92c937f/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md
[0]: json-schema-org/json-schema-spec#1172
And change `additionalProperties` message to be consistent.
This allows default properties to be inserted using symbol keys. I didn't think about this when adding symbol key support everywhere. I don't love overloading `insert_property_defaults` like this, but it seems slightly better than adding another option (or `property_default_resolver: :symbol` or whatever). Addresses: #166
Parsing the whole schema can lead to errors for malformed keyword
values, eg:
```
>> JSONSchemer.schema({ 'properties' => '' })
/Users/dharsha/repos/json_schemer/lib/json_schemer/draft202012/vocab/applicator.rb:224:in `parse': undefined method `each_with_object' for an instance of String (NoMethodError)
value.each_with_object({}) do |(property, subschema), out|
^^^^^^^^^^^^^^^^^
from /Users/dharsha/repos/json_schemer/lib/json_schemer/keyword.rb:14:in `initialize'
```
Instead, this creates a minimal parseable schema with just the `$schema`
value, if it's present and a string. That way the meta schema can be
determined as usual and then used to validate the provided schema.
Addresses: #167
This aligns the schema generation (`JSONSchemer.schema`) and schema validation (`valid_schema?` and `validate_schema`) method interfaces, so that they all take the same schema object types.
The default meta schemas don't inherit the provided options, because they're initialized with their own options and cached. To override validation-time options, they need to be passed directly to the validation methods. This is a little brittle because the validation-time options are listed separately to pull them out of the options hash. I couldn't think of a better way to split the initialization and validation options.
This resolves any `ref_schema` keywords (`$ref`, `$dynamicRef`,
`$recursiveRef`) when looking for `default` keywords for
`insert_property_defaults`. It follows the keyword order defined in the
vocabulary (`$ref` first, then `$dynamicRef`/`$recursiveRef` depending
on the meta schema) and searches depth-first (ie, follows a `$ref` chain
until a leaf schema before moving on to a sibling `$dynamicRef`). The
first `default` keyword found is used, meaning a `$ref` default can be
overwritten by the including schema, eg:
```json
{
"properties": {
"example": {
"$ref": "#/$defs/ref",
"default": "override!"
}
},
"$defs": {
"ref": {
"default": "overridden"
}
}
}
```
Closes: #173
Don't want to introduce new behavior.
I don't think there's a good reason to change this.
It doesn't make sense in the context of the configuration object.
Match the option names from `JSONSchemer.schema` and `Schema.new`.
I want to introduce this separately and think about using it elsewhere.
This is already handled in `Schema#initialize`.
`meta_schema` is a little wrong at this point because `JSONSchemer.schema` processes strings and the configuration object only allows `Schema` objects.
This allows string values in `Configuration#meta_schema` in order to be consistent with `JSONSchemer.schema`. There's a slight behavior change in that unknown `meta_schema` values will be passed to the provided ref resolver. I think this is good because it better matches the behavior of the `$schema` keyword. `UnsupportedMetaSchema` is gone; `UnknownRef` will be raised instead. It was necessary to add `$schema` in `test_schema_validation_parse_error_with_custom_meta_schema` because `ref_resolver` schemas inherit the provided `meta_schema`, which meant the custom meta schema was using itself as a meta schema when provided as a string.
This makes it easy to pass in an existing configuration object and override multiple arguments without modifying the global configuration. It also provides a simpler way to pass configuration to subschemas (and ref schemas). `base_uri`, `meta_schema`, `ref_resolver`, and `regexp_resolver` still need to be passed separately because they're parsed and modified in the schema object (not reflected in the configuration object).
simplecov is complaining about this now for some reason. Previously, `errors_test.rb` wasn't showing up at all on the coverage report...
This makes `Configuration` a struct and overrides its `initialize` method to provide defaults. It simplifies things a bit and allows passing options during initialization using keyword arguments.
Make sure the options are actually getting applied properly.
Global configuration options
Follow refs when finding default property values
bf0360f4 add $recursiveAnchor to 2019-09 meta-schemas
0519d1f0 add $dynamicAnchor to meta-schemas
b41167c7 Merge pull request #714 from json-schema-org/more-not
4221a55a Add tests for not: {} schemas for all values.
c499d1d2 Merge pull request #713 from spacether/patch-1
24a471bd Update README.md
544f7c3d Merge pull request #712 from otto-ifak/main
9dad3ebe Add tests for enum with array of bool
589a0858 Merge pull request #706 from marksparkza/unevaluated-before-ref
64d5cab9 Merge pull request #710 from spacether/patch-1
418cdbd6 Removes idea folder
e0a9e066 Updates all other tests to mention grapheme/graphemes
217bf81b Merge pull request #701 from json-schema-org/ether/dynamicRef-boolean
7a3d06d7 I remove a test that doesn't make sense.
e8bf453d Move tests with ids in non-schemas to optional
69136952 Update minLength.json
d545be21 Fix duplidate identifiers in recently added tests
4e9640c8 test when $dynamicRef references a boolean schema
3dab98ca Merge pull request #705 from json-schema-org/gregsdennis/remove-contains-objects-tests
1d3aa495 remove more maxContains
4a2c61e8 Test unevaluatedItems|Properties before $ref
ec553d76 contains no longer applies to objects
0433a2bf Merge pull request #704 from big-andy-coates/clarify-format-requirements
c685195f Merge pull request #703 from big-andy-coates/link-to-creek-validator-comprison-site
a46174b0 Add more detail around test runner requirements for `format` tests
bb1de8a9 The site linked to is a data-driven functional and performance benchmark of JVM based validator implementations.
git-subtree-dir: JSON-Schema-Test-Suite
git-subtree-split: bf0360f4b7c51b8f968aabe7f3f49e12b120fc85
Forgot to add this as part of: #170
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Features:
See CHANGELOG.md and individual commits for more details.
Closes: