metaschema permissiveness (why are unsupported keywords allowed?)

[russwe]

I've recently written (and validated) a schema that contained "requiredProperties": [] rather than "required": [] and accidentally let a much more permissive schema into the wild than intended. Is there a reason this sort of error should be allowed, or is this simply an oversight in the existing drafts?

Maybe I'm missing a use-case that "free-form" keywords in the schema allow?

[russwe]

TL;DR: Why isn't "additionalProperties": false for the meta-schema as a whole?

[Julian]

Not to take away from an independent question that it sounds like you're asking ("should the meta schema disallow additionalProperties by default", which I believe has some previous discussion somewhere that I'm sure @handrews will know about), but I'd say if you didn't have unit tests for your schema you have got some issues that defaults won't fix :). They can make it slightly harder, but I'd still always recommend personally that you have a suite that's testing examples of instances you expect to be valid and invalid.

[russwe]

That is also an excellent point, not to be discounted. While the schema did undergo testing, this was clearly a miss... in part because the intention was clear in the schema and we all know the spiel about assumptions.

It would be nice, though, to have an additional layer, especially one that would allow simply pulling referenced meta-schema to do validation of the actual schema at runtime ;)

[handrews]

@russwe JSON Schema is specifically designed as an extensible system. Per JSON Schema Core §4.3.1:

A JSON Schema MAY contain properties which are not schema keywords. Unknown keywords SHOULD be ignored.

Setting "additionalProperties": false in the meta-schema would directly contradict that requirement.

You can, of course, write your own meta-schema, add "additionalProperties": false where desired, and test your schemas against that. I have a build step that does just that in the schema repository that I use currently. Currently, the downside of using such a meta-schema in $schema is that if your validator checks $schema and expects the standard meta-schema, it will get confused. Although many validators ignore $schema in favor of whatever you tell them to do on the command line or through configuration.

With #561 (vocabulary support, targeted for draft-08) it will be easier to write your own meta-schema but still have implementations recognize the underlying standard vocabulary. Once draft-08 is published and implemented you could use that plus #556 (unevaluatedProperties, also targeted for draft-08) to very easily write a meta-schema that does this, but is still recognizable as using the standard validation vocabulary.

[handrews]

@russwe hopefully this makes sense- it's done this way because schemas are a constraint system, and once you add a constraint to a schema, no one else who re-uses a schema can remove that constraint.

Once we have unevaluatedProperties, you can easily do {"allOf": [{"$ref": "http://json-schema.org/draft-08/schema"}], "unevaluatedProperties": false} and get the behavior you want. Or you can do something more complex with vocabularies. These changes are already tracked in other issues so I'm going to close this one.

[russwe]

That absolutely makes sense. I missed 4.3.1, though I was looking for something similar. I'll look over the links you've provided and determine the best path forward for us... certainly it is no real hardship to add the "additionalProperties": false for internal validation.

Thanks!