Skip to content

Strengthen requirements around optional vocabularies #1300

Closed
@handrews

Description

@handrews

Issue #1294 (implemented by PR #1295) includes a better explanation of optional vocabulary use cases, specifically supporting annotation-only vocabularies without needing any custom code.

Currently, implementations SHOULD process optional vocabularies that they do not understand, and SHOULD handle unrecognized keywords as annotations.

I don't remember why the first SHOULD exists - since it's already possible to disable annotation collection (if it's supported at all), and if annotations can't be collected then unrecognized keywords MUST be ignored, I think it makes sense to upgrade this to a MUST. Any negative impact can be mitigated by disabling annotation collection.

The second SHOULD ought to be converted to a MUST collect as annotations when annotations are enabled, and a MUST ignore otherwise. It was a SHOULD to avoid forcing collecting large values (e.g. subschemas of unknown applicators), which was a concern with non-vocabulary keywords. However, a vocabulary with such keywords can be included as required to avoid collecting applicators as annotations, so there's now another way to avoid that problem that makes more sense. If we keep non-vocabulary keywords, annotation collection can remain a SHOULD for those.

Finally, we should overall make it mandatory to support unrecognized optional vocabularies. We want people to make these as they don't require code, so we want them to be widely supported. Doing so is trivial (again, if annotations aren't supported then supporting unrecognized optional vocabularies means literally doing nothing).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    Closed

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions