Is "type" a required keyword? If not, how should validation be handled when a type is not specified?

[jessepinho]

According to json-schema.org:

When the primitive type of the instance cannot be validated by a given keyword, validation for this keyword and instance SHOULD succeed.

However, it is unclear whether the "primitive type" refers to the instance itself, or to the schema's type keyword. If the latter, how should an instance be validated if the schema is missing a type keyword for the instance? For example, if an instance is validated against a schema containing simply { required: ["a", "b"] }, should it be inferred that the schema describes an object, and thus validation should fail if the instance is, say, an integer? If so, what about if the schema also has non-object keywords, like minimum?

IMHO, a schema missing a type keyword should be considered invalid, as that makes validation of an instance impossible. And as a result, any instance validated against it should succeed.

[geraintluff]

Type should not be inferred from other keywords. If type is not present, then the data may be any type.

What the spec is attempting to say is: some keywords (such as required) only apply to certain types. Their presence does not imply a type for the object - if the data is not of the corresponding type, then the keyword is ignored.

Therefore, if your schema is {"required": ["a", "b"]}, then non-object values (such as "foo" or 6 or [1, 2, 3]) should pass validation. However, if the data is an object, then suddenly required becomes relevant, and is used for validation.

[juanreutter]

So if I'm not mistaken, the schema {"required" : ["a","b"], "multipleOf" : 3} successfully validates against anything that is neither a number nor an object, or any object with both "a" and "b", or any number that is a multiple of 3.

In my opinion the schema above looks rather unnatural. When you write {"minimum" : 10, "multipleOf" : 3} I read it as "a number that is at least 10 and multiple of 3". But when reading {"required" : ["a","b"], "multipleOf" : 3} its "either an object with required properties a and b, or a number that is a multiple of 3". So the meaning of the comma is "and" in the first case and "or" in the second case.

Since usually one reads the comma as an "and", I think that a natural solution would be to state that schemas as {"required" : ["a","b"], "multipleOf" : 3} cannot be validated against any object. You can enforce this by stating that objects must validate against all keywords. If you want a schema with the previous semantics you would then have to write it using "anyOf" and "not".

[geraintluff]

That's correct.

And yeah, the system you describe would also make sense, although I'm not sure whether it makes more intuitive sense to me. That's not how the specs have worked so far, and it would be a pretty big breaking change.

[bugventure]

I find implicit type validation intuitive only in the first case, when you have keywords that apply to the same type. In cases where you mix keywords for different types, I find it quite awkward to change the implicit Boolean "and" logic to "or". Currently the spec, although not very intuitive at first, clearly disambiguates any such case by simply ignoring keywords that do not apply to the actual data type and marking them as passing. This also means that a schema writer must be explicit about the required type and I find this a good thing in terms of security, the latter being one of the most common contexts a JSON validator is used in.

[fsuarezb]

Hey, in my opinion the most intuitive thing to do in this case, is to reject all instances of documents that don`t state a particular type. Furthermore, there should be instances of JSON Schemas that we could call well-formed schemas and there should be other kind of schemas that we could name not well-formed schemas. On one hand, an instance of a not well-formed schemma should be something like this:

{"required" : ["a","b"], "multipleOf" : 3}

As you can see, this is kind of a syntax error, since the type is missing in the JSON Schemma. This kind of schemas should be handled as not valid JSON Schemas(from the side of the programmer). On the other hand, we have the well-formed schemmas which can be satisfiable or not. An example of a well-formed schemma that is not satisfiable could be something like this:

{"type":"number""minimum": 8,"maximum": 4}

As you can see, the syntax of the schemma doesn't have any problems, but there is no json document that could satisfy it, since there is no number bigger than 8 and smaller than 4 at the same time. This kind of Schemas should be handled as valid JSON Schemas, even if they are not satisfiable. In my opinion this is a much better way to see the problem. Even if you can work with the way that the specification states right now, I think that this could be seen as a good practice for the community. The reason of this, is because you give much more sense to the existence of the booleans operators such as anyOf, allOf, not, etc. In this context, you could use this operators to represent schemmas like {"required" : ["a","b"], "multipleOf" : 3} but using a well-formed structure.

[sgpinkus]

According to json-schema.org:

When the primitive type of the instance cannot be validated by a given keyword, validation for this keyword and instance SHOULD succeed.

However, it is unclear whether the "primitive type" refers to the instance itself, or to the schema's type keyword. If the latter, how should an instance be validated if the schema is missing a type keyword for the instance?

@jessepinho the value should successfully validate, as it would for the empty schema {}, or equivalently a non empty schema with non keywords in it - {"some": "non", "key": "words"}. If we interpret the spec the latter way. However @geraintluff seems to be suggesting the former is the correct interpretation:

What the spec is attempting to say is: some keywords (such as required) only apply to certain types. Their presence does not imply a type for the object - if the data is not of the corresponding type, then the keyword is ignored.

Therefore, if your schema is {"required": ["a", "b"]}, then non-object values (such as "foo" or 6 or [1, 2, 3]) should pass validation. However, if the data is an object, then suddenly required becomes relevant, and is used for validation.

Its a good point raised by @jessepinho. I had assumed @jessepinho's "latter" interpretation without even considering this alternative, because it's just conceptually simpler. In the latter interpretation we have one schema object nesting level to one constraint. multipleOf, required etc are not constraints themselves but parametrizations of the type constraint. Simple. In the former we have confusing situations like {"required" : ["a","b"], "multipleOf" : 3} that aren't addressed by the spec and are harder to implement.

I don't think I'm the only one who interpreted the spec this way. In fact at the least the PHP JSON Schema implementation I'm currently using also read it this way.

[jessepinho]

From @juanreutter:

So the meaning of the comma is "and" in the first case and "or" in the second case.

I think this nails the point home the most that a type keyword should simply be required, or else the schema should be considered invalid.

As for @geraintluff's point that it would be a breaking change, I (sort of) agree that this is a concern. But two thoughts:

• The JSON schema spec actually doesn't really clarify the behavior in this case, so it's only breaking JSON schema validators that are (incorrectly) making assumptions about things that the spec doesn't actually state.
• The JSON schema spec is still a draft. Some drafts have had breaking changes from the previous versions (e.g., changing how required works between drafts 3 and 4). So, breaking changes aren't necessarily a problem.

[geraintluff]

The spec does state the behaviour. Which keywords are tested or ignored is defined by the type of the data. The allowed types are specified by the type keyword, which (if absent) allows for all types (e.g. in the empty schema {}).

{
    "type": ["string", "number"],
    "maxLength": 5, // if it's a string, length of at most five
    "oneOf": [ // if it's a number, either between 0-10, or between 100-200
        {"minimum": 0, "maximum": 10},
        {"minimum": 100, "maximum", 200}
    ]
}

The above example illustrates how this works - the options in oneOf don't need to repeat the type. Instead, they add additional constraints that only apply in the case that the data is a number.

To illustrate why I think it's a bigger change than the v3/v4 ones: while the changes from v3 to v4 were syntactically incompatible, whenever they agreed on syntax they also agreed on behaviour. This means it is straightforward to implement a validator that handles both v3/v4 without having to be told which version it should be using (e.g. by testing whether required is a boolean or array). However, a change that is syntactically compatible but with different behaviour would mean some schemas would be ambiguous depending on the version with which they're interpreted.

[mugartec]

The spec indeed define the cases of no type and multiple types, but this seems to be rather unnecessary and confusing (hence this issue). The schema presented by @geraintluff is equivalent to writing

{
   "anyOf":[
        {"type": "string",  "maxLength": 5},
        {"type": "integer", "minimum": 0, "maximum": 10 },
        {"type": "integer", "minimum": 100, "maximum": 200 }
    ]
}

which is much more intuitive and easy to read. Moreover, notice that this is not equivalent to

{
    "type": ["string", "number"],
    "maxLength": 5,
    "oneOf": [
        {"type": "number", minimum": 0, "maximum": 10},
        {"type": "number", "minimum": 100, "maximum", 200}
    ]
}

since the latter schema does not validate strings. To me this is counterintuitive. @geraintluff's comment // if it's a number, ... is valid only if you assume that all strings validate against the oneOf, but if this is not the case understanding the schema is not easy.

My conclusion is that allowing for multiple or empty types:

• Makes it harder to read and understand the meaning of a schema.
• Makes the specification harder to read.
• Does not allow for more expressive schemas. All schemas with no type or multiple types can be easily transformed into a schema in which type is required.

This facts make me lean towards making the type keyword required and containing only one string.

About this being a breaking change I agree with @jessepinho's thoughts, and would like to add the fact that it would be a breaking change only in terms of the specification. I don't think (I could be wrong though) that people use schemas like {"type": "string", "multipleOf": 10} or {"pattern": "^[a-zA-Z]@gmail.com$", "maximum": 5} or {"type": ["integer", "string"], "maximum": 10}.

[fsuarezb]

+1 @mugartec

[DomagojVrgoc]

+1 @mugartec

I can see what @geraintluff is trying to achieve by allowing a lot of freedom in the way people can write schemas (after all JSON is supposed to be very intuitive), by allowing to factor out many parts and have high-level descriptions. The problem with this is that having a formal specification is quite difficult when you want to have this level of generality, which:
a) makes building validators quite difficult and
b) will lead to people making mistakes while writing schemas (in the sense that you will have two people reading one schema in two different ways).

Overall I believe it would be beneficial for the community to have a very clean standard for the schema and, seeing what was proposed above, no expressive power would be lost. I agree that with this people might have to be a bit more pedantic when writing schemas, but it seems that this would be for the best in the long run as it would not be that prone to introducing unwanted effects.

[sgpinkus]

From @juanreutter:

So the meaning of the comma is "and" in the first case and "or" in the second case.

I think this nails the point home the most that a type keyword should simply be required, or else the schema > should be considered invalid.

Actually the meaning of the comma is consistently AND.

The changes proposed amount to either requiring the type keyword, or changing the default behavior of validation keywords applied to types they are not applicable to, from succeed to fail. I agree with @geraintluff in that these proposed changes would be a big change in semantics. I'm only in favor of an unambiguous version 4 draft spec. The text in section 4.1 of JSON Schema Validation spec should be updated to make the intended behavior clearer. From:

"Some validation keywords only apply to one or more primitive types. When the primitive type of the instance cannot be validated by a given keyword, validation for this keyword and instance SHOULD succeed."

to

"Some validation keywords only apply to one or more primitive types. When the primitive type of the instance being validated is not applicable to a validation keyword, validation for this keyword and instance SHOULD succeed. For example validating the string value "foo" against the "minimum" keyword SHOULD succeed because "minimum" is only applicable to numeric types."

[jdesrosiers]

Consider the case where you want to define a schema where any valid JSON is valid. The default keyword in the draft 4 meta schema is a real life example.

If type is not required (as it is currently). The schema would be:

{}

If type is required (the proposal). The schema would be:

{ "type": ["array", "boolean", "integer", "number", "null", "object", "string"] }

If type is required and can not have multiples (also mentioned). The schema would be:

{
  "anyOf": [
    { "type": "array" },
    { "type": "boolean" },
    { "type": "integer" },
    { "type": "number" },
    { "type": "null" },
    { "type": "object" },
    { "type": "string" }
  ]
}

In the cases where type is required, it seems pretty ridiculous that we have to do so much in order to tell the schema to do nothing. This illustrates why I am NOT in favor of making type required.

It is nice that we can start with an empty schema that validates everything and then add keywords to add constraints. Any keyword that is not in the schema has no effect on validation. No keyword is exempt. Not even type. This gives the specification a simple elegance and also makes it easy to implement validators.

I can not agree that the documentation is ambiguous, but it is undeniable that it leaves many people confused. I think it would be a good idea for the documentation to acknowledge the common misconception that leads to threads like this and add further explanation to avoid more people getting confused. That is the only change proposed in this thread that I would support.

[sgpinkus]

..it is undeniable that it leaves many people confused. I think it would be a good idea for the documentation to acknowledge the common misconception that leads to threads like this and add further explanation to avoid more people getting confused. That is the only change proposed in this thread that I would support.

👍 😄. How would we go about making such a change to the spec. Just PR it to the gh-pages branch?