`$vocabulary:{<vocab>:false}` when a vocab is recognized is not defined

[gregsdennis]

The spec states

If the value is true, then implementations that do not recognize the vocabulary MUST refuse to process any schemas that declare this meta-schema with "$schema". If the value is false, implementations that do not recognize the vocabulary SHOULD proceed with processing such schemas.

This doesn't say what the behavior is when the value is false and the implementation does recognize the vocabulary. The implication is that keywords defined by such vocabularies should still be processed.

@karenetheridge disagrees with this implication in that she interprets this as having the vocab configured as false means that the vocab's keywords can be entirely skipped (collected as annotations) even when the vocab is known.

It should be explicitly stated.

---

I had extensive DM conversations around this keyword with @handrews when he was first defining it for 2019-09 (sadly those are now lost to the Free Slack Aether). This wasn't a special case for format. The intent is to process the keywords if the vocab is known, regardless of the value. Having <vocab>: false simply means that knowledge of the vocab doesn't preclude the processability of a schema.

[handrews]

@gregsdennis yes thank you, you are remembering our conversations correctly.

For all vocabularies in $vocabulary, regardless of boolean value, if the implementations recognizes the vocabulary (either natively or through a plugin that it finds/loads somehow- how is left unspecified), then the implementation MUST process the appropriate keywords according to the semantics of the vocabulary.

The point of false is to indicate that it is safe to proceed even if the keywords will be treated as unknown keywords. It was never intended to cause the keywords to be treated as unknown keywords.

[gregsdennis]

Thank you. I'll write up a PR tonight.

[karenetheridge]

Having : false simply means that knowledge of the vocab doesn't preclude the processability of a schema.

What is a realistic usecase for ever doing this (declaring <vocab>:false)? I suppose it might be okay for a purely annotative vocabulary (if you know it, process the annotations from it, if you don't, then don't worry about it), but we are already collecting all unknown keywords as annotations anyway. For a vocabulary with validation keywords, the validation status of any schemas applied against such metaschemas (with a <vocab>:false) will be compromised when processing such keywords is skipped.

[gregsdennis]

Because of the introduction of "collect unknown keywords as annotations," purely annotative vocabs are in a weird spot. You're right: it doesn't make much sense to declare an annotative vocab with false because there's no practical change in behavior. But it does make a lot of sense for vocabs with assertive or applicative (?) keywords.

However, a schema author may want to be sure that a validator understands title, even though it's just an annotation. I can't speak to the practicality of that, but I've seen weirder things. After rereading your post, this comment doesn't make sense.

[handrews]

@karenetheridge JSON Hyper-schema's base and links annotations are complex features that produce annotations based on the instance content.

It would be totally reasonable to run a hyper-schema through a standard validator that does not understand the hyper-schema vocabulary. Depending on the application, the literal collected base and links may be usable separately, or maybe it simply doesn't care about the hyperlinks at all.