Skip to content

Define Validation spec vocabularies #697

Closed
@handrews

Description

@handrews

Now that the $vocabulary PR is nearing approval, we need to figure out how many vocabularies are present in the Validation spec, and what to call them.

Minimal arrangement

I'm guessing something like:

I'm not super-attached to those names, but I do think this nicely encapsulates both the different purposes of some groups of keywords, and the optional nature of format and content*. Optional keyword groups were always particularly confusing for users and implementors.

The reason for basic-format is that it's extensible so I assume other people will probably have vocabularies using format in the name. But I could be convinced to go with standard-format, format, or the plural of any of those (standard-formats, etc.).

Multiple format vocabularies?

While format currently says that if you implement the keyword at all, you SHOULD implement all of the formats, this has become increasingly burdensome as the set of standard formats has expanded.

We could break them up and provide vocabularies that each only declare the semantics for a subset of the standard formats. An example division could be:

  • date-time-formats
  • internet-formats (hostnames, IP addresses, email, URIs, IRIs)
  • json-pointer-formats (JSON Pointer and Relative JSON Pointer)
  • regex-format

The internet-formats could be split up more, although I do wonder at what point it's more trouble than its worth.

@Julian @johandorland @gregsdennis as implementors what would you find useful here?

Metadata

Metadata

Assignees

Type

No type

Projects

Status

Closed

Relationships

None yet

Development

No branches or pull requests

Issue actions