Will this validator reject JSON that has fields not present in the schema?

[Johnlon]

I need strict validation.

I'm assuming such a feature would be a switch in the configuration

[stevehu]

Yes. set additonal property false in your schema.

[Johnlon]

No that is not the right approach in general.
Many articles on that misunderstanding.

For the record..

json-schema-org/json-schema-spec#556

The draft for unevaluatedproperties is interesting, but because that's not in common use and even if it was I don't own the schema so that's why I suggested a cfg flag.

However such strict validation is something we want for test reasons even if a schema doesn't carry these flags.

[stevehu]

@Johnlon I am confused. If you set "additionalProperties": false in your schema, any additional properties that are not defined in the schema will get an error. Is this enough? If not, could you please submit a test case to explain your use case? Thanks.

[Johnlon]

Hi Doesn't work the way you think when you have allof. It falls apart. Only works on flat objects. It's fully explained in the paper.

…

On Tue, 15 Mar 2022, 2:16 am Steve Hu, ***@***.***> wrote: @Johnlon <https://github.com/Johnlon> I am confused. If you set "additionalProperties": false in your schema, any additional properties that are not defined in the schema will get an error. Is this enough? If not, could you please submit a test case to explain your use case? Thanks. — Reply to this email directly, view it on GitHub <#531 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMFGFAICM2UIYALDABDKLU77XIPANCNFSM5QSAUASQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Johnlon]

Its because additionalproperties false does not work the way you are suggesting it does that led to the addition of the "unevaluatedproperties" switch in the draft standard.

One cannot reliably build a validator that spots excess fields in the presence of a schema which includes allof anyof oneof because there is no defined (or even obvious) protocol for how the additionalproperties flag works in that scenariio. Thus the massive discussion.

Also thus my question and the way I posed it, ie that it world have to be a switch out side the oas and on the validator.
And when if unevaluatedproperties was ready then I would still need a way to impose strict validation even on schemata that didn't carry it

[stevehu]

I hear you. When allOf, anyOf and oneOf are involved, things are getting more complicated. I didn't finish my reading on the unevaluated properties and I think it will take some time to be included in the spec. Meanwhile, if you think we can do that with a flag (I am not sure how this can be done), I would be happy to merge the PR. Thanks a lot for the explanation.

[kmalski]

Hi @fdutton , It seems to me that with the addition of the implementation of unevaluatedProperties @Johnlon should be satisfied or if not this issue needs more clarfication.

[fdutton]

@kmalski I think so but added the research tag to remind me to look for the "paper" @Johnlon mentioned.

[fdutton]

@Johnlon I have read this discussion and can confirm that we meet the requirements of the JSON Schema specification and pass the relevant conformance tests.

I sympathize that you have no control over the schema you are using but I'm sure you can imagine the complexity involved in asking a validator alter its behavior based on some configuration parameters. In your case it appears that you wish the validator implicitly apply an unevaluatedProperties constraint to a schema you do not control. There are several issues with this approach including:

• What is the schema used for this implicit constraint? Is it true, false or some other constraint? Your use-case implies false but others would like true and a few people would like to specify a non-boolean constraint.
• What happens when unevaluatedProperties actually appears in the schema? Do we ignore it or or replace it?
• Should we support the same behavior for unevaluated Items?

I suggest that you intercept the fetching of the problematic schema and modify it to express your additional constraints. This can be done using the URITranslator facility provided by this library. Using it, you can redirect the fetching of the problematic schema to another definition; including one that is embedded in your project. See this page for more details.

Fell free to reopen this issue if you have more insight in how this request should behave.