Validator doesn't support "tuple-typing" for arrays.

[bap2000]

A schema cannot be created which can contain a certain object, or nulls.

Probably more generally, the array items.type cannot take an array containing an object definition schema and a simple type definition.

Pull request with a test containing a valid schema definition and a document that should validate successfully against it.

The SchemaPassThroughCache will not even load the schema.

[seanjreilly]

Thanks for the bug report (and the associated pull request with tests).

The problem is bigger than you suspected — neither the schema object model nor the schema parser support the third clause of section 5.5, the "tuple-type" clause. The validator also doesn't support additionalItems.

I've renamed the issue — hope that's ok with you.

Proposed Fix: The fix is to implement tuple typing in ArraySchemas.

Edge cases:

1. What happens when there are more items in the document's array than there are in the schema?
   • Loop through the items array multiple times
   • Fail with an error

I prefer the first case, but IMO, the spec is unclear about what should happen in this situation. I'll check the mailing list for more info and opinions.

[seanjreilly]

The edge case is probably governed by section 5.6: additionalItems. If the number of items doesn't match exactly, then the additionalItems property should be consulted.

[bap2000]

Sometimes GitHub really confuses me! I closed the issue that it created all by itself - and it made the pull disappear!

Oh well, the test case is here #2

The case that I supplied was not for tupple-typing (where the items property is a list containing the schemas/simple types for the positions in the list) but is for "Union Types" specified at the end of 5.1 Types - where each position in the list can match any of the schemas/simple types.

[seanjreilly]

I've reopened the pull request, just so that it's visible to refer to.

As you suspected, Section 5.1's union types aren't supported yet either. I might ultimately split this issue into two separate issues, one for each section.

The big issue here is with error messages. If it's just an array of simple types like ["string", "number", "null"] then a usable error message is no problem:

foo.bar.baz[3]: value must be one of these types: "string", "number", "null"

But if the array consists of more than one object type, and the supplied document doesn't conform to any of them, then which set of error messages should be displayed?

• The first set
• All error messages across all sets
• The set with the smallest number of errors
• All of the sub errors + an additional message explaining the union
• None of the sets of errors, just a message explaining that none of the schemas were valid
• Something else

We try really hard to emit high quality error messages, and include all of the problems that we can find, in order to minimise the number of validation round-trips a user has to perform to fix errors and make a valid document.

IIRC, that's why we put off implementing this feature at first (we don't really need it). I'll have to ask the guys for some opinions. I'll probably canvas the json-schema mailing list as well.