-
-
Notifications
You must be signed in to change notification settings - Fork 209
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.
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
contentSchema
tests inadequate
#609
Comments
Sounds reasonable to me. |
Actually I'm starting to question whether this needs to be in the requires test set (could be in optional). The spec (Section 8.2) says:
This effectively means that |
Right, I thought you knew that part :) and that the point was that if an implementation for some reason does do something with contentSchema (incorrectly) that it would still pass this test because it might consider the thing to be a string. |
In draft 2019-09 onwards the In draft-07, The test schema and instance are correct, although a |
But given that the requirement is "MUST NOT perform these operations by default," doesn't that mean that we need to test that the implementation isn't evaluating the schema? I'm not sure that this test does that. I think we'd need content that doesn't pass the |
I'm not sure who's responding to who with what from the last two comments even though you quoted me :D I was trying to say the same thing Henry said though, which is there's no test we can write with a result other than Is that different than your understanding, sounds like no now right? Basically yeah if you want to strengthen the test sure go for it, as you say, the way to do so is to have content that doesn't pass the contentSchema, and then assert that it passes anyhow.. |
When I created the issue, I had initially misinterpreted the requirement thinking that I had to decode and validate the content (because the test has content that is valid), and the Reading the spec more recently, I realize that I am explicitly NOT to decode and validate the content. But the content is valid against the If we change the content to encode (Sorry the direction of this issue changed after I educated myself and thought about it a bit.) |
Right I think we're all saying the same thing now? Agree, change the schema, change the instance, whichever. |
Yes!
Such a test would be great in optional/, where the keywords were treated as assertions as well as annotations. |
I noted in the PR that there's already a test that does this what I'm looking for. I added the |
Unfortunately the assertion behavior is only optional in draft-07 and earlier, which do not include |
I'm not sure that the
contentSchema
are fully testing what they intend to.For example:
Schema:
Instance
"eyJmb28iOiAiYmFyIn0K"
(instance decodes to
{"foo": "bar"}
)The subschema at
/contentSchema
(based on the keywords present) seems to be expecting an object. However, if an implementation ignores the encoding and media type and just validates this as a string, the test incorrectly passes. (Mine does this.)I suggest we need to add a
"type": "object"
restriction to the subschema to ensure that it requires an object and doesn't just validate the base64 string.The text was updated successfully, but these errors were encountered: