Skip to content

format should not change behavior based on its vocabulary value #1020

Closed
@gregsdennis

Description

@gregsdennis

The true or false value of the vocabulary declaration governs the implementation requirements necessary to process a schema that uses "format", and the behaviors on which schema authors can rely.

This is just wrong. It precludes an ability to assert format when supported but not require assertion when not supported. The spec still allows for configuration of this, but the practical side of that configuration becomes quite difficult and confusing:

  • For : false, my configuration needs to say "format should be an assertion."
  • For : true, my configuration needs to say "format should be an annotation."

This is hard to do and confusing for clients (users of the implementation). The configuration should always work one direction. If my implementation offers a "format behavior" configuration with values of "assert" and "annotate," setting either value only works for one of the vocab cases. The only way to get the desired behavior is to have a configuration that says "use the non-default behavior," which changes its meaning depending on the schema it's processing.

What we SHOULD have is format as an annotation ALWAYS, but configurable to be assertion.

I agree with @karenetheridge that it'd be nice to have a way for the schema itself to indicate how format should be processed, and I think that changing it based on the vocab value was an attempt at that. But the vocab value and the behavior of format are orthogonal concerns. The spec is conflating them unnecessarily.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    Closed

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions