Define the abstract instance validation function

[awwright]

It may be useful to define, in somewhat mathematical terms, what it means to validate an instance, and which inputs are used.

I imagine the validation function being defined as such:

Validate[collection, schema, version, iriBase, instance] → Boolean ∪ Indeterminate

Where:

• collection ∈ set of all Map[ IRI → valid JSON Schema instance ]
• schema ∈ set of all IRIs
• version ∈ set of all IRIs
• iriBase ∈ set of all IRIs
• instance ∈ set of all JSON documents (i.e. with a media type application/json)

This may also help to resolve issue #4. If the validation function is defined to have no side-effects, then we can just reiterate that point within the "default" keyword. We can also say the keyword is "not used for validation, but may be used for other purposes not defined here."

This is not to say that JSON Schema libraries can't implement other functions, they might desire to implement a "coerce" function that turns an arbitrary JSON instance into a validating one (casting strings to numbers, filling in missing required values using the default, etc).

Aside: Defining a "coerce" might be something useful for v6 (or, the next version with feature additions).

[epoberezkin]

I agree that validation should not have side effects. I would keep "coerce" out of the standard.

[yoshuawuyts]

Agreed. -1 for side effects, -1 for "coerce" in v5.

[awwright]

Perhaps more something like:

Validate[collection, schema, version, iriBase, instance] → Boolean

Where:

• collection ∈ set of all Map[ IRI → valid JSON Schema instance ]
• schema ∈ set of all IRIs found in collection
• version ∈ set of all IRIs identifying meta-schemas
• iriBase ∈ set of all IRIs
• instance ∈ set of all JSON documents (i.e. with a media type application/json)

By this definition, invalid schemas, and schemas linking to non-existent schemas, are outside of the domain, and the function can always return valid/invalid.

[awwright]

There's two questions we have to figure out here:

0. Is it possible to change schema versions, intra-document, with a $schema keyword? How can we indicate where a schema version change may take place?

1. Should the function include an indeterminate return value; or should invalid schemas be considered outside the domain of the function? (I.e. the value of this function is only defined for valid schemas). This may have a few ramifications, for example, it's possible to construct a schema that can produce all three invalid, valid, and error conditions depending on the instance that you feed it.

[Relequestual]

An invalid schema should be out of scope. In a similar way, if you try to parse invalid json, you get an error from your json parser... you don't get up to the point of the error in parsed json.

[Relequestual]

@yoshuawuyts You have given two -1's but without reason. A -1 without reason is invalid.

[seagreen]

One thing I think we can say for sure is that invalid schemas should not return validation: false, either the shouldn't be part of the domain of the function at all or they should get their own result (like the indeterminate suggested by @awwright). If they did return false then then invalid schemas would be indistinguishable from {"not":{}} valid schemas. No one has actually suggested we do this, I'm just writing the argument against it out for completeness.

Also, I think the questions brought up by @awwright are super important and I'd like to hear more people's thoughts on this.

[seagreen]

This should absolutely be a blocker for new drafts of the spec until it's resolved.

How can we be releasing specifications for something that we can't even formally describe?

[handrews]

@seagreen from a practical perspective, it's obviously been working out OK. We are very close to Draft 06 and I am reluctant to postpone it for an issue that will no doubt involve a lot of debate.

What about this would prevent someone from successfully implementing Draft 06?