[awwright]

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]

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!