Use full schema (schema-base.yaml) for coverage #4701
Conversation
But don't count standard JSON Schema keywords.
There needs to be a local `$dynamicAnchor`, but it is never actually evaluated.
| }); | ||
|
|
||
| defineVocabulary( | ||
| "https://spec.openapis.org/oas/3.1/vocab/base", |
There was a problem hiding this comment.
This apparently needs to be parameterized with the OpenAPI version of the branch it is running on, because the script fails if run as-is on the v3.2-dev branch.
No spontanous idea on how to reliably do that, other than parsing dialect.yaml.
There was a problem hiding this comment.
@ralfhandl I was just going to modify the line on the 3.2 port
There was a problem hiding this comment.
Which would end up in main (and then dev and v3.1-dev) after the release unless someone fiddles with the v3.2.0-rel branch.
Automatically detecting the release seems preferable.
There was a problem hiding this comment.
@ralfhandl Which is fine but let's fix it separately. I do not have the mental bandwidth today for that, and want to get the XML PR merged so I can unblock further work that depends on it.
There was a problem hiding this comment.
This apparently needs to be parameterized with the OpenAPI version of the branch it is running on
I didn't realize you were versioning the vocabulary now. So, ignore what I said about not needing defineVocabulary, but you still shouldn't need to implement the keywords as long as you use the correct import.
|
@handrews Thanks for taking this up, I was wondering how to test our Schema Object extensions without having to cover all standard JSON Schema keywords. |
| addKeyword({ | ||
| id: "https://spec.openapis.org/oas/schema/vocab/keyword/discriminator", | ||
| interpret: (discriminator, instance, context) => { | ||
| return true; | ||
| }, | ||
| /* discriminator is not exactly an annotation, but it's not allowed | ||
| * to change the validation outcome (hence returing true from interopret()) | ||
| * and for our purposes of testing, this is sufficient. | ||
| */ | ||
| annotation: (discriminator) => { | ||
| return discriminator; | ||
| }, | ||
| }); | ||
|
|
||
| addKeyword({ | ||
| id: "https://spec.openapis.org/oas/schema/vocab/keyword/example", | ||
| interpret: (example, instance, context) => { | ||
| return true; | ||
| }, | ||
| annotation: (example) => { | ||
| return example; | ||
| }, | ||
| }); | ||
|
|
||
| addKeyword({ | ||
| id: "https://spec.openapis.org/oas/schema/vocab/keyword/externalDocs", | ||
| interpret: (externalDocs, instance, context) => { | ||
| return true; | ||
| }, | ||
| annotation: (externalDocs) => { | ||
| return externalDocs; | ||
| }, | ||
| }); | ||
|
|
||
| addKeyword({ | ||
| id: "https://spec.openapis.org/oas/schema/vocab/keyword/xml", | ||
| interpret: (xml, instance, context) => { | ||
| return true; | ||
| }, | ||
| annotation: (xml) => { | ||
| return xml; | ||
| }, | ||
| }); |
There was a problem hiding this comment.
These seem to be unnecessary, commenting them out does not change the test result.
There was a problem hiding this comment.
@ralfhandl they make the vocabulary be handled correctly if we want to further utilize those keywords in tests. I prefer to set up the vocabulary correctly rather than stub it out just because we're not using it right now.
There was a problem hiding this comment.
Would checks of the keyword's correct use go into the interpret stubs?
There was a problem hiding this comment.
@ralfhandl they're not stubs. Annotations are always valid, returning true is correct.
There was a problem hiding this comment.
At least I think. That was as far as I got in the library's documentation. It's at least closer to correct than it was, and we can work on it more later.
There was a problem hiding this comment.
These seem to be unnecessary, commenting them out does not change the test result.
It works because the vocabulary is set as optional. If there is no keyword implementation, it's treated like an unknown keyword, which is allowed, but not quite the same thing.
These keyword implementations are already provided, so you shouldn't need to define them here. Instead of importing @hyperjump/json-schema/draft-2020-12, use @hyperjump/json-schema/openapi-3-1. Then the keywords and vocabulary definitions will be loaded and you can skip this. However, you still need to register the local schemas because you're testing the local schemas, not the ones included with the @hyperjump/json-schema.
Co-authored-by: Ralf Handl <[email protected]>
Co-authored-by: Ralf Handl <[email protected]>
|
@ralfhandl I have fixed the blocking things, I think. I realize the Among other things, it's extremely awkward that this script has to start on |
Co-authored-by: Ralf Handl <[email protected]>
|
@ralfhandl merged your latest suggestion, thanks. |
But don't count standard JSON Schema keywords.
We were not actually using the correct schema for our testing, which meant that we were not covering the Schema Object at all.