Meaning of the "ignore" in relation to the keywords

[yakimun]

Spec states that we must ignore some of the keywords in some cases.

Examples from spec:

• The "$vocabulary" keyword MUST be ignored in schema documents that are not being processed as a meta-schema.

• when "if" is not present, both "then" and "else" MUST be entirely ignored.

• If a boolean true value is present from any of the relevant annotations, "unevaluatedItems" MUST be ignored.

What does this "ignore" mean exactly? Should we at least check the correctness of the value of the keyword in such cases?

{
  "$vocabulary": "foo"
}

Here we have an incorrect value for $vocabulary keyword. If we treat this JSON as a schema (not as meta-schema), should it be considered correct?

[Relequestual]

The meta-schema is still used to validate a given schema, and it will check for the correct formatting of that value. However, it has no implications. "Ignored" in the sense of impact. The spec talks about format and implementation when using RFC2119 keywords (requirements in caps). In this instance, it's about the validation process of an implementation as opposed to the format.

[karenetheridge]

Here we have an incorrect value for $vocabulary keyword. If we treat this JSON as a schema (not as meta-schema), should it be considered correct?

That syntax is prohibited by the metaschema itself ("properties": { "$vocabulary": { "additionalProperties": { "type": "boolean" } } } }), so you might as well check it right away while processing all the other keywords.

The checks that are important to delay until in "processing as a metaschema" mode are:

• is the $vocabulary URI known to the implementation (i.e. do we know what vocabulary that URI corresponds to)
• is the Core vocabulary one of the vocabularies listed
• are the specification versions between the vocabulary and the metaschema itself consistent (this may be a non-issue for your implementation; it wasn't for mine, so I check for mismatches everywhere).

[yakimun]

Thanks for the clarification!

The checks that are important to delay until in "processing as a metaschema" mode are:

• is the $vocabulary URI known to the implementation (i.e. do we know what vocabulary that URI corresponds to)
• is the Core vocabulary one of the vocabularies listed
• are the specification versions between the vocabulary and the metaschema itself consistent (this may be a non-issue for your implementation; it wasn't for mine, so I check for mismatches everywhere).

It's clear, but what about this (from $vocabulary keyword spec):

It MUST NOT appear in subschemas.

This requirement isn't reflected in the meta-schema (probably to avoid complicating it too much), but it looks more like a format requirement than a validation rule.

[karenetheridge]

We could put this in the metaschema, to at least check that $vocabulary appeared only in a schema resource root:

"dependentRequired": {
  "$vocabulary": [ "$id" ]
}

(that is: if $vocabulary appears, there needs to be an $id adjacent to it), but indeed the "$vocabulary can only appear at the document root" part would be more difficult to check without restructuring the entire metaschema and how the $dynamicRefs worked. It would also make it more difficult for other metaschemas to modify this one.

But FWIW, I disagree with that part of the spec anyway, as it means that metaschemas cannot be bundled, and am considering proposing removing that restriction in a subsequent revision.