Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support all built-in formats of JSON Schema #60

Open
ikitommi opened this issue Sep 7, 2019 · 1 comment
Open

Support all built-in formats of JSON Schema #60

ikitommi opened this issue Sep 7, 2019 · 1 comment
Labels
enhancement New feature or request for discussion Discussion is main focus of PR

Comments

@ikitommi
Copy link
Member

ikitommi commented Sep 7, 2019

To be compatible with JSON Schema, maybe all of these should be implemented? Required for #54. Let's not do this now.

https://json-schema.org/understanding-json-schema/reference/string.html#built-in-formats

@ikitommi ikitommi added enhancement New feature or request for discussion Discussion is main focus of PR labels Sep 7, 2019
@ieugen
Copy link

ieugen commented Mar 15, 2024

Hi, It would be great to keep track of what is implemented from the built-in formats and what is not.

I made a list from the docs here to help track progress.
Feel free to copy and adapt it.

Built-in formats
The following is the list of formats specified in the JSON Schema specification.

Dates and times

Dates and times are represented in RFC 3339, section 5.6. This is a subset of the date format also commonly known as ISO8601 format.

  • "date-time": Date and time together, for example, 2018-11-13T20:20:39+00:00.
  • "time": New in draft 7 - Time, for example, 20:20:39+00:00
  • "date": New in draft 7 - Date, for example, 2018-11-13.
  • "duration": New in draft 2019-09 - A duration as defined by the ISO 8601 ABNF for "duration". For example, P3D expresses a duration of 3 days.

Email addresses

  • "email": Internet email address, see RFC 5321, section 4.1.2.
  • "idn-email": New in draft 7 - The internationalized form of an Internet email address, see RFC 6531.

Hostnames

IP Addresses

Resource identifiers

  • "uuid": New in draft 2019-09 - A Universally Unique Identifier as defined by RFC 4122. Example: 3e4666bf-d5e5-4aa7-b8ce-cefe41c7568a
  • "uri": A universal resource identifier (URI), according to RFC3986.
  • "uri-reference": New in draft 6 - A URI Reference (either a URI or a relative-reference), according to RFC3986, section 4.1.
  • "iri": New in draft 7 - The internationalized equivalent of a "uri", according to RFC3987.
  • "iri-reference": New in draft 7 - The internationalized equivalent of a "uri-reference", according to RFC3987
    If the values in the schema have the ability to be relative to a particular source path (such as a link from a webpage), it is generally better practice to use "uri-reference" (or "iri-reference") rather than "uri" (or "iri"). "uri" should only be used when the path must be absolute.

URI template

  • "uri-template": New in draft 6 - A URI Template (of any level) according to RFC6570. If you don't already know what a URI Template is, you probably don't need this value.

JSON Pointer

  • "json-pointer": New in draft 6 - A JSON Pointer, according to RFC6901. There is more discussion on the use of JSON Pointer within JSON Schema in Structuring a complex schema. Note that this should be used only when the entire string contains only JSON Pointer content, e.g. /foo/bar. JSON Pointer URI fragments, e.g. #/foo/bar/ should use "uri-reference".
  • "relative-json-pointer": New in draft 7 - A relative JSON pointer.

Regular Expressions

  • "regex": New in draft 7 - A regular expression, which should be valid according to the ECMA 262 dialect.

Be careful, in practice, JSON schema validators are only required to accept the safe subset of regular expressions described elsewhere in this document.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request for discussion Discussion is main focus of PR
Projects
None yet
Development

No branches or pull requests

2 participants