4 ms·

I was building an app using JSON Schema last year (until Feb this year) and gave up. I had read JSON Schema specification like 10 times and there are some undef

I was building an app using JSON Schema last year (until Feb this year) and gave up. I had read JSON Schema specification like 10 times and there are some undefined behaviors. I had read a lot of JSON Schema issues on Github, there is basically one man show and the others come to review mostly. After the point they added all logics to the spec, everything becomes a mess. Example 1: { "oneOf": [ {"type": "number"}, {"type": "number"} ] } 1 or 2 or 3 is an invalid input based on above schema. It doesn't make sense to me at first glance. (hint: it's XOR) --------- Example 2: { "oneOf": [ {"minimum": 0, "maximum": 10}, {"minimum": 5, "maximum": 20} ] } These ranges will pass: [0,4] and [11,20] But you would be surprise it doesn't reject string, bool, null. Basically it doesn't reject anything except [5,10] range. --------- Example 3: { "type": ["object", "array", "null"], "not": {} } Easy but confusing. This rejects every thing because comma means AND, and `"not": {}` means false. --------- Example 4: { "allOf": [ { "type": "object", "properties": { "a": {"type": "string"}, "b": {"type": "integer"} } }], "additionalProperties": false } A well-known problem. This rejects (all - {}) This is because the "allOf" is object AND outside it is an empty object. "properties" at level 0 is empty if not specified. So this schema only accept {}; an object AND is empty. They add a new keyword called "unevaluatedProperties" to solve this and I won't explain it to you! ----- If you just use basic stuff like draft-04, you will be fine. But I will NEVER touch this spec again! ----- EDIT: My app was sort of static analysis on schema, and this spec doesn't suppose to help doing thing like that.

Existenceblinks 8y ago
I also read this paper: https://martinugarte.com/media/pdfs/p263.pdf https://martinugarte.com/media/pdfs/p263.pdf (Foundations of JSON Schema) Also this: https://www.genivia.com/sjot.html#SJOT_versus_JSON_schema https://www.genivia.com/sjot.html#SJOT_versus_JSON_schema (JSON Schema problems) GOOD LUCK!
awwright 8y ago
It seems like there's two slight misunderstandings: > "oneOf": [ {"type": "number"}, {"type": "number"} ] > { "oneOf": [ {"minimum": 0, "maximum": 10}, {"minimum": 5, "maximum": 20} ] } "oneOf" requires exactly one match (hence the name), typically you want to use "anyOf" or "allOf". And there's no benefit in putting two identical values inside them. > { "type": ["object", "array", "null"], "not": {} } > { "allOf": [ { "type": "object", "properties": { "a": {"type": "string"}, "b": {"type": "integer"} } }], "additionalProperties": false } JSON Schema is merely a list of assertions. Some test the type of the value (that's the "type" keyword), others test the value ranges within a single type. This way, you can allow values to be one of multiple types, e.g.: {type:["string","object"], minLength:1} means "Value must be a string or object; and if it's a string, it must have at least one character." Some of the assertions are spread across multiple keywords, "additionalProperties" depends on "properties", for example. So, {additionalProperties:false} means: if value is an object, then only an empty object is permitted. Some implementations can tell you if you're trying to do nonsensical things (like test the maximum length of a value that's only allowed to be a boolean), but that's up to the implementation to test for.
- Existenceblinks 7y ago
  Yes, it's my mistake using JSON Schema for something it does not suppose to. Analyzing schema from user input is very difficult if "type" keyword is not required (I actually had read the GH's issue about it). IMHO, JSON is already verbose, no need to make it concise, requiring "type" make it a lot simpler. I'd also prefer not to allow multiple type on "type" keyword. The fact that the spec is too flexible that allow users to write all nonsensical things, and so sensible things that might have hole on assertions. I understand all your explanation and thanks for creating a new account to do this, appreciated!

Existenceblinks 8y ago

I also read this paper: https://martinugarte.com/media/pdfs/p263.pdf https://martinugarte.com/media/pdfs/p263.pdf (Foundations of JSON Schema) Also this: https://www.genivia.com/sjot.html#SJOT_versus_JSON_schema https://www.genivia.com/sjot.html#SJOT_versus_JSON_schema (JSON Schema problems) GOOD LUCK!

awwright 8y ago

It seems like there's two slight misunderstandings: > "oneOf": [ {"type": "number"}, {"type": "number"} ] > { "oneOf": [ {"minimum": 0, "maximum": 10}, {"minimum": 5, "maximum": 20} ] } "oneOf" requires exactly one match (hence the name), typically you want to use "anyOf" or "allOf". And there's no benefit in putting two identical values inside them. > { "type": ["object", "array", "null"], "not": {} } > { "allOf": [ { "type": "object", "properties": { "a": {"type": "string"}, "b": {"type": "integer"} } }], "additionalProperties": false } JSON Schema is merely a list of assertions. Some test the type of the value (that's the "type" keyword), others test the value ranges within a single type. This way, you can allow values to be one of multiple types, e.g.: {type:["string","object"], minLength:1} means "Value must be a string or object; and if it's a string, it must have at least one character." Some of the assertions are spread across multiple keywords, "additionalProperties" depends on "properties", for example. So, {additionalProperties:false} means: if value is an object, then only an empty object is permitted. Some implementations can tell you if you're trying to do nonsensical things (like test the maximum length of a value that's only allowed to be a boolean), but that's up to the implementation to test for.

Existenceblinks 7y ago
Yes, it's my mistake using JSON Schema for something it does not suppose to. Analyzing schema from user input is very difficult if "type" keyword is not required (I actually had read the GH's issue about it). IMHO, JSON is already verbose, no need to make it concise, requiring "type" make it a lot simpler. I'd also prefer not to allow multiple type on "type" keyword. The fact that the spec is too flexible that allow users to write all nonsensical things, and so sensible things that might have hole on assertions. I understand all your explanation and thanks for creating a new account to do this, appreciated!