Spec and meta-schema seem inconsistent w.r.t empty "type" array
aha79 opened this issue · comments
The spec allows "type": [], but in the validation vocabuary there is a 'minItems: 1' for the "type" property. This seems inconsistent.
For details see this issue I filed earlier with the test-suite (but that was the wrong place): json-schema-org/JSON-Schema-Test-Suite#673
I'm not sure I'd agree with "inconsistent", the spec doesn't say anything specifically about this case, and given the metaschema disallows this it seems more to me like the situation is that the spec is implicitly saying this isn't valid (and the metaschema is enforcing something not explicitly called out).
But the end result (of this issue) is likely the same, namely: "call out explicitly in the spec that type MUST be nonempty".
Let me quote the relevant text (type keyword) from the spec
The value of this keyword MUST be either a string or an array. If it is an array, elements of the array MUST be strings and MUST be unique.
No mention of an non-empty here array.
String values MUST be one of the six primitive types ("null", "boolean", "object", "array", "number", or "string"), or "integer" which matches any number with a zero fractional part.
Does not affect array.
If the value of "type" is a string, then an instance validates successfully if its type matches the type represented by the value of the string. If the value of "type" is an array, then an instance validates successfully if its type matches any of the types indicated by the strings in the array.
So this is an logical OR connection for the entries in the type array. The empty logical OR is false. For me this is very clear, with little room for interpretation.
For comparison see the definition of anyOf (which is also a logical OR). There non-empty array anyOf is explicitly mentioned.
But anyway you are of course right: the wording should be fixed in a future draft.
It seems to me an empty array should be permitted, even if it has limited practical use, it does mean something consistent (it's not completely nonsensical).
In particular, you can easily use {type: []} as an alternative to false or {not: {}}.
@aha79 I think the magic is contained in this sentence (and a bit to @awwright's point):
If the value of "type" is an array, then an instance validates successfully if its type matches any of the types indicated by the strings in the array.
If the array is empty, then there are no strings to match an instance to, and thus every instance will fail. It then seems reasonable that one could assume the array must be non-empty.
This does seem rather implicit, and I'm not against adding the text that @Julian mentioned as a clarification.
To be extra explicit, I see no good reason personally for
[changing the behavior such that one can] use {type: []} as an alternative to false or {not: {}}.
We should not add noisy extra ways to spell clear concepts, and even more so should err on the side of making or keeping as many useless schemas invalid as is possible whenever such a constraint is expressable in a metaschema, i.e. within the language of JSON Schema's official dialect.