2.1.0 #156
Merged
2.1.0 #156
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
https://spec.openapis.org/oas/v3.1.0#discriminator-object > The expectation now is that a property with name petType MUST be present in the response payload It's a little unclear because the specification examples mostly specify the `propertyName` property under `required` as well, which seems redundant. It's probably safer this way, though, and the spec says "MUST" so we must.
`resolve_ref` needs to be called on the root schema because that's where
all the `resources` are stored.
The behavior here is kind of confusing because the ref is resolved just
like the `$ref` keyword would be in the schema, so it's dependent on the
schema's base URI. That means for a subschema `ref('#')` doesn't
necessarily resolve to itself (ie, if the subschema doesn't have `$id`).
This addresses an issue where `resolve_ref` gets called for refs that
aren't explicitly listed in `anyOf` or `oneOf`. The [specification][0]
says:
> In both the oneOf and anyOf use cases, all possible schemas MUST be listed explicitly.
So for anyOf/oneOf discriminators, this uses the provided refs to build
a mapping of property values to schema objects for lookup during
validation. Explicit mappings are found by schema name or full ref to
support:
```yaml
discriminator:
propertyName: petType
mapping:
cat: Cat
dog: '#/components/schemas/Dog'
```
Impicit mappings are only created for refs under `#/components/schemas/`
and are overridden by any explicit mappings that point to the same
schema.
`allOf` discriminators still resolve refs because there isn't an
explicit list of allowed refs. Switched to `Schema#ref` now that it
calls `root.resolve_ref` itself.
`FIXED_FIELD_REGEX` comes from the [spec][1]:
> All the fixed fields declared above are objects that MUST use keys that match the regular expression: ^[a-zA-Z0-9\.\-_]+$.
It's used in all cases to make sure schemas are only looked up by name
if the property value is a valid schema name.
Closes: #144
[0]: https://spec.openapis.org/oas/v3.1.0#discriminator-object
[1]: https://spec.openapis.org/oas/v3.1.0#components-object
It looks like they changed these to redirects: ``` % curl 'http://json-schema.org/draft-07/schema#' -I HTTP/1.1 301 Moved Permanently Date: Fri, 13 Oct 2023 21:29:36 GMT Connection: keep-alive Cache-Control: max-age=3600 Expires: Fri, 13 Oct 2023 22:29:36 GMT Location: https://json-schema.org/draft-07/schema Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=4Y8wC8Dh8QkEwNGjF%2FFKlVkfEiFB1hOv3XOnfGJPcIKfna%2FrsYwkURU1zkA5HAgGXRsXFZ3EUCjMOnZiLkXNjDJQ3zvaJJvsS43oAUhIM0uu2CFTfa4QHGRWI%2FpXcULLCqXrAzuUu%2FdG3RU0tFU%3D"}],"group":"cf-nel","max_age":604800} NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800} Vary: Accept-Encoding CF-Cache-Status: DYNAMIC Server: cloudflare CF-RAY: 815aadd5892dcf05-SJC ``` Seems wrong to me, but idk. Added a test helper to resolve redirects when fetching things.
In drafts 7 and earlier, all keywords except `definitions` are ignored when `$ref` is present. This includes `$id`, which means refs are resolved using the schema's inherited base URI (default or parent). Currently, when `$id` is present, the inherited base URI isn't being registered as a ref resolution resource (with `ID_KEYWORD_CLASS.new`), which causes JSON pointer ref resolution to fail. The fix here is to add the exclusive ref case for the `ID_KEYWORD_CLASS.new` call. The rest of the changes are from if/else cleanup. Closes: #146
Limit anyOf/oneOf discriminator to listed refs
still ugly tho
And use the same code paths as custom formats. This fixes an issue where older drafts have access to formats that aren't in the specification.
This introduces two ways of defining custom error messages: the `x-error` keyword and I18n translations. `x-error` is a json_schemer-specific schema keyword that allows overriding error messsages for a schema. It can either be a string, which overrides errors for all keywords (and for the schema itself), or a hash of keyword-specific messages. Interpolation of some values is supported using `gsub` because `sprintf` logs annoying warnings if all arguments aren't present in the string. I18n translations are enabled when the `i18n` gem is loaded and a `json_schemer` translation key exists. Translation keys are based on schema $id, keyword location, meta-schema $id, and keyword. The lookup is ordered from most specific to least specific so that overrides can be applied as necessary. Notes: - Both `x-error` and I18n use special catch-all (`*`) and schema (`^`) "keywords" to support fallbacks and schema-level errors, respectively. - `x-error` uses the `x-` prefix to match the future spec for unknown keywords: https://github.com/orgs/json-schema-org/discussions/329 - The I18n check to enable translations is cached forever because I18n is slow and I didn't want it to hurt performance when it's not used. - I18n uses the ASCII unit separator (\x1F) because the `.` default doesn't work well with absolute URIs ($id and $schema). - I moved `CLASSIC_ERROR_TYPES` out of `JSONSchemer::Result` because that's actually where it's being defined. The `Struct.new` block scope doesn't hold constants like a class. Closes: #143
…pointer Use default base URI for exclusive refs
These keys make it possible to determine how error messages were generated. #149 (comment)
This shouldn't've been removed in: ccffac7 I was under the impression that it would be provided by draft4 since that's openapi30's meta schema, but it's not in that spec. OpenAPI 3.0 formats listed here: https://spec.openapis.org/oas/v3.0.3#data-types @ahx noticed this here: #149 (comment)
This exposes hooks for the `contentEncoding` and `contentMediaType` keywords, similar to the existing custom formats behavior. The provided callables must return a tuple comprised of a validation boolean and annotation of any type. The validation boolean is ignored in draft 2019-09 and 2020-12, because the [specification][0] says: > They do not function as validation assertions; a malformed string-encoded document MUST NOT cause the containing instance to be considered invalid. Drafts 7 and earlier will return a validation error based on the validation boolean. From the [specification][1]: > Implementations MAY support the "contentMediaType" and "contentEncoding" keywords as validation assertions. All drafts forward the returned annotation as an annotation in the overall result. I don't love the API here, since it requires returning an array even when it's ignored in the latest drafts, but I couldn't come up with anything better. Closes: #137 [0]: https://json-schema.org/draft/2020-12/json-schema-validation#section-8.1 [1]: https://json-schema.org/draft-07/draft-handrews-json-schema-validation-01#rfc.section.8.2
This behavior has been around but undocumented for a while. I'm adding this now because it's similar to custom content encodings and media types. Related: #137
[RFC 3339][0] is not very clear about what separator characters are allowed. It just lists "space" as an example: > NOTE: ISO 8601 defines date and time separated by "T". > Applications using this syntax may choose, for the sake of > readability, to specify a full-date and full-time separated by > (say) a space character. Ruby's [`DateTime.rfc3339`][1] allows `T`, `t`, and `\s`, so I'm going with that. This should only affect the edge case tests since everything else is delegated to `DateTime.rfc3339`. There are a bunch of tests that were generated here: https://ijmacd.github.io/rfc3339-iso8601/ Thanks to @pboling for pointing me to it in: #153 The RFC 3339 examples include some that use an underscore as the date-time separator, which I decided to ignore because it seems arbitrary to allow random characters and Ruby doesn't support it. [0]: https://datatracker.ietf.org/doc/html/rfc3339#section-5.6 [1]: https://github.com/ruby/ruby/blob/d3ea9070bbbf04749e5fcd8339d71a9e73a86cfb/ext/date/date_parse.c#L2613
Support custom content encodings and media types
Support custom error messages
|
Take a look at this issue before merging #157 |
d38ddd54 Merge pull request #696 from jdesrosiers/unevaluated-dynamicref 5d0c05fa Fix copy/paste error 95fe6ca2 Merge pull request #694 from json-schema-org/heterogeneous-additionalItems 9c88a0be Merge pull request #697 from json-schema-org/gregsdennis/add-ref-into-known-nonapplicator 49222046 Add unevaluted with dynamic ref tests to draft-next 8ba1c90d Update unevaluted with dynamic ref to be more likely to catch errors fea2cf19 add tests for 2019 and 2020 6695ca38 add optional tests for `$ref`ing into known non-applicator keywords 2834c630 Add tests for unevaluated with dynamic reference cda4281c Merge pull request #695 from json-schema-org/ether/clean-up-subSchemas 7b9f45c2 move subSchemas-defs.json to subSchemas.json e41ec0ec remove unused definition files 349c5a82 Merge pull request #692 from json-schema-org/ether/fix-subSchemas-refs 451baca4 Merge pull request #670 from marksparkza/invalid-output-test b8da838a Add tests for heterogeneous arrays with additionalItems 6d7a44b7 fix subschema locations and their $refs a9a1e2e3 Merge pull request #690 from skryukov/add-ipv4-mask-test ba52c48a Merge pull request #689 from skryukov/add-schema-keyword-to-required-tests 69b53add Add a test case for ipv4 with netmask d0c602a7 Add $schema keyword to required tests 20f1f52c Merge pull request #688 from spacether/feat_updates_python_exp_impl b087b3ca Updates implmentation 4ecd01f3 Merge pull request #687 from swaeberle/check-single-label-idn-hostnames 732e7275 test single label IDN hostnames ab3924a6 Merge pull request #685 from swaeberle/check-single-label-hostnames 9265a4fa do not test hostname with leading digit for older drafts 261b52db do not allow starting digits in hostnames for older drafts 9fc231ea test digits in hostnames e9b20158 test plain single label hostnames c8b57093 test valid single label hostnames 299aa7fe Merge pull request #682 from json-schema-org/useless-branch fbb3cac6 Bump the sanity check to use a released version of jsonschema ea0b63c9 Remove invalid output tests git-subtree-dir: JSON-Schema-Test-Suite git-subtree-split: d38ddd543ebc81e5c23ab03d6598c06563c38a17
From json-schema-test-suite update.
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 individual commits for more details.
Closes: