From 3ef66dc16c18b09cbd9223b5e47fbb9057df0ae2 Mon Sep 17 00:00:00 2001 From: Dj Padzensky Date: Thu, 7 Feb 2019 10:02:36 -0800 Subject: [PATCH 001/780] Clarifying "const" usage. --- jsonschema-validation.xml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index c589d1cd..51986853 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -242,6 +242,10 @@ The value of this keyword MAY be of any type, including null. + + Use of this keyword is functionally equivalent to an + "enum" with a single value. + An instance validates successfully against this keyword if its value is equal to the value of the keyword. From ae9416e6189a5fbb4721f508d41d81465f7f50bc Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 22 Feb 2019 20:04:08 -0800 Subject: [PATCH 002/780] Update year to 2019 --- jsonschema-core.xml | 2 +- jsonschema-hyperschema.xml | 2 +- jsonschema-validation.xml | 2 +- relative-json-pointer.xml | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d67b3d1e..e4736366 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -60,7 +60,7 @@ - + Internet Engineering Task Force JSON Schema diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index f7741632..cfd90225 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -48,7 +48,7 @@ - + Internet Engineering Task Force JSON Schema diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index c589d1cd..21200f34 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -69,7 +69,7 @@ - + Internet Engineering Task Force JSON Schema diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index eb8b7f38..8162736d 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -39,7 +39,7 @@ - + Internet Engineering Task Force JSON JavaScript From a37187350b1c9fc2dd7510f82790b1aa569b1ff6 Mon Sep 17 00:00:00 2001 From: Austin Wright Date: Tue, 26 Feb 2019 22:34:05 -0700 Subject: [PATCH 003/780] Update xml2rfc required version --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index 25b47f85..cccfa933 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,6 +1,6 @@ language: python install: -- pip install "xml2rfc<2.10" +- pip install "xml2rfc~=2.20" before_script: - TAG=$(git tag -l --points-at HEAD) script: From eb0add1b2211a4acc54d8db718c25f8cc3610a57 Mon Sep 17 00:00:00 2001 From: Austin Wright Date: Tue, 26 Feb 2019 22:38:09 -0700 Subject: [PATCH 004/780] Output xml2rfc version number --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index cccfa933..ab5bf83a 100644 --- a/.travis.yml +++ b/.travis.yml @@ -4,6 +4,7 @@ install: before_script: - TAG=$(git tag -l --points-at HEAD) script: +- xml2rfc -V - xml2rfc jsonschema-core.xml --basename=jsonschema-core-$TAG --text --html - xml2rfc jsonschema-validation.xml --basename=jsonschema-validation-$TAG --text --html - xml2rfc jsonschema-hyperschema.xml --basename=jsonschema-hyperschema-$TAG --text --html From 0d85f47995518e90961a92d163b9424546f99775 Mon Sep 17 00:00:00 2001 From: Austin Wright Date: Tue, 26 Feb 2019 22:47:56 -0700 Subject: [PATCH 005/780] Use Makefile for building --- .travis.yml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/.travis.yml b/.travis.yml index ab5bf83a..00e794b4 100644 --- a/.travis.yml +++ b/.travis.yml @@ -5,6 +5,4 @@ before_script: - TAG=$(git tag -l --points-at HEAD) script: - xml2rfc -V -- xml2rfc jsonschema-core.xml --basename=jsonschema-core-$TAG --text --html -- xml2rfc jsonschema-validation.xml --basename=jsonschema-validation-$TAG --text --html -- xml2rfc jsonschema-hyperschema.xml --basename=jsonschema-hyperschema-$TAG --text --html +- make all From 362552fe67582fc1a084ae5fe0604d6c3cd38622 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 27 Feb 2019 14:57:29 +0000 Subject: [PATCH 006/780] Fix issue label number badges Fixes https://github.com/json-schema-org/json-schema-spec/issues/460 --- README.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 1bafd11d..d6528e65 100644 --- a/README.md +++ b/README.md @@ -13,10 +13,11 @@ Please read our [guidelines for contributing](CONTRIBUTING.md). ## Status For the current status of issues and pull requests, please see the following labels -[![Available](https://img.shields.io/waffle/label/json-schema-org/json-schema-spec/Status:%20Available.svg?style=flat)](https://github.com/json-schema-org/json-schema-spec/issues?q=is%3Aopen+is%3Aissue+label%3A%22Status%3A+Available%22) [![In Progress](https://img.shields.io/waffle/label/json-schema-org/json-schema-spec/Status:%20In%20Progress.svg?style=flat)](https://github.com/json-schema-org/json-schema-spec/labels/Status:%20In%20Progress) [![Review Needed](https://img.shields.io/waffle/label/json-schema-org/json-schema-spec/Status:%20Review%20Needed.svg?style=flat)](https://github.com/json-schema-org/json-schema-spec/labels/Status%3A%20Review%20Needed) +[![Available](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20Available.svg?color=brightgreen)](https://github.com/json-schema-org/json-schema-spec/issues?q=is%3Aopen+is%3Aissue+label%3A%22Status%3A+Available%22) [![In Progress](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20In%20Progress.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Status:%20In%20Progress) [![Review Needed](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20Review%20Needed.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Status%3A%20Review%20Needed) + +[![Critical](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Critical.svg?color=critical +)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Critical) [![High](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20High.svg?color=important)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20High) [![Medium](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Medium.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Medium) [![Low](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Low.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Low) -[![Critical](https://img.shields.io/waffle/label/json-schema-org/json-schema-spec/Priority:%20Critical.svg?style=flat -)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Critical) [![High](https://img.shields.io/waffle/label/json-schema-org/json-schema-spec/Priority:%20High.svg?style=flat)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20High) [![Medium](https://img.shields.io/waffle/label/json-schema-org/json-schema-spec/Priority:%20Medium.svg?style=flat)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Medium) [![Low](https://img.shields.io/waffle/label/json-schema-org/json-schema-spec/Priority:%20Low.svg?style=flat)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Low) Labels are assigned based on [Sensible Github Labels](https://github.com/Relequestual/sensible-github-labels). From f0f802f21f9fab8fd57c6c9712018f9d938e9047 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 22 Feb 2019 23:53:57 -0800 Subject: [PATCH 007/780] Add a "duration" format. --- jsonschema-validation.xml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 21200f34..d8647bdb 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -543,13 +543,15 @@
-
+
These attributes apply to string instances. Date and time format names are derived from RFC 3339, section 5.6. + The duration format is from the ISO 8601 ABNF as given + in Appendix A of RFC 3339. Implementations supporting formats SHOULD implement support for @@ -567,6 +569,10 @@ A string instance is valid against this attribute if it is a valid representation according to the "full-time" production. + + A string instance is valid against this attribute if it is + a valid representation according to the "duration" production. + From 6cae0d020a14565e84157f014cd9aae9d4fcff6a Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 23 Feb 2019 00:20:15 -0800 Subject: [PATCH 008/780] Add UUID (not in URN) format --- jsonschema-validation.xml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 21200f34..d1cb5da2 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -8,6 +8,7 @@ + @@ -676,10 +677,22 @@ Reference (either an IRI or a relative-reference), according to . + + A string instance is valid against this attribute if it is a valid + string representation of a UUID, according to . + + + Note that all valid URIs are valid IRIs, and all valid URI References are also valid IRI References. + + Note also that the "uuid" format is for plain UUIDs, not UUIDs in URNs. An example + is "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". For UUIDs as URNs, use the "uri" format, + with a "pattern" regular expression of "^urn:uuid:" to indicate the URI scheme and + URN namespace. +
@@ -1063,6 +1076,7 @@ &RFC3339; &RFC3986; &RFC3987; + &RFC4122; &RFC4291; &RFC4648; &RFC5322; From 3d14d92f163dc845e82ce3e77977c82c20c1129b Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 22 Feb 2019 23:28:26 -0800 Subject: [PATCH 009/780] Identify vocabularies, update meta-schemas Includes verbiage on the likelihood of updated meta-schemas with later dates. The hyper-schema output format has not yet been updated to conform to the recent annotion/error output work. --- hyper-schema.json | 30 ++-- jsonschema-core.xml | 63 ++++--- jsonschema-hyperschema.xml | 35 +++- jsonschema-validation.xml | 78 ++++++-- links.json | 12 +- applicator.json => meta/applicator.json | 7 +- meta/content.json | 17 ++ core.json => meta/core.json | 6 +- meta/format.json | 14 ++ meta/hyper-schema.json | 29 +++ meta/meta-data.json | 33 ++++ meta/validation.json | 101 +++++++++++ .../hyper-schema.json | 6 +- schema-output.json => output/schema.json | 6 +- .../verbose-example.json | 0 schema.json | 169 +++--------------- 16 files changed, 380 insertions(+), 226 deletions(-) rename applicator.json => meta/applicator.json (87%) create mode 100644 meta/content.json rename core.json => meta/core.json (85%) create mode 100644 meta/format.json create mode 100644 meta/hyper-schema.json create mode 100644 meta/meta-data.json create mode 100644 meta/validation.json rename hyper-schema-output.json => output/hyper-schema.json (91%) rename schema-output.json => output/schema.json (94%) rename standardized-output-verbose.json => output/verbose-example.json (100%) diff --git a/hyper-schema.json b/hyper-schema.json index 5d72a263..96013fdd 100644 --- a/hyper-schema.json +++ b/hyper-schema.json @@ -1,22 +1,22 @@ { - "$schema": "http://json-schema.org/draft-08/hyper-schema#", - "$id": "http://json-schema.org/draft-08/hyper-schema", + "$schema": "http://json-schema.org/draft/2019-03/hyper-schema#", + "$id": "http://json-schema.org/draft/2019-03/hyper-schema", + "$vocabulary": { + "https://json-schema.org/draft/2019/03/vocab/core": true, + "https://json-schema.org/draft/2019/03/vocab/applicator": true, + "https://json-schema.org/draft/2019/03/vocab/validation": true, + "https://json-schema.org/draft/2019/03/vocab/meta-data": true, + "https://json-schema.org/draft/2019/03/vocab/format": true, + "https://json-schema.org/draft/2019/03/vocab/content": true, + "https://json-schema.org/draft/2019/03/vocab/hyper-schema": true + }, "$recursiveAnchor": true, "title": "JSON Hyper-Schema", - "$ref": "http://json-schema.org/draft-08/schema", - "properties": { - "base": { - "type": "string", - "format": "uri-template" - }, - "links": { - "type": "array", - "items": { - "$ref": "http://json-schema.org/draft-08/links" - } - } - }, + "allOf": [ + {"$ref": "http://json-schema.org/draft/2019-03/schema"}, + {"$ref": "http://json-schema.org/draft/2019-03/meta/hyper-schema"} + ], "links": [ { "rel": "self", diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e4736366..9093bf35 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1058,11 +1058,18 @@ The current URI for the Core vocabulary is: - . + . The current URI for the corresponding meta-schema is: - . + . + + + Updated vocabulary and meta-schema URIs MAY be published between + specification drafts in order to correct errors. Implementations + SHOULD consider URIs dated after this specification draft and + before the next to indicate the same syntax and semantics + as those listed here.
+ + Meta-schemas that do not use "$vocabulary" SHOULD be considered to + require this vocabulary as if its URI were present with a value of true. + The current URI for this vocabulary, known as the Applicator vocabulary, is: - . + . The current URI for the corresponding meta-schema is: - . + . - Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its URI were present with a value of true. + Updated vocabulary and meta-schema URIs MAY be published between + specification drafts in order to correct errors. Implementations + SHOULD consider URIs dated after this specification draft and + before the next to indicate the same syntax and semantics + as those listed here.
@@ -2479,7 +2493,7 @@
@@ -2555,7 +2569,7 @@ http://json-schema.org/draft-08/schema#/$defs/nonNegativeInteger/minimum Because this output structure can be quite large, a smaller example is given - here for brevity. The full output structure of the example above can be found - here. + here for brevity. The URI of the full output structure of the example above is: + .
@@ -2775,7 +2789,7 @@ http://json-schema.org/draft-08/schema#/$defs/nonNegativeInteger/minimum // schema { "$id": "http://example.com/polygon#", - "$schema": "http://json-schema.org/draft-08/schema#", + "$schema": "http://json-schema.org/draft/2019-03/schema#", "type": "object", "properties": { "validProp": true, @@ -2825,10 +2839,11 @@ http://json-schema.org/draft-08/schema#/$defs/nonNegativeInteger/minimum
-
+
- For convenience, a JSON Schema has been provided to validate output generated - by implementations. It can be found here. + For convenience, JSON Schema has been provided to validate output generated + by implementations. Its URI is: + .
diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index cfd90225..05fc523b 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -288,14 +288,24 @@
The current URI for the JSON Hyper-Schema meta-schema is - . + . + + + The current URI for this vocabulary, known as the Hyper-Schema vocabulary, is: + . + + + The current URI for the corresponding meta-schema, which differs from the + convenience meta-schema above in that it describes only the hyper-schema + keywords ("base" and "link") is: + . The link description format can be used without JSON Schema, and use of this format can be declared by referencing the normative link description schema as the schema for the data structure that uses the links. The URI of the normative link description schema is: - . + . JSON Hyper-Schema implementations are free to provide output in any format. @@ -306,7 +316,14 @@ It is RECOMMENDED that implementations be capable of producing output in this format to facilitated testing. The URI of the JSON Schema describing the recommended output format is - . + . + + + Updated vocabulary and meta-schema URIs MAY be published between + specification drafts in order to correct errors. Implementations + SHOULD consider URIs dated after this specification draft and + before the next to indicate the same syntax and semantics + as those listed here.
@@ -1607,7 +1624,7 @@ Link: ; rel="describedBy" ; rel="describedBy" ; rel="describedBy" ; rev="up" ; rev="up" ; rev="up" The current URI for the JSON Schema Validation meta-schema is - . - This meta-schema describes the core keywords, the subschema application - vocabulary from the core specification, and all keywords - defined by this specification. All implementations of this specification - SHOULD support the subschema application vocabulary, and MUST NOT - implement behavior that contradicts that vocabulary. + . + For schema author convenience, this meta-schema describes all vocabularies + defined in this specification and the JSON Schema Core specification. + Individual vocabulary and vocabulary meta-schema URIs are given for + each section below. + + + Updated vocabulary and meta-schema URIs MAY be published between + specification drafts in order to correct errors. Implementations + SHOULD consider URIs dated after this specification draft and + before the next to indicate the same syntax and semantics + as those listed here.
-
+
Validation keywords in a schema impose requirements for successful validation of an instance. These keywords are all assertions without any annotation behavior. + + Meta-schemas that do not use "$vocabulary" SHOULD be considered to + require this vocabulary as if its URI were present with a value of true. + + + The current URI for this vocabulary, known as the Validation vocabulary, is: + . + + + The current URI for the corresponding meta-schema is: + . +
@@ -496,7 +514,7 @@
-
+
@@ -514,6 +532,20 @@ format attribute and instance SHOULD succeed. + + Meta-schemas that do not use "$vocabulary" SHOULD be considered to + require this vocabulary as if its URI were present with a value of true, + although see the Implementation Requirements below for details. + + + The current URI for this vocabulary, known as the Format vocabulary, is: + . + + + The current URI for the corresponding meta-schema is: + . + +
@@ -733,7 +765,7 @@
-
+
@@ -745,6 +777,19 @@ These properties provide additional information required to interpret JSON data as rich multimedia documents. + + Meta-schemas that do not use "$vocabulary" SHOULD be considered to + require this vocabulary as if its URI were present with a value of true, + although see the Implementation Requirements below for details. + + + The current URI for this vocabulary, known as the Content vocabulary, is: + . + + + The current URI for the corresponding meta-schema is: + . +
@@ -914,13 +959,26 @@
-
+
These general-purpose annotation keywords provide commonly used information for documentation and user interface display purposes. They are not intended to form a comprehensive set of features. Rather, additional vocabularies can be defined for more complex annotation-based applications. + + Meta-schemas that do not use "$vocabulary" SHOULD be considered to + require this vocabulary as if its URI were present with a value of true. + + + The current URI for this vocabulary, known as the Meta-Data vocabulary, is: + . + + + The current URI for the corresponding meta-schema is: + . + +
The value of both of these keywords MUST be a string. diff --git a/links.json b/links.json index 435eecba..ddcca685 100644 --- a/links.json +++ b/links.json @@ -1,6 +1,6 @@ { - "$schema": "http://json-schema.org/draft-08/hyper-schema#", - "$id": "http://json-schema.org/draft-08/links", + "$schema": "http://json-schema.org/draft/2019-03/hyper-schema#", + "$id": "http://json-schema.org/draft/2019-03/links", "title": "Link Description Object", "allOf": [ { "required": [ "rel", "href" ] }, @@ -36,7 +36,7 @@ "format": "uri-template" }, "hrefSchema": { - "$recursiveRef": "http://json-schema.org/draft-08/hyper-schema", + "$recursiveRef": "http://json-schema.org/draft/2019-03/hyper-schema", "default": false }, "templatePointers": { @@ -63,7 +63,7 @@ "type": "string" }, "targetSchema": { - "$recursiveRef": "http://json-schema.org/draft-08/hyper-schema", + "$recursiveRef": "http://json-schema.org/draft/2019-03/hyper-schema", "default": true }, "targetMediaType": { @@ -71,7 +71,7 @@ }, "targetHints": { }, "headerSchema": { - "$recursiveRef": "http://json-schema.org/draft-08/hyper-schema", + "$recursiveRef": "http://json-schema.org/draft/2019-03/hyper-schema", "default": true }, "submissionMediaType": { @@ -79,7 +79,7 @@ "default": "application/json" }, "submissionSchema": { - "$recursiveRef": "http://json-schema.org/draft-08/hyper-schema", + "$recursiveRef": "http://json-schema.org/draft/2019-03/hyper-schema", "default": true }, "$comment": { diff --git a/applicator.json b/meta/applicator.json similarity index 87% rename from applicator.json rename to meta/applicator.json index de770dd2..88d2af0d 100644 --- a/applicator.json +++ b/meta/applicator.json @@ -1,10 +1,9 @@ { - "$schema": "http://json-schema.org/draft-08/schema#", - "$id": "https://json-schema.org/draft-08/applicator", + "$schema": "http://json-schema.org/draft/2019-03/schema#", + "$id": "https://json-schema.org/draft/2019-03/meta/applicator", "$recursiveAnchor": true, "$vocabulary": { - "https://json-schema.org/draft-08/vocabularies/core": true, - "https://json-schema.org/draft-08/vocabularies/applicator": true + "https://json-schema.org/draft/2019-03/vocab/applicator": true }, "title": "Applicator vocabulary meta-schema", diff --git a/meta/content.json b/meta/content.json new file mode 100644 index 00000000..a0f722be --- /dev/null +++ b/meta/content.json @@ -0,0 +1,17 @@ +{ + "$schema": "http://json-schema.org/draft/2019-03/schema#", + "$id": "http://json-schema.org/draft/2019-03/meta/content", + "$vocabulary": { + "https://json-schema.org/draft/2019-03/vocab/content": true + }, + "$recursiveAnchor": true, + + "title": "Content vocabulary meta-schema", + + "type": ["object", "boolean"], + "properties": { + "contentMediaType": { "type": "string" }, + "contentEncoding": { "type": "string" }, + "contentSchema": { "$recursiveRef": "#" } + } +} diff --git a/core.json b/meta/core.json similarity index 85% rename from core.json rename to meta/core.json index d845b3dd..cdf52669 100644 --- a/core.json +++ b/meta/core.json @@ -1,9 +1,9 @@ { - "$schema": "http://json-schema.org/draft-08/schema#", - "$id": "https://json-schema.org/draft-08/core", + "$schema": "http://json-schema.org/draft/2019-03/schema#", + "$id": "https://json-schema.org/draft/2019-03/meta/core", "$recursiveAnchor": true, "$vocabulary": { - "https://json-schema.org/draft-08/vocabularies/core": true + "https://json-schema.org/draft/2019-03/vocab/core": true }, "title": "Core vocabulary meta-schema", diff --git a/meta/format.json b/meta/format.json new file mode 100644 index 00000000..bf4c8b55 --- /dev/null +++ b/meta/format.json @@ -0,0 +1,14 @@ +{ + "$schema": "http://json-schema.org/draft/2019-03/schema#", + "$id": "http://json-schema.org/draft/2019-03/meta/format", + "$vocabulary": { + "https://json-schema.org/draft/2019-03/vocab/format": true + }, + "$recursiveAnchor": true, + + "title": "Format vocabulary meta-schema", + "type": ["object", "boolean"], + "properties": { + "format": { "type": "string" } + } +} diff --git a/meta/hyper-schema.json b/meta/hyper-schema.json new file mode 100644 index 00000000..a9ccf874 --- /dev/null +++ b/meta/hyper-schema.json @@ -0,0 +1,29 @@ +{ + "$schema": "http://json-schema.org/draft/2019-03/hyper-schema#", + "$id": "http://json-schema.org/draft/2019-03/meta/hyper-schema", + "$vocabulary": { + "https://json-schema.org/draft/2019-03/vocab/hyper-schema": true + }, + "$recursiveAnchor": true, + + "title": "JSON Hyper-Schema Vocabulary Schema", + "type": ["object", "boolean"], + "properties": { + "base": { + "type": "string", + "format": "uri-template" + }, + "links": { + "type": "array", + "items": { + "$ref": "http://json-schema.org/draft/2019-03/links" + } + } + }, + "links": [ + { + "rel": "self", + "href": "{+%24id}" + } + ] +} diff --git a/meta/meta-data.json b/meta/meta-data.json new file mode 100644 index 00000000..0f3a493d --- /dev/null +++ b/meta/meta-data.json @@ -0,0 +1,33 @@ +{ + "$schema": "http://json-schema.org/draft/2019-03/schema#", + "$id": "http://json-schema.org/draft/2019-03/meta/meta-data", + "$vocabulary": { + "https://json-schema.org/draft/2019-03/vocab/meta-data": true + }, + "$recursiveAnchor": true, + + "title": "Meta-data vocabulary meta-schema", + + "type": ["object", "boolean"], + "properties": { + "title": { + "type": "string" + }, + "description": { + "type": "string" + }, + "default": true, + "readOnly": { + "type": "boolean", + "default": false + }, + "writeOnly": { + "type": "boolean", + "default": false + }, + "examples": { + "type": "array", + "items": true + } + } +} diff --git a/meta/validation.json b/meta/validation.json new file mode 100644 index 00000000..9098523a --- /dev/null +++ b/meta/validation.json @@ -0,0 +1,101 @@ +{ + "$schema": "http://json-schema.org/draft/2019-03/schema#", + "$id": "http://json-schema.org/draft/2019-03/meta/validation", + "$vocabulary": { + "https://json-schema.org/draft/2019-03/vocab/validation": true + }, + "$recursiveAnchor": true, + + "title": "Validation vocabulary meta-schema", + "$defs": { + "nonNegativeInteger": { + "type": "integer", + "minimum": 0 + }, + "nonNegativeIntegerDefault0": { + "$ref": "#/$defs/nonNegativeInteger", + "default": 0 + }, + "simpleTypes": { + "enum": [ + "array", + "boolean", + "integer", + "null", + "number", + "object", + "string" + ] + }, + "stringArray": { + "type": "array", + "items": { "type": "string" }, + "uniqueItems": true, + "default": [] + } + }, + "type": ["object", "boolean"], + "properties": { + "multipleOf": { + "type": "number", + "exclusiveMinimum": 0 + }, + "maximum": { + "type": "number" + }, + "exclusiveMaximum": { + "type": "number" + }, + "minimum": { + "type": "number" + }, + "exclusiveMinimum": { + "type": "number" + }, + "maxLength": { "$ref": "#/$defs/nonNegativeInteger" }, + "minLength": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, + "pattern": { + "type": "string", + "format": "regex" + }, + "maxItems": { "$ref": "#/$defs/nonNegativeInteger" }, + "minItems": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, + "uniqueItems": { + "type": "boolean", + "default": false + }, + "contains": { "$recursiveRef": "#" }, + "maxContains": { "$ref": "#/$defs/nonNegativeInteger" }, + "minContains": { + "$ref": "#/$defs/nonNegativeInteger", + "default": 1 + }, + "maxProperties": { "$ref": "#/$defs/nonNegativeInteger" }, + "minProperties": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, + "required": { "$ref": "#/$defs/stringArray" }, + "dependentRequired": { + "type": "object", + "additionalProperties": { + "$ref": "#/$defs/stringArray" + } + }, + "const": true, + "enum": { + "type": "array", + "items": true, + "minItems": 1, + "uniqueItems": true + }, + "type": { + "anyOf": [ + { "$ref": "#/$defs/simpleTypes" }, + { + "type": "array", + "items": { "$ref": "#/$defs/simpleTypes" }, + "minItems": 1, + "uniqueItems": true + } + ] + } + } +} diff --git a/hyper-schema-output.json b/output/hyper-schema.json similarity index 91% rename from hyper-schema-output.json rename to output/hyper-schema.json index 53593fa2..9a65132a 100644 --- a/hyper-schema-output.json +++ b/output/hyper-schema.json @@ -1,11 +1,11 @@ { - "$schema": "http://json-schema.org/draft-08/schema#", - "$id": "http://json-schema.org/draft-08/hyper-schema-output", + "$schema": "http://json-schema.org/draft/2019-03/schema#", + "$id": "http://json-schema.org/draft/2019-03/output/hyper-schema", "title": "JSON Hyper-Schema Output", "type": "array", "items": { "allOf": [ - {"$ref": "http://json-schema.org/draft-08/links#/$defs/noRequiredFields" } + {"$ref": "http://json-schema.org/draft/2019-03/links#/$defs/noRequiredFields" } ], "type": "object", "required": [ diff --git a/schema-output.json b/output/schema.json similarity index 94% rename from schema-output.json rename to output/schema.json index 579ef8bb..5d6fbb9f 100644 --- a/schema-output.json +++ b/output/schema.json @@ -1,6 +1,6 @@ { - "$schema": "http://json-schema.org/draft-08/schema#", - "$id": "http://json-schema.org/draft-08/schema-output#", + "$schema": "http://json-schema.org/draft/2019-03/schema#", + "$id": "http://json-schema.org/draft/2019-03/output/schema", "description": "A schema that validates the minimum requirements for validation output", "$defs": { "outputUnit":{ @@ -82,4 +82,4 @@ { "$ref": "#/$defs/detailed" }, { "$ref": "#/$defs/verbose" } ] -} \ No newline at end of file +} diff --git a/standardized-output-verbose.json b/output/verbose-example.json similarity index 100% rename from standardized-output-verbose.json rename to output/verbose-example.json diff --git a/schema.json b/schema.json index 281912c6..d30c02a0 100644 --- a/schema.json +++ b/schema.json @@ -1,42 +1,25 @@ { - "$schema": "http://json-schema.org/draft-08/schema#", - "$id": "http://json-schema.org/draft-08/schema#", + "$schema": "http://json-schema.org/draft/2019-03/schema#", + "$id": "http://json-schema.org/draft/2019-03/schema#", + "$vocabulary": { + "https://json-schema.org/draft/2019/03/vocab/core": true, + "https://json-schema.org/draft/2019/03/vocab/applicator": true, + "https://json-schema.org/draft/2019/03/vocab/validation": true, + "https://json-schema.org/draft/2019/03/vocab/meta-data": true, + "https://json-schema.org/draft/2019/03/vocab/format": true, + "https://json-schema.org/draft/2019/03/vocab/content": true + }, "$recursiveAnchor": true, - "$recursiveRef": "core", "title": "Core and Validation specifications meta-schema", - "$defs": { - "schemaArray": { - "type": "array", - "minItems": 1, - "items": { "$recursiveRef": "#" } - }, - "nonNegativeInteger": { - "type": "integer", - "minimum": 0 - }, - "nonNegativeIntegerDefault0": { - "$ref": "#/$defs/nonNegativeInteger", - "default": 0 - }, - "simpleTypes": { - "enum": [ - "array", - "boolean", - "integer", - "null", - "number", - "object", - "string" - ] - }, - "stringArray": { - "type": "array", - "items": { "type": "string" }, - "uniqueItems": true, - "default": [] - } - }, + "allOf": [ + {"$ref": "meta/core"}, + {"$ref": "meta/applicator"}, + {"$ref": "meta/validation"}, + {"$ref": "meta/meta-data"}, + {"$ref": "meta/format"}, + {"$ref": "meta/content"} + ], "type": ["object", "boolean"], "properties": { "definitions": { @@ -45,127 +28,15 @@ "additionalProperties": { "$recursiveRef": "#" }, "default": {} }, - "title": { - "type": "string" - }, - "description": { - "type": "string" - }, - "default": true, - "readOnly": { - "type": "boolean", - "default": false - }, - "examples": { - "type": "array", - "items": true - }, - "multipleOf": { - "type": "number", - "exclusiveMinimum": 0 - }, - "maximum": { - "type": "number" - }, - "exclusiveMaximum": { - "type": "number" - }, - "minimum": { - "type": "number" - }, - "exclusiveMinimum": { - "type": "number" - }, - "maxLength": { "$ref": "#/$defs/nonNegativeInteger" }, - "minLength": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, - "pattern": { - "type": "string", - "format": "regex" - }, - "additionalItems": { "$recursiveRef": "#" }, - "items": { - "anyOf": [ - { "$recursiveRef": "#" }, - { "$ref": "#/$defs/schemaArray" } - ] - }, - "maxItems": { "$ref": "#/$defs/nonNegativeInteger" }, - "minItems": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, - "uniqueItems": { - "type": "boolean", - "default": false - }, - "contains": { "$recursiveRef": "#" }, - "maxContains": { "$ref": "#/$defs/nonNegativeInteger" }, - "minContains": { - "$ref": "#/$defs/nonNegativeInteger", - "default": 1 - }, - "maxProperties": { "$ref": "#/$defs/nonNegativeInteger" }, - "minProperties": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, - "required": { "$ref": "#/$defs/stringArray" }, - "additionalProperties": { "$recursiveRef": "#" }, - "properties": { - "type": "object", - "additionalProperties": { "$recursiveRef": "#" }, - "default": {} - }, - "patternProperties": { - "type": "object", - "additionalProperties": { "$recursiveRef": "#" }, - "propertyNames": { "format": "regex" }, - "default": {} - }, - "dependentSchemas": { - "type": "object", - "additionalProperties": { - "$recursiveRef": "#" - } - }, - "dependentRequired": { - "type": "object", - "additionalProperties": { - "$ref": "#/$defs/stringArray" - } - }, "dependencies": { "$comment": "\"dependencies\" is no longer a keyword, but schema authors should avoid redefining it to facilitate a smooth transition to \"dependentSchemas\" and \"dependentRequired\"", "type": "object", "additionalProperties": { "anyOf": [ { "$recursiveRef": "#" }, - { "$ref": "#/$defs/stringArray" } + { "$ref": "meta/validation#/$defs/stringArray" } ] } - }, - "propertyNames": { "$recursiveRef": "#" }, - "const": true, - "enum": { - "type": "array", - "items": true, - "minItems": 1, - "uniqueItems": true - }, - "type": { - "anyOf": [ - { "$ref": "#/$defs/simpleTypes" }, - { - "type": "array", - "items": { "$ref": "#/$defs/simpleTypes" }, - "minItems": 1, - "uniqueItems": true - } - ] - }, - "format": { "type": "string" }, - "contentMediaType": { "type": "string" }, - "contentEncoding": { "type": "string" }, - "if": { "$recursiveRef": "#" }, - "then": { "$recursiveRef": "#" }, - "else": { "$recursiveRef": "#" }, - "allOf": { "$ref": "#/$defs/schemaArray" }, - "anyOf": { "$ref": "#/$defs/schemaArray" }, - "oneOf": { "$ref": "#/$defs/schemaArray" }, - "not": { "$recursiveRef": "#" } + } } } From 5e4cca4f00de4fd65ce14502365194bcbc09e9f7 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 26 Feb 2019 17:51:10 -0800 Subject: [PATCH 010/780] Put meta-schema keywords in standard order This is mostly about the self-describing keywords near the top, but also settled on moving "$defs" to the end to avoid obscuring the high-level structure of the schema. --- meta/applicator.json | 16 ++++++------- meta/core.json | 2 +- meta/validation.json | 54 ++++++++++++++++++++++---------------------- output/schema.json | 15 ++++++------ 4 files changed, 44 insertions(+), 43 deletions(-) diff --git a/meta/applicator.json b/meta/applicator.json index 88d2af0d..9e5ed560 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -1,19 +1,12 @@ { "$schema": "http://json-schema.org/draft/2019-03/schema#", "$id": "https://json-schema.org/draft/2019-03/meta/applicator", - "$recursiveAnchor": true, "$vocabulary": { "https://json-schema.org/draft/2019-03/vocab/applicator": true }, + "$recursiveAnchor": true, "title": "Applicator vocabulary meta-schema", - "$defs": { - "schemaArray": { - "type": "array", - "minItems": 1, - "items": { "$recursiveRef": "#" } - } - }, "properties": { "additionalItems": { "$recursiveRef": "#" }, "unevaluatedItems": { "$recursiveRef": "#" }, @@ -56,5 +49,12 @@ "anyOf": { "$ref": "#/$defs/schemaArray" }, "oneOf": { "$ref": "#/$defs/schemaArray" }, "not": { "$recursiveRef": "#" } + }, + "$defs": { + "schemaArray": { + "type": "array", + "minItems": 1, + "items": { "$recursiveRef": "#" } + } } } diff --git a/meta/core.json b/meta/core.json index cdf52669..0e7363f7 100644 --- a/meta/core.json +++ b/meta/core.json @@ -1,10 +1,10 @@ { "$schema": "http://json-schema.org/draft/2019-03/schema#", "$id": "https://json-schema.org/draft/2019-03/meta/core", - "$recursiveAnchor": true, "$vocabulary": { "https://json-schema.org/draft/2019-03/vocab/core": true }, + "$recursiveAnchor": true, "title": "Core vocabulary meta-schema", "type": ["object", "boolean"], diff --git a/meta/validation.json b/meta/validation.json index 9098523a..cf5d49e8 100644 --- a/meta/validation.json +++ b/meta/validation.json @@ -7,33 +7,6 @@ "$recursiveAnchor": true, "title": "Validation vocabulary meta-schema", - "$defs": { - "nonNegativeInteger": { - "type": "integer", - "minimum": 0 - }, - "nonNegativeIntegerDefault0": { - "$ref": "#/$defs/nonNegativeInteger", - "default": 0 - }, - "simpleTypes": { - "enum": [ - "array", - "boolean", - "integer", - "null", - "number", - "object", - "string" - ] - }, - "stringArray": { - "type": "array", - "items": { "type": "string" }, - "uniqueItems": true, - "default": [] - } - }, "type": ["object", "boolean"], "properties": { "multipleOf": { @@ -97,5 +70,32 @@ } ] } + }, + "$defs": { + "nonNegativeInteger": { + "type": "integer", + "minimum": 0 + }, + "nonNegativeIntegerDefault0": { + "$ref": "#/$defs/nonNegativeInteger", + "default": 0 + }, + "simpleTypes": { + "enum": [ + "array", + "boolean", + "integer", + "null", + "number", + "object", + "string" + ] + }, + "stringArray": { + "type": "array", + "items": { "type": "string" }, + "uniqueItems": true, + "default": [] + } } } diff --git a/output/schema.json b/output/schema.json index 5d6fbb9f..cfd692b8 100644 --- a/output/schema.json +++ b/output/schema.json @@ -2,6 +2,13 @@ "$schema": "http://json-schema.org/draft/2019-03/schema#", "$id": "http://json-schema.org/draft/2019-03/output/schema", "description": "A schema that validates the minimum requirements for validation output", + + "oneOf": [ + { "$ref": "#/$defs/flag" }, + { "$ref": "#/$defs/basic" }, + { "$ref": "#/$defs/detailed" }, + { "$ref": "#/$defs/verbose" } + ], "$defs": { "outputUnit":{ "properties": { @@ -75,11 +82,5 @@ "basic": { "$ref": "#/outputUnit" }, "detailed": { "$ref": "#/outputUnit" }, "verbose": { "$ref": "#/outputUnit" } - }, - "oneOf": [ - { "$ref": "#/$defs/flag" }, - { "$ref": "#/$defs/basic" }, - { "$ref": "#/$defs/detailed" }, - { "$ref": "#/$defs/verbose" } - ] + } } From 8c1f35e6ae3c19329ded22677e0cc566f7617604 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 23 Feb 2019 01:19:14 -0800 Subject: [PATCH 011/780] Update hostname RFC reference RFC 1123 modifies the syntax to allow a leading digit, which is present in modern practice. --- jsonschema-validation.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 21200f34..7bfd2da6 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1,6 +1,6 @@ + @@ -616,12 +616,12 @@ representation for an Internet hostname as follows: - As defined by RFC 1034, section 3.1, + As defined by RFC 1123, section 2.1, including host names produced using the Punycode algorithm specified in RFC 5891, section 4.4. - As defined by either RFC 1034 as for hostname, or an + As defined by either RFC 1123 as for hostname, or an internationalized hostname as defined by RFC 5890, section 2.3.2.3. @@ -1056,7 +1056,7 @@ &RFC2119; - &RFC1034; + &RFC1123; &RFC2045; &RFC2046; &RFC2673; From 4faa3c72af0fa4e741ffdd4fd0122cd5af50bcdc Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sun, 17 Mar 2019 20:33:36 -0700 Subject: [PATCH 012/780] Fix and update mets/vocab dates Should always be hyphen. Also, admit that this is not going to be done this month either :-/ --- hyper-schema.json | 22 +++++++++++----------- jsonschema-core.xml | 38 +++++++++++++++++++------------------- jsonschema-hyperschema.xml | 22 +++++++++++----------- jsonschema-validation.xml | 18 +++++++++--------- links.json | 12 ++++++------ meta/applicator.json | 6 +++--- meta/content.json | 6 +++--- meta/core.json | 6 +++--- meta/format.json | 6 +++--- meta/hyper-schema.json | 8 ++++---- meta/meta-data.json | 6 +++--- meta/validation.json | 6 +++--- output/hyper-schema.json | 6 +++--- output/schema.json | 4 ++-- schema.json | 16 ++++++++-------- 15 files changed, 91 insertions(+), 91 deletions(-) diff --git a/hyper-schema.json b/hyper-schema.json index 96013fdd..07d331dd 100644 --- a/hyper-schema.json +++ b/hyper-schema.json @@ -1,21 +1,21 @@ { - "$schema": "http://json-schema.org/draft/2019-03/hyper-schema#", - "$id": "http://json-schema.org/draft/2019-03/hyper-schema", + "$schema": "http://json-schema.org/draft/2019-04/hyper-schema#", + "$id": "http://json-schema.org/draft/2019-04/hyper-schema", "$vocabulary": { - "https://json-schema.org/draft/2019/03/vocab/core": true, - "https://json-schema.org/draft/2019/03/vocab/applicator": true, - "https://json-schema.org/draft/2019/03/vocab/validation": true, - "https://json-schema.org/draft/2019/03/vocab/meta-data": true, - "https://json-schema.org/draft/2019/03/vocab/format": true, - "https://json-schema.org/draft/2019/03/vocab/content": true, - "https://json-schema.org/draft/2019/03/vocab/hyper-schema": true + "https://json-schema.org/draft/2019-04/vocab/core": true, + "https://json-schema.org/draft/2019-04/vocab/applicator": true, + "https://json-schema.org/draft/2019-04/vocab/validation": true, + "https://json-schema.org/draft/2019-04/vocab/meta-data": true, + "https://json-schema.org/draft/2019-04/vocab/format": true, + "https://json-schema.org/draft/2019-04/vocab/content": true, + "https://json-schema.org/draft/2019-04/vocab/hyper-schema": true }, "$recursiveAnchor": true, "title": "JSON Hyper-Schema", "allOf": [ - {"$ref": "http://json-schema.org/draft/2019-03/schema"}, - {"$ref": "http://json-schema.org/draft/2019-03/meta/hyper-schema"} + {"$ref": "http://json-schema.org/draft/2019-04/schema"}, + {"$ref": "http://json-schema.org/draft/2019-04/meta/hyper-schema"} ], "links": [ { diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 9093bf35..8f5d6365 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1058,11 +1058,11 @@ The current URI for the Core vocabulary is: - . + . The current URI for the corresponding meta-schema is: - . + . Updated vocabulary and meta-schema URIs MAY be published between @@ -1088,16 +1088,16 @@ The current URI for this vocabulary, known as the Applicator vocabulary, is: - . + . The current URI for the corresponding meta-schema is: - . + . Updated vocabulary and meta-schema URIs MAY be published between @@ -2493,7 +2493,7 @@
@@ -2569,7 +2569,7 @@ http://json-schema.org/draft/2019-03/schema#/$defs/nonNegativeInteger/minimum Because this output structure can be quite large, a smaller example is given here for brevity. The URI of the full output structure of the example above is: - . + .
@@ -2789,7 +2789,7 @@ http://json-schema.org/draft/2019-03/schema#/$defs/nonNegativeInteger/minimum // schema { "$id": "http://example.com/polygon#", - "$schema": "http://json-schema.org/draft/2019-03/schema#", + "$schema": "http://json-schema.org/draft/2019-04/schema#", "type": "object", "properties": { "validProp": true, @@ -2843,7 +2843,7 @@ http://json-schema.org/draft/2019-03/schema#/$defs/nonNegativeInteger/minimum For convenience, JSON Schema has been provided to validate output generated by implementations. Its URI is: - . + .
diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index 05fc523b..e77f077d 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -288,24 +288,24 @@
The current URI for the JSON Hyper-Schema meta-schema is - . + . The current URI for this vocabulary, known as the Hyper-Schema vocabulary, is: - . + . The current URI for the corresponding meta-schema, which differs from the convenience meta-schema above in that it describes only the hyper-schema keywords ("base" and "link") is: - . + . The link description format can be used without JSON Schema, and use of this format can be declared by referencing the normative link description schema as the schema for the data structure that uses the links. The URI of the normative link description schema is: - . + . JSON Hyper-Schema implementations are free to provide output in any format. @@ -316,7 +316,7 @@ It is RECOMMENDED that implementations be capable of producing output in this format to facilitated testing. The URI of the JSON Schema describing the recommended output format is - . + . Updated vocabulary and meta-schema URIs MAY be published between @@ -1624,7 +1624,7 @@ Link: ; rel="describedBy" ; rel="describedBy" ; rel="describedBy" ; rev="up" ; rev="up" ; rev="up" The current URI for the JSON Schema Validation meta-schema is - . + . For schema author convenience, this meta-schema describes all vocabularies defined in this specification and the JSON Schema Core specification. Individual vocabulary and vocabulary meta-schema URIs are given for @@ -218,11 +218,11 @@ The current URI for this vocabulary, known as the Validation vocabulary, is: - . + . The current URI for the corresponding meta-schema is: - . + .
@@ -539,11 +539,11 @@ The current URI for this vocabulary, known as the Format vocabulary, is: - . + . The current URI for the corresponding meta-schema is: - . + .
@@ -784,11 +784,11 @@ The current URI for this vocabulary, known as the Content vocabulary, is: - . + . The current URI for the corresponding meta-schema is: - . + .
@@ -972,11 +972,11 @@ The current URI for this vocabulary, known as the Meta-Data vocabulary, is: - . + . The current URI for the corresponding meta-schema is: - . + .
diff --git a/links.json b/links.json index ddcca685..a5d5469c 100644 --- a/links.json +++ b/links.json @@ -1,6 +1,6 @@ { - "$schema": "http://json-schema.org/draft/2019-03/hyper-schema#", - "$id": "http://json-schema.org/draft/2019-03/links", + "$schema": "http://json-schema.org/draft/2019-04/hyper-schema#", + "$id": "http://json-schema.org/draft/2019-04/links", "title": "Link Description Object", "allOf": [ { "required": [ "rel", "href" ] }, @@ -36,7 +36,7 @@ "format": "uri-template" }, "hrefSchema": { - "$recursiveRef": "http://json-schema.org/draft/2019-03/hyper-schema", + "$recursiveRef": "http://json-schema.org/draft/2019-04/hyper-schema", "default": false }, "templatePointers": { @@ -63,7 +63,7 @@ "type": "string" }, "targetSchema": { - "$recursiveRef": "http://json-schema.org/draft/2019-03/hyper-schema", + "$recursiveRef": "http://json-schema.org/draft/2019-04/hyper-schema", "default": true }, "targetMediaType": { @@ -71,7 +71,7 @@ }, "targetHints": { }, "headerSchema": { - "$recursiveRef": "http://json-schema.org/draft/2019-03/hyper-schema", + "$recursiveRef": "http://json-schema.org/draft/2019-04/hyper-schema", "default": true }, "submissionMediaType": { @@ -79,7 +79,7 @@ "default": "application/json" }, "submissionSchema": { - "$recursiveRef": "http://json-schema.org/draft/2019-03/hyper-schema", + "$recursiveRef": "http://json-schema.org/draft/2019-04/hyper-schema", "default": true }, "$comment": { diff --git a/meta/applicator.json b/meta/applicator.json index 9e5ed560..43b104ef 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-03/schema#", - "$id": "https://json-schema.org/draft/2019-03/meta/applicator", + "$schema": "http://json-schema.org/draft/2019-04/schema#", + "$id": "https://json-schema.org/draft/2019-04/meta/applicator", "$vocabulary": { - "https://json-schema.org/draft/2019-03/vocab/applicator": true + "https://json-schema.org/draft/2019-04/vocab/applicator": true }, "$recursiveAnchor": true, diff --git a/meta/content.json b/meta/content.json index a0f722be..2262099a 100644 --- a/meta/content.json +++ b/meta/content.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-03/schema#", - "$id": "http://json-schema.org/draft/2019-03/meta/content", + "$schema": "http://json-schema.org/draft/2019-04/schema#", + "$id": "http://json-schema.org/draft/2019-04/meta/content", "$vocabulary": { - "https://json-schema.org/draft/2019-03/vocab/content": true + "https://json-schema.org/draft/2019-04/vocab/content": true }, "$recursiveAnchor": true, diff --git a/meta/core.json b/meta/core.json index 0e7363f7..6ba4329e 100644 --- a/meta/core.json +++ b/meta/core.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-03/schema#", - "$id": "https://json-schema.org/draft/2019-03/meta/core", + "$schema": "http://json-schema.org/draft/2019-04/schema#", + "$id": "https://json-schema.org/draft/2019-04/meta/core", "$vocabulary": { - "https://json-schema.org/draft/2019-03/vocab/core": true + "https://json-schema.org/draft/2019-04/vocab/core": true }, "$recursiveAnchor": true, diff --git a/meta/format.json b/meta/format.json index bf4c8b55..02970f37 100644 --- a/meta/format.json +++ b/meta/format.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-03/schema#", - "$id": "http://json-schema.org/draft/2019-03/meta/format", + "$schema": "http://json-schema.org/draft/2019-04/schema#", + "$id": "http://json-schema.org/draft/2019-04/meta/format", "$vocabulary": { - "https://json-schema.org/draft/2019-03/vocab/format": true + "https://json-schema.org/draft/2019-04/vocab/format": true }, "$recursiveAnchor": true, diff --git a/meta/hyper-schema.json b/meta/hyper-schema.json index a9ccf874..8f427d4b 100644 --- a/meta/hyper-schema.json +++ b/meta/hyper-schema.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-03/hyper-schema#", - "$id": "http://json-schema.org/draft/2019-03/meta/hyper-schema", + "$schema": "http://json-schema.org/draft/2019-04/hyper-schema#", + "$id": "http://json-schema.org/draft/2019-04/meta/hyper-schema", "$vocabulary": { - "https://json-schema.org/draft/2019-03/vocab/hyper-schema": true + "https://json-schema.org/draft/2019-04/vocab/hyper-schema": true }, "$recursiveAnchor": true, @@ -16,7 +16,7 @@ "links": { "type": "array", "items": { - "$ref": "http://json-schema.org/draft/2019-03/links" + "$ref": "http://json-schema.org/draft/2019-04/links" } } }, diff --git a/meta/meta-data.json b/meta/meta-data.json index 0f3a493d..a5eee1c2 100644 --- a/meta/meta-data.json +++ b/meta/meta-data.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-03/schema#", - "$id": "http://json-schema.org/draft/2019-03/meta/meta-data", + "$schema": "http://json-schema.org/draft/2019-04/schema#", + "$id": "http://json-schema.org/draft/2019-04/meta/meta-data", "$vocabulary": { - "https://json-schema.org/draft/2019-03/vocab/meta-data": true + "https://json-schema.org/draft/2019-04/vocab/meta-data": true }, "$recursiveAnchor": true, diff --git a/meta/validation.json b/meta/validation.json index cf5d49e8..4665fe57 100644 --- a/meta/validation.json +++ b/meta/validation.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-03/schema#", - "$id": "http://json-schema.org/draft/2019-03/meta/validation", + "$schema": "http://json-schema.org/draft/2019-04/schema#", + "$id": "http://json-schema.org/draft/2019-04/meta/validation", "$vocabulary": { - "https://json-schema.org/draft/2019-03/vocab/validation": true + "https://json-schema.org/draft/2019-04/vocab/validation": true }, "$recursiveAnchor": true, diff --git a/output/hyper-schema.json b/output/hyper-schema.json index 9a65132a..04e6e05a 100644 --- a/output/hyper-schema.json +++ b/output/hyper-schema.json @@ -1,11 +1,11 @@ { - "$schema": "http://json-schema.org/draft/2019-03/schema#", - "$id": "http://json-schema.org/draft/2019-03/output/hyper-schema", + "$schema": "http://json-schema.org/draft/2019-04/schema#", + "$id": "http://json-schema.org/draft/2019-04/output/hyper-schema", "title": "JSON Hyper-Schema Output", "type": "array", "items": { "allOf": [ - {"$ref": "http://json-schema.org/draft/2019-03/links#/$defs/noRequiredFields" } + {"$ref": "http://json-schema.org/draft/2019-04/links#/$defs/noRequiredFields" } ], "type": "object", "required": [ diff --git a/output/schema.json b/output/schema.json index cfd692b8..d9ab2cd1 100644 --- a/output/schema.json +++ b/output/schema.json @@ -1,6 +1,6 @@ { - "$schema": "http://json-schema.org/draft/2019-03/schema#", - "$id": "http://json-schema.org/draft/2019-03/output/schema", + "$schema": "http://json-schema.org/draft/2019-04/schema#", + "$id": "http://json-schema.org/draft/2019-04/output/schema", "description": "A schema that validates the minimum requirements for validation output", "oneOf": [ diff --git a/schema.json b/schema.json index d30c02a0..74215b30 100644 --- a/schema.json +++ b/schema.json @@ -1,13 +1,13 @@ { - "$schema": "http://json-schema.org/draft/2019-03/schema#", - "$id": "http://json-schema.org/draft/2019-03/schema#", + "$schema": "http://json-schema.org/draft/2019-04/schema#", + "$id": "http://json-schema.org/draft/2019-04/schema#", "$vocabulary": { - "https://json-schema.org/draft/2019/03/vocab/core": true, - "https://json-schema.org/draft/2019/03/vocab/applicator": true, - "https://json-schema.org/draft/2019/03/vocab/validation": true, - "https://json-schema.org/draft/2019/03/vocab/meta-data": true, - "https://json-schema.org/draft/2019/03/vocab/format": true, - "https://json-schema.org/draft/2019/03/vocab/content": true + "https://json-schema.org/draft/2019-04/vocab/core": true, + "https://json-schema.org/draft/2019-04/vocab/applicator": true, + "https://json-schema.org/draft/2019-04/vocab/validation": true, + "https://json-schema.org/draft/2019-04/vocab/meta-data": true, + "https://json-schema.org/draft/2019-04/vocab/format": true, + "https://json-schema.org/draft/2019-04/vocab/content": true }, "$recursiveAnchor": true, From 56c227136f8e3726862c30f4c3347883b360def1 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 22 Feb 2019 19:59:20 -0800 Subject: [PATCH 013/780] Note undefined behavior with unknown $ref targets The most common situation here, which are basically alternate names for "definitions" or "$defs", will generally work, but this makes clear that there is no obligation to attempt to guarantee the proper behavior in such situations. We might want to narrow this behavior down in the future, but for now this at least clearly removes any possible burdensome and totally impractical inferencing requirements. --- jsonschema-core.xml | 23 +++++++++++++++++++++++ jsonschema-validation.xml | 5 +++-- 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e4736366..e785ea77 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1540,6 +1540,29 @@
+
+ + Subschema objects (or booleans) are recognized by their use with known + applicator keywords. These keywords may be the standard applicators + from this document, or extension keywords from a known vocabulary, or + implementation-specific custom keywords. + + + Multi-level structures of unknown keywords are capable of introducing + nested subschemas, which would be subject to the processing rules for + "$id". Therefore, having a reference target in such an unrecognized + structure cannot be reliably implemented, and the resulting behavior + is undefined. + + + Note that single-level custom keywords with identical syntax and + semantics to "$defs" do not allow for any intervening "$id" keywords, + and therefore will behave correctly under implementations that attempt + to use any reference target as a schema. However, this behavior is + implementation-specific and MUST NOT be relied upon for interoperability. + +
+
The use of URIs to identify remote schemas does not necessarily mean anything is downloaded, diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 7df5aa0b..6a29d96f 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -887,8 +887,9 @@ Instances described by this schema should be strings containing HTML, using - whatever character set the JSON string was decoded into (default is - Unicode). + whatever character set the JSON string was decoded into. Per section 8.1 of + RFC 8259, outside of an entirely closed + system, this MUST be UTF-8. From e741b8e98c430b2330895d9d6befe2ca4a3a8bc8 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sun, 3 Mar 2019 16:08:03 -0800 Subject: [PATCH 014/780] Clarify non-schema $ref targets Whether the target is definitely not a schema or simply unknown and therefore not necessarily a schema, the result of $ref-ing it is undefined. Only references to targets that the implementation can determine with certainty to be schemas have well-defined behavior. --- jsonschema-core.xml | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e785ea77..e538db0c 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1552,7 +1552,19 @@ nested subschemas, which would be subject to the processing rules for "$id". Therefore, having a reference target in such an unrecognized structure cannot be reliably implemented, and the resulting behavior - is undefined. + is undefined. Similarly, a reference target under a known keyword, + for which the value is known not to be a schema, results in undefined + behavior in order to avoid burdening implementations with the need + to detect such targets. + + These scenarios are analogous to fetching a schema over HTTP + but receiving a response with a Content-Type other than + application/schema+json. An implementation can certainly + try to interpret it as a schema, but the origin server + offered no guarantee that it actually is any such thing. + Therefore, interpreting it as such has security implications + and may produce unpredictable results. + Note that single-level custom keywords with identical syntax and From af6231dc9c6f4be984b236780eebe2b8c2b0b8f4 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 10 May 2019 15:24:52 -0700 Subject: [PATCH 015/780] Fix #74: add "deprecated" keyword --- jsonschema-validation.xml | 26 +++++++++++++++++++++++--- meta/meta-data.json | 4 ++++ 2 files changed, 27 insertions(+), 3 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 7184f6e5..5a70fe15 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -51,7 +51,7 @@ henry@cloudflare.com - + Wellcome Sanger Institute
@@ -956,7 +956,7 @@ "const": { "typ": "JWT", "alg": "HS256" - } + } }, { "type": "object", @@ -967,7 +967,7 @@ } } ] - } + } }]]> @@ -1028,6 +1028,26 @@
+
+ + The value of this keyword MUST be a boolean. When multiple occurrences + of this keyword are applicable to a single sub-instance, the resulting + value MUST be true if any occurrence specifies a true value, and MUST + be false otherwise. + + + If "deprecated" has a value of boolean true, it indicates that the property + MAY be removed from the document in the future. + + + An instance document that is marked as "deprecated" for the entire document + means the entire document MAY be removed in the future. + + + Omitting this keyword has the same behavior as a value of false. + +
+
The value of these keywords MUST be a boolean. When multiple occurrences diff --git a/meta/meta-data.json b/meta/meta-data.json index a5eee1c2..1accce67 100644 --- a/meta/meta-data.json +++ b/meta/meta-data.json @@ -17,6 +17,10 @@ "type": "string" }, "default": true, + "deprecated": { + "type": "boolean", + "default": false + }, "readOnly": { "type": "boolean", "default": false From b0d1437e06275a2bf243e13e09fef6a644e9ece4 Mon Sep 17 00:00:00 2001 From: Phil Sturgeon Date: Thu, 16 May 2019 12:23:00 +0200 Subject: [PATCH 016/780] Similar wording to OpenAPI --- jsonschema-validation.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 5a70fe15..1f3084b4 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1036,8 +1036,9 @@ be false otherwise. - If "deprecated" has a value of boolean true, it indicates that the property - MAY be removed from the document in the future. + If "deprecated" has a value of boolean true, it indicates that applications + SHOULD refrain from usage of the declared operation. It MAY mean the property + is going to be removed in the futuree. An instance document that is marked as "deprecated" for the entire document From a51ff12da8f5ba9d6022f0e9f938e3e92e7baae0 Mon Sep 17 00:00:00 2001 From: Phil Sturgeon Date: Fri, 17 May 2019 10:55:55 +0200 Subject: [PATCH 017/780] Feedback from @handrews --- jsonschema-validation.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 1f3084b4..7a08e027 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1037,12 +1037,12 @@ If "deprecated" has a value of boolean true, it indicates that applications - SHOULD refrain from usage of the declared operation. It MAY mean the property - is going to be removed in the futuree. + SHOULD refrain from usage of the declared property. It MAY mean the property + is going to be removed in the future. - An instance document that is marked as "deprecated" for the entire document - means the entire document MAY be removed in the future. + A root schema containing "deprecated" with a value of true indicates the entire + root schema MAY be removed in the future. Omitting this keyword has the same behavior as a value of false. From 003d88571a3f58517d447d8596acc2d6b9726005 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 21 May 2019 17:25:19 +0100 Subject: [PATCH 018/780] Fix enum definition according to spec. Issue: https://github.com/json-schema-org/json-schema-spec/issues/717 enum no longer requires minimum number of items or unique items, in accordance with the spec. --- meta/validation.json | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/meta/validation.json b/meta/validation.json index 4665fe57..5453f078 100644 --- a/meta/validation.json +++ b/meta/validation.json @@ -55,9 +55,7 @@ "const": true, "enum": { "type": "array", - "items": true, - "minItems": 1, - "uniqueItems": true + "items": true }, "type": { "anyOf": [ From b71796101ac894c16bc596193a700451f01c4c6c Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 23 May 2019 11:55:00 +1200 Subject: [PATCH 019/780] Removed `contains` from validation vocab meta-schema --- meta/validation.json | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/validation.json b/meta/validation.json index 4665fe57..f71b066a 100644 --- a/meta/validation.json +++ b/meta/validation.json @@ -37,7 +37,6 @@ "type": "boolean", "default": false }, - "contains": { "$recursiveRef": "#" }, "maxContains": { "$ref": "#/$defs/nonNegativeInteger" }, "minContains": { "$ref": "#/$defs/nonNegativeInteger", From cacf9ad7e18877ee896e3124f1e53c62ae3d37c3 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 10 May 2019 18:04:41 -0700 Subject: [PATCH 020/780] Update my contact info --- jsonschema-core.xml | 5 +++-- jsonschema-hyperschema.xml | 5 +++-- jsonschema-validation.xml | 5 +++-- relative-json-pointer.xml | 5 +++-- 4 files changed, 12 insertions(+), 8 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 51d9a7ae..67fb14ae 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -30,14 +30,15 @@ + Riverbed Technology
- + 680 Folsom St. San Francisco CA USA - henry@cloudflare.com + handrews@riverbed.com
diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index e77f077d..bcdeb39b 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -31,14 +31,15 @@ + Riverbed Technology
- + 680 Folsom St. San Francisco CA USA - henry@cloudflare.com + handrews@riverbed.com
diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 7a08e027..6f29e048 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -41,14 +41,15 @@ + Riverbed Technology
- + 680 Folsom St. San Francisco CA USA - henry@cloudflare.com + handrews@riverbed.com
diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 8162736d..b3ac5ff1 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -28,14 +28,15 @@ + Riverbed Technology
- + 680 Folsom St. San Francisco CA USA - andrews_henry@yahoo.com + handrews@riverbed.com
From e39e1644955fbf3ef549997fd326dccd6ae2ce17 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 25 May 2019 14:23:13 -0700 Subject: [PATCH 021/780] Change logs for draft-handrews-*-02 --- jsonschema-core.xml | 13 +++++++++++++ jsonschema-hyperschema.xml | 6 +++++- jsonschema-validation.xml | 5 +++++ 3 files changed, 23 insertions(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 67fb14ae..362ee1c1 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3273,9 +3273,22 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0 + Update to RFC 8359 for JSON specification Moved "definitions" from the Validation specification here as "$defs" Moved applicator keywords from the Validation specification as their own vocabulary Moved the schema form of "dependencies" from the Validation specification as "dependentSchemas" + Formalized annotation collection + Specified recommended output formats + Defined keyword interactions in terms of annotation and assertion results + Added "unevaluatedProperties" and "unevaluatedItems" + Define "$ref" behavior in terms of the assertion, applicator, and annotation model + Allow keywords adjacent to "$ref" + Note undefined behavior for "$ref" targets involving unknown keywords + Add recursive referencing, primarily for meta-schema extension + Add the concept of formal vocabularies, and how they can be recognized through meta-schemas + Additional guidance on initial base URIs beyond network retrieval + Allow "schema" media type parameter for "application/schema+json" + Better explanation of media type parameters and the HTTP Accept header diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index bcdeb39b..bb48b0e1 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -2752,7 +2752,11 @@ Link: ; rev="up" - + Allow multiple values for "rel" + Clarify that "headerSchema", like "targetHints", should use array values + Clarified link behavior with conditional applicator keywords such as "if" + Added and clarified various examples + Avoid accidentally implying that only POST can be used to create in HTTP diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 6f29e048..d2841417 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1293,6 +1293,11 @@ Moved "definitions" to the core spec as "$defs" Moved applicator keywords to the core spec Renamed the array form of "dependencies" to "dependentRequired", moved the schema form to the core spec + Added "contentSchema" to allow applying a schema to a string-encoded document + Also allow RFC 4648 encodings in "contentEncoding" + Added "minContains" and "maxContains" + Update RFC reference for "hostname" and "idn-hostname" + Add "uuid" and "duration" formats From 30c4301e0a9ba1c3f0ce52cd2867f4d4eb4a5991 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 25 May 2019 15:31:07 -0700 Subject: [PATCH 022/780] Fix cross-references Also a reference within the validation spec was accidentally done as a cross-ref to core, so fixed that as well. --- jsonschema-hyperschema.xml | 14 +++++++------- jsonschema-validation.xml | 4 ++-- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index e77f077d..a2fcd158 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -188,8 +188,8 @@ The terms "applicable" and "attached" are to be interpreted as defined in - Section 3 of the - JSON Schema validation specification. + Section 3.1 of the + JSON Schema core specification. The terms "link", "link context" (or "context"), "link target" (or "target"), @@ -329,8 +329,8 @@
Hyper-schema keywords from all schemas that are applicable to a position - in an instance, as defined by Section - 3 of JSON Schema validation, can be used with that instance. + in an instance, as defined by Section + 3.1 of JSON Schema core, can be used with that instance. When multiple subschemas are applicable to a given sub-instance, all "link" @@ -401,8 +401,8 @@ In JSON Hyper-Schema, the link's context resource is, by default, the sub-instance to which it is attached (as defined by - Section 3 of the JSON Schema - validation specification). This is often not the entire instance + Section 3.1 of the JSON Schema + core specification). This is often not the entire instance document. This default context can be changed using the keywords in this section. @@ -1364,7 +1364,7 @@ for varname in templateData: describing possible HTTP request headers that are relevant to the given resource. - Section 11 of the JSON Schema core specification + Section 13 of the JSON Schema core specification provides guidance on linking instances in a hypermedia system to their schemas. This may be done with network-accessible schemas, or may simply identify schemas which were pre-packaged within the client application. JSON Hyper-Schema diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 7a08e027..247105a3 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -243,7 +243,7 @@
-
+
The value of this keyword MUST be an array. This array SHOULD have at least one element. Elements in the array SHOULD be unique. @@ -263,7 +263,7 @@ Use of this keyword is functionally equivalent to an - "enum" with a single value. + "enum" with a single value. An instance validates successfully against this keyword if its value is From 08720c1d9da9bb8ae87d9b9b2ddd25abf3760318 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 27 May 2019 09:54:40 +0100 Subject: [PATCH 023/780] Update contact information --- jsonschema-core.xml | 1 + jsonschema-validation.xml | 1 + 2 files changed, 2 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 51d9a7ae..0081f25b 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -45,6 +45,7 @@ Wellcome Sanger Institute
bh7@sanger.ac.uk + https://jsonschema.dev
diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 7a08e027..53b28bd9 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -56,6 +56,7 @@ Wellcome Sanger Institute
bh7@sanger.ac.uk + https://jsonschema.dev
From 9a34ddd17658625b315ed8550b7436bc51b2c2dd Mon Sep 17 00:00:00 2001 From: Leonidas Arvanitis Date: Tue, 28 May 2019 17:32:04 +0300 Subject: [PATCH 024/780] Mistyped JSON RFC number in ChangeLog --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index c2f72cfd..3dd0588a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3274,7 +3274,7 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0 - Update to RFC 8359 for JSON specification + Update to RFC 8259 for JSON specification Moved "definitions" from the Validation specification here as "$defs" Moved applicator keywords from the Validation specification as their own vocabulary Moved the schema form of "dependencies" from the Validation specification as "dependentSchemas" From 7cd2594960d450b42c378d3730367b1845d152e8 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 31 May 2019 12:51:46 +0100 Subject: [PATCH 025/780] Include another reference to RFC 3986 to try and make things clearer for schema documents that define no explicit base URI. Align phrasing. --- jsonschema-core.xml | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 3dd0588a..1d21ad8a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1151,6 +1151,11 @@ found, whether that was a network location, a local filesystem, or any other situation identifiable by a URI of any known scheme. + + If a schema document defines no explicit base URI with "$id" (embedded in content), + the base URI is that determined per + RFC 3986 section 5. + If no source is known, or no URI scheme is known for the source, a suitable implementation-specific default URI MAY be used as described in @@ -1164,8 +1169,8 @@ The "$id" keyword defines a URI for the schema, and the base URI that other URI references within the schema are resolved against. A subschema's "$id" is resolved against the base URI of its parent schema. - If no parent sets an explicit base with "$id", the base URI is that of the - entire document, as determined per + If no parent schema defines an explicit base URI with "$id", the base URI + is that of the entire document, as determined per RFC 3986 section 5. From 3bbb2f281517c6a076584647b1ac72d7bedf66ba Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 5 Jun 2019 12:37:00 +0100 Subject: [PATCH 026/780] Create FUNDING.yml Add sponsorship link --- .github/FUNDING.yml | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 .github/FUNDING.yml diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml new file mode 100644 index 00000000..b7c9fe2b --- /dev/null +++ b/.github/FUNDING.yml @@ -0,0 +1,9 @@ +# These are supported funding model platforms + +github: # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2] +patreon: # Replace with a single Patreon username +open_collective: # Replace with a single Open Collective username +ko_fi: relequestual +tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel +community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry +custom: # Replace with a single custom sponsorship URL From ccab20e7f5bc1fe08c553d70f616da1c4ab3eae5 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 8 Jun 2019 10:59:57 +1200 Subject: [PATCH 027/780] fixed note about error message wording --- jsonschema-core.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 51d9a7ae..d69580b9 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2651,9 +2651,10 @@ http://json-schema.org/draft/2019-04/schema#/$defs/nonNegativeInteger/minimum There are only two vertices, but three are required. - Note that neither the error message property nor its wording as depicted in these - examples is not a requirement of this specification. Implementations SHOULD craft - error messages tailored for their audience. + Note that the error message wording as depicted in these examples is not a + requirement of this specification. Implementations SHOULD craft error messages + tailored for their audience or provide a templating mechanism that allows their + users to craft their own messages.
From 91c198ec33b4595fd2b55e01af11e27feacac27b Mon Sep 17 00:00:00 2001 From: Phil Sturgeon Date: Sun, 16 Jun 2019 21:01:40 +0200 Subject: [PATCH 028/780] Deprecated clarfications around arrays --- jsonschema-validation.xml | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 610c18fc..416946b0 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1043,8 +1043,16 @@ is going to be removed in the future. - A root schema containing "deprecated" with a value of true indicates the entire - root schema MAY be removed in the future. + A root schema containing "deprecated" with a value of true indicates that + the entire resource beng described MAY be removed in the future. + + + When the "deprecated" keyword is used to describe an array, it can be used + in the tuple form to deprecate positional schemas. If "deprecated" is used + in the list form it can mark regular "items" as deprecated, whilst allowing + "additionalItems". Vice verse, setting "deprecated" to true inside + "additionalItems" would mark the additional items as deprecated, but not + effect list usage. Omitting this keyword has the same behavior as a value of false. From 5b088711e78d472905ed37481d5ca055f370ba05 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 17 Jun 2019 22:18:50 +0100 Subject: [PATCH 029/780] replace `definitions` with `$defs` Fixes #752 --- jsonschema-core.xml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index c1f9f5e0..a52c5538 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2701,21 +2701,21 @@ http://json-schema.org/draft/2019-04/schema#/$defs/nonNegativeInteger/minimum { "keywordLocation": "#/items/$ref", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point", + "http://example.com/polygon#/$defs/point", "instanceLocation": "#/1", "error": "A subschema had errors." }, { "keywordLocation": "#/items/$ref/required", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/required", + "http://example.com/polygon#/$defs/point/required", "instanceLocation": "#/1", "error": "Required property 'y' not found." }, { "keywordLocation": "#/items/$ref/additionalProperties", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/additionalProperties", + "http://example.com/polygon#/$defs/point/additionalProperties", "instanceLocation": "#/1/z", "error": "Additional property 'z' found but was invalid." }, @@ -2768,14 +2768,14 @@ http://json-schema.org/draft/2019-04/schema#/$defs/nonNegativeInteger/minimum "valid": false, "keywordLocation": "#/items/$ref", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point", + "http://example.com/polygon#/$defs/point", "instanceLocation": "#/1", "errors": [ { "valid": false, "keywordLocation": "#/items/$ref/required", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/required", + "http://example.com/polygon#/$defs/point/required", "instanceLocation": "#/1", "error": "Required property 'y' not found." }, @@ -2783,7 +2783,7 @@ http://json-schema.org/draft/2019-04/schema#/$defs/nonNegativeInteger/minimum "valid": false, "keywordLocation": "#/items/$ref/additionalProperties", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/additionalProperties", + "http://example.com/polygon#/$defs/point/additionalProperties", "instanceLocation": "#/1/z", "error": "Additional property 'z' found but was invalid." } From db5a50cda5b1bb960ff254f9497695aa1ced2b20 Mon Sep 17 00:00:00 2001 From: Phil Sturgeon Date: Thu, 20 Jun 2019 15:25:46 +0200 Subject: [PATCH 030/780] no more tuple --- jsonschema-validation.xml | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 416946b0..77fff604 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1047,12 +1047,10 @@ the entire resource beng described MAY be removed in the future. - When the "deprecated" keyword is used to describe an array, it can be used - in the tuple form to deprecate positional schemas. If "deprecated" is used - in the list form it can mark regular "items" as deprecated, whilst allowing - "additionalItems". Vice verse, setting "deprecated" to true inside - "additionalItems" would mark the additional items as deprecated, but not - effect list usage. + When the "deprecated" keyword is used to describe an array, it's meaning will + vary depending on how "items" is used. If "items" is a single schema, it will + deprecate the contents of an array, but if "items" is an array of schemas it + can be used to deprecate positional schemas. Omitting this keyword has the same behavior as a value of false. From 7924e6ecd42d45fc5a34c97e7d0b02db6630fac9 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 10 Jul 2019 19:58:24 -0700 Subject: [PATCH 031/780] Make a real, appropriately short, Overview section The "Keyword Behavior" section is moved, completely unchanged, to immediately after the "General Considerations", where it makes quite a bit more sense. The "General Considerations" section gives a brief description of the keyword types, which makes a lot more sense before the detailed description rather than after it. The old "Schema Vocabularies" section has mostly been deleted, as it took up a lot of space without adding much. Given that the validation spec now contains four or five vocabularies, enumerating all of them plus hyper-schema (which is highly unlikely to reach RFC at the same time as core) seemed like an overlaod of non-essential information. The introductory paragraph is still useful, so it has been spliced into the appropriate location in the "Meta-Schemas and Vocabularies" section, and the reference anchor has been given to that section as well. The contents of that paragraph are also completely unchanged. --- jsonschema-core.xml | 437 +++++++++++++++++++++----------------------- 1 file changed, 206 insertions(+), 231 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 69da383b..01a7c857 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -143,236 +143,43 @@ This, and related specifications, define keywords allowing authors to describe JSON data in several ways. - -
- - JSON Schema keywords fall into several general behavior categories. - Assertions validate that an instance satisfies constraints, producing - a boolean result. Annotations attach information that applications - may use in any way they see fit. - Applicators apply subschemas to parts of the instance and combine - their results. - - - Extension keywords SHOULD stay within these categories, keeping in mind - that annotations in particular are extremely flexible. Complex behavior - is usually better delegated to applications on the basis of annotation - data than implemented directly as schema keywords. However, extension - keywords MAY define other behaviors for specialized purposes. - - - Evaluating an instance against a schema involves processing all of the - keywords in the schema against the appropriate locations within the instance. - Typically, applicator keywords are processed until a schema object with no - applicators (and therefore no subschemas) is reached. The appropriate - location in the instance is evaluated against the assertion and - annotation keywords in the schema object, and their results are gathered - into the parent schema according to the rules of the applicator. - - - Evaluation of a parent schema object can complete once all of its - subschemas have been evaluated, although in some circumstances evaluation - may be short-circuited due to assertion results. - -
- - Keyword behavior MAY be defined in terms of the annotation results - of subschemas and/or adjacent keywords. - Such keywords MUST NOT result in a circular dependency. - Keywords MAY modify their behavior based on the presence or absence - of another keyword in the same - schema object. - -
-
- - A missing keyword MUST NOT produce a false assertion result, MUST - NOT produce annotation results, and MUST NOT cause any other schema - to be evaluated as part of its own behavioral definition. - However, given that missing keywords do not contribute annotations, - the lack of annotation results may indirectly change the behavior - of other keywords. - - - In some cases, the missing keyword assertion behavior of a keyword is - identical to that produced by a certain value, and keyword definitions - SHOULD note such values where known. However, even if the value which - produces the default behavior would produce annotation results if - present, the default behavior still MUST NOT result in annotations. - - - Because annotation collection can add significant cost in terms of both - computation and memory, implementations MAY opt out of this feature. - Keywords known to an implementation to have assertion or applicator behavior - that depend on annotation results MUST then be treated as errors, unless - an alternate implementation producing the same behavior is available. - Keywords of this sort SHOULD describe reasonable alternate approaches - when appropriate. This approach is demonstrated by the - "" and - "" keywords in this - document. - -
-
- - Applicators allow for building more complex schemas than can be accomplished - with a single schema object. Evaluation of an instance against a - schema document begins by applying - the root schema to the complete instance - document. From there, keywords known as applicators are used to determine - which additional schemas are applied. Such schemas may be applied in-place - to the current location, or to a child location. - - - The schemas to be applied may be present as subschemas comprising all or - part of the keyword's value. Alternatively, an applicator may refer to - a schema elsewhere in the same schema document, or in a different one. - The mechanism for identifying such referenced schemas is defined by the - keyword. - - - Applicator keywords also define how subschema or referenced schema - boolean assertion - results are modified and/or combined to produce the boolean result - of the applicator. Applicators may apply any boolean logic operation - to the assertion results of subschemas, but MUST NOT introduce new - assertion conditions of their own. - - - Annotation results are - combined according to the rules specified by each annotation keyword. - -
- -
- - JSON Schema can be used to assert constraints on a JSON document, which - either passes or fails the assertions. This approach can be used to validate - conformance with the constraints, or document what is needed to satisfy them. - - - JSON Schema implementations produce a single boolean result when evaluating - an instance against schema assertions. - - - An instance can only fail an assertion that is present in the schema. - - -
- - Most assertions only constrain values within a certain - primitive type. When the type of the instance is not of the type - targeted by the keyword, the instance is considered to conform - to the assertion. - - - For example, the "maxLength" keyword from the companion validation - vocabulary will only restrict certain strings - (that are too long) from being valid. If the instance is a number, - boolean, null, array, or object, then it is valid against this assertion. - -
-
- -
- - JSON Schema can annotate an instance with information, whenever the instance - validates against the schema object containing the annotation, and all of its - parent schema objects. The information can be a simple value, or can be - calculated based on the instance contents. - - - Annotations are attached to specific locations in an instance. - Since many subschemas can be applied to any single - location, annotation keywords need to specify any unusual handling of - multiple applicable occurrences of the keyword with different values. - - - The default behavior is simply to collect all values in a list in - indeterminate order. Given the extensibility of keywords, including - applicators, it is not possible to define a universally predictable - order of processing. - - - Unlike assertion results, annotation data can take a wide variety of forms, - which are provided to applications to use as they see fit. JSON Schema - implementations are not expected to make use of the collected information - on behalf of applications. - - - While "short-circuit" evaluation is possible for assertions, collecting - annotations requires examining all schemas that apply to an instance - location, even if they cannot change the overall assertion result. - -
-
- -
- - A JSON Schema vocabulary is a set of keywords defined for a particular - purpose. The vocabulary specifies the meaning of its keywords as - assertions, annotations, and/or any vocabulary-defined keyword category. - - - Several vocabularies are provided as - standards in this and closely related documents. These vocabularies - are used with the core keywords defined as fundamental to the - "application/schema+json" media type. - - - Schema authors are encouraged to define their own vocabularies for - domain-specific concepts. A vocabulary need not be a standard to - be re-usable, although users of extension vocabularies MUST NOT - assume that any JSON Schema implementation can support the vocabulary - unless it specifically documents such support. - -
- - This vocabulary provides keywords for applying subschemas to the - instance in various ways. It is defined in this document, and - it is RECOMMENDED that all JSON Schema implementations support it. - All other vocabularies in this section are designed to be used - alongside the subschema application vocabulary. - - - Without this vocabulary or an equivalent one, JSON Schema can only - be applied to a JSON document as a whole. In most cases, schema - keywords need to be applied to specific object properties or array items. - -
-
- - This vocabulary describes the structure of a JSON document - (for instance, required properties and length limitations). - Applications can use this information to validate instances (check that - constraints are met), or inform interfaces to collect user input - such that the constraints are satisfied. - - - Validation behaviour and keywords are specified in - a separate document. - -
-
- - A small set of annotation keywords are defined in - the validation specification - to allow associating common kinds of meta-data with an instance. - -
-
- - JSON Hyper-Schema produces hyperlinks as annotations available for - use with a JSON document. It supports resolving URI Templates - and describing the resource and data submission formats required - to use an API. - - - Hyper-schema behaviour and keywords are specified in - a separate document. - -
-
+ + JSON Schema uses keywords to assert constraints on JSON instances or annotate those + instances with additional information. Additional keywords are used to apply + assertions and annotations to more complex JSON data structures, or based on + some sort of condition. + + + To facilitate re-use, keywords can be organized into vocabularies. A vocabulary + consists of a list of keywords, together with their syntax and semantics. + + + JSON Schema can be extended either by adding vocabularies, or less formally + by adding keywords without defining a vocabulary. Unrecognized individual + keywords are ignored, while the behavior with respect to an unrecognized + vocabulary can be controlled when declaring which vocabularies are in use. + + + This document defines a core vocabulary that MUST be supported by any + implementation, and cannot be disabled. Its keywords are each prefixed + with a "$" character to emphasize their required nature. This vocabulary + is essential to the functioning of the "application/schema+json" media + type, and is used to bootstrap the loading of other vocabularies. + + + Additionally, this document defines a RECOMMENDED vocabulary of keywords + for applying subschemas conditionally, and for applying subschemas to + the contents of objects and arrays. Either this vocabulary or one very + much like it is required to write schemas for non-trivial JSON instances, + whether those schemas are intended for assertion validation, annotation, + or both. While not part of the required core vocabulary, for maximum + interoperability this additional vocabulary is included in this document + and its use is strongly encouraged. + + + Further vocabularies for purposes such as structural validation or + hypermedia annotation are defined in other documents. +
@@ -825,7 +632,170 @@
-
+
+ + JSON Schema keywords fall into several general behavior categories. + Assertions validate that an instance satisfies constraints, producing + a boolean result. Annotations attach information that applications + may use in any way they see fit. + Applicators apply subschemas to parts of the instance and combine + their results. + + + Extension keywords SHOULD stay within these categories, keeping in mind + that annotations in particular are extremely flexible. Complex behavior + is usually better delegated to applications on the basis of annotation + data than implemented directly as schema keywords. However, extension + keywords MAY define other behaviors for specialized purposes. + + + Evaluating an instance against a schema involves processing all of the + keywords in the schema against the appropriate locations within the instance. + Typically, applicator keywords are processed until a schema object with no + applicators (and therefore no subschemas) is reached. The appropriate + location in the instance is evaluated against the assertion and + annotation keywords in the schema object, and their results are gathered + into the parent schema according to the rules of the applicator. + + + Evaluation of a parent schema object can complete once all of its + subschemas have been evaluated, although in some circumstances evaluation + may be short-circuited due to assertion results. + +
+ + Keyword behavior MAY be defined in terms of the annotation results + of subschemas and/or adjacent keywords. + Such keywords MUST NOT result in a circular dependency. + Keywords MAY modify their behavior based on the presence or absence + of another keyword in the same + schema object. + +
+
+ + A missing keyword MUST NOT produce a false assertion result, MUST + NOT produce annotation results, and MUST NOT cause any other schema + to be evaluated as part of its own behavioral definition. + However, given that missing keywords do not contribute annotations, + the lack of annotation results may indirectly change the behavior + of other keywords. + + + In some cases, the missing keyword assertion behavior of a keyword is + identical to that produced by a certain value, and keyword definitions + SHOULD note such values where known. However, even if the value which + produces the default behavior would produce annotation results if + present, the default behavior still MUST NOT result in annotations. + + + Because annotation collection can add significant cost in terms of both + computation and memory, implementations MAY opt out of this feature. + Keywords known to an implementation to have assertion or applicator behavior + that depend on annotation results MUST then be treated as errors, unless + an alternate implementation producing the same behavior is available. + Keywords of this sort SHOULD describe reasonable alternate approaches + when appropriate. This approach is demonstrated by the + "" and + "" keywords in this + document. + +
+
+ + Applicators allow for building more complex schemas than can be accomplished + with a single schema object. Evaluation of an instance against a + schema document begins by applying + the root schema to the complete instance + document. From there, keywords known as applicators are used to determine + which additional schemas are applied. Such schemas may be applied in-place + to the current location, or to a child location. + + + The schemas to be applied may be present as subschemas comprising all or + part of the keyword's value. Alternatively, an applicator may refer to + a schema elsewhere in the same schema document, or in a different one. + The mechanism for identifying such referenced schemas is defined by the + keyword. + + + Applicator keywords also define how subschema or referenced schema + boolean assertion + results are modified and/or combined to produce the boolean result + of the applicator. Applicators may apply any boolean logic operation + to the assertion results of subschemas, but MUST NOT introduce new + assertion conditions of their own. + + + Annotation results are + combined according to the rules specified by each annotation keyword. + +
+ +
+ + JSON Schema can be used to assert constraints on a JSON document, which + either passes or fails the assertions. This approach can be used to validate + conformance with the constraints, or document what is needed to satisfy them. + + + JSON Schema implementations produce a single boolean result when evaluating + an instance against schema assertions. + + + An instance can only fail an assertion that is present in the schema. + + +
+ + Most assertions only constrain values within a certain + primitive type. When the type of the instance is not of the type + targeted by the keyword, the instance is considered to conform + to the assertion. + + + For example, the "maxLength" keyword from the companion validation + vocabulary will only restrict certain strings + (that are too long) from being valid. If the instance is a number, + boolean, null, array, or object, then it is valid against this assertion. + +
+
+ +
+ + JSON Schema can annotate an instance with information, whenever the instance + validates against the schema object containing the annotation, and all of its + parent schema objects. The information can be a simple value, or can be + calculated based on the instance contents. + + + Annotations are attached to specific locations in an instance. + Since many subschemas can be applied to any single + location, annotation keywords need to specify any unusual handling of + multiple applicable occurrences of the keyword with different values. + + + The default behavior is simply to collect all values in a list in + indeterminate order. Given the extensibility of keywords, including + applicators, it is not possible to define a universally predictable + order of processing. + + + Unlike assertion results, annotation data can take a wide variety of forms, + which are provided to applications to use as they see fit. JSON Schema + implementations are not expected to make use of the collected information + on behalf of applications. + + + While "short-circuit" evaluation is possible for assertions, collecting + annotations requires examining all schemas that apply to an instance + location, even if they cannot change the overall assertion result. + +
+
+ +
Two concepts, meta-schemas and vocabularies, are used to inform an implementation how to interpret a schema. A schema S declares its meta-schema M with the "$schema" @@ -844,6 +814,11 @@ Meta-schema authoring is an advanced usage of JSON Schema, so the design of meta-schema features emphasizes flexibility over simplicity. + + A JSON Schema vocabulary is a set of keywords defined for a particular + purpose. The vocabulary specifies the meaning of its keywords as + assertions, annotations, and/or any vocabulary-defined keyword category. + The role of a vocabulary is to declare which keywords (including sub-keywords such as those in JSON Hyper-Schema's Link Description Object) are in use, From 6b2232effd34fc863d253ca3f43468c67fff75cf Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 11 Jul 2019 07:30:36 -0700 Subject: [PATCH 032/780] Improve wording: define additional vocabs/keywords Make it more clear that extending involves defining more vocabularies and/or keywords, not adding existing vocabularies/keywords from some place to some other place. --- jsonschema-core.xml | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 01a7c857..fd3246e3 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -154,10 +154,11 @@ consists of a list of keywords, together with their syntax and semantics. - JSON Schema can be extended either by adding vocabularies, or less formally - by adding keywords without defining a vocabulary. Unrecognized individual - keywords are ignored, while the behavior with respect to an unrecognized - vocabulary can be controlled when declaring which vocabularies are in use. + JSON Schema can be extended either by defining additional vocabularies, + or less formally by defining additional keywords outside of any vocabulary. + Unrecognized individual keywords are ignored, while the behavior with respect + to an unrecognized vocabulary can be controlled when declaring which + vocabularies are in use. This document defines a core vocabulary that MUST be supported by any From 53982c3de60b6b38f6a968f8c435f31bd0ca0042 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Mon, 15 Jul 2019 09:02:34 -0700 Subject: [PATCH 033/780] Update draft dates to August, and all HTTPS There's no reason in 2019 to even have http:// examples, plus our use of http:// vs https:// for meta-schemas was pretty much random. --- hyper-schema.json | 22 ++++---- jsonschema-core.xml | 106 ++++++++++++++++++------------------ jsonschema-hyperschema.xml | 24 ++++---- jsonschema-validation.xml | 20 +++---- links.json | 12 ++-- meta/applicator.json | 6 +- meta/content.json | 6 +- meta/core.json | 6 +- meta/format.json | 6 +- meta/hyper-schema.json | 8 +-- meta/meta-data.json | 6 +- meta/validation.json | 6 +- output/hyper-schema.json | 6 +- output/schema.json | 4 +- output/verbose-example.json | 26 ++++----- schema.json | 16 +++--- 16 files changed, 140 insertions(+), 140 deletions(-) diff --git a/hyper-schema.json b/hyper-schema.json index 07d331dd..79aadc0b 100644 --- a/hyper-schema.json +++ b/hyper-schema.json @@ -1,21 +1,21 @@ { - "$schema": "http://json-schema.org/draft/2019-04/hyper-schema#", - "$id": "http://json-schema.org/draft/2019-04/hyper-schema", + "$schema": "https://json-schema.org/draft/2019-08/hyper-schema#", + "$id": "https://json-schema.org/draft/2019-08/hyper-schema", "$vocabulary": { - "https://json-schema.org/draft/2019-04/vocab/core": true, - "https://json-schema.org/draft/2019-04/vocab/applicator": true, - "https://json-schema.org/draft/2019-04/vocab/validation": true, - "https://json-schema.org/draft/2019-04/vocab/meta-data": true, - "https://json-schema.org/draft/2019-04/vocab/format": true, - "https://json-schema.org/draft/2019-04/vocab/content": true, - "https://json-schema.org/draft/2019-04/vocab/hyper-schema": true + "https://json-schema.org/draft/2019-08/vocab/core": true, + "https://json-schema.org/draft/2019-08/vocab/applicator": true, + "https://json-schema.org/draft/2019-08/vocab/validation": true, + "https://json-schema.org/draft/2019-08/vocab/meta-data": true, + "https://json-schema.org/draft/2019-08/vocab/format": true, + "https://json-schema.org/draft/2019-08/vocab/content": true, + "https://json-schema.org/draft/2019-08/vocab/hyper-schema": true }, "$recursiveAnchor": true, "title": "JSON Hyper-Schema", "allOf": [ - {"$ref": "http://json-schema.org/draft/2019-04/schema"}, - {"$ref": "http://json-schema.org/draft/2019-04/meta/hyper-schema"} + {"$ref": "https://json-schema.org/draft/2019-08/schema"}, + {"$ref": "https://json-schema.org/draft/2019-08/meta/hyper-schema"} ], "links": [ { diff --git a/jsonschema-core.xml b/jsonschema-core.xml index fd3246e3..396ac498 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -87,7 +87,7 @@ . - For additional information, see . + For additional information, see . To provide feedback, use this issue tracker, the communication methods listed on the @@ -1036,11 +1036,11 @@ The current URI for the Core vocabulary is: - . + . The current URI for the corresponding meta-schema is: - . + . Updated vocabulary and meta-schema URIs MAY be published between @@ -1066,16 +1066,16 @@ - http://example.com/root.json - http://example.com/root.json# + https://example.com/root.json + https://example.com/root.json# - http://example.com/root.json#foo - http://example.com/root.json#/$defs/A + https://example.com/root.json#foo + https://example.com/root.json#/$defs/A - http://example.com/other.json - http://example.com/other.json# - http://example.com/root.json#/$defs/B + https://example.com/other.json + https://example.com/other.json# + https://example.com/root.json#/$defs/B - http://example.com/other.json#bar - http://example.com/other.json#/$defs/X - http://example.com/root.json#/$defs/B/$defs/X + https://example.com/other.json#bar + https://example.com/other.json#/$defs/X + https://example.com/root.json#/$defs/B/$defs/X - http://example.com/t/inner.json - http://example.com/t/inner.json# - http://example.com/other.json#/$defs/Y - http://example.com/root.json#/$defs/B/$defs/Y + https://example.com/t/inner.json + https://example.com/t/inner.json# + https://example.com/other.json#/$defs/Y + https://example.com/root.json#/$defs/B/$defs/Y urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f# - http://example.com/root.json#/$defs/C + https://example.com/root.json#/$defs/C @@ -1342,7 +1342,7 @@ When an implementation encounters the <#/$defs/single> schema, it resolves the "$id" URI reference against the current base URI to form - <http://example.net/root.json#item>. + <https://example.net/root.json#item>. When an implementation then looks inside the <#/items> schema, it encounters the <#item> reference, and resolves this to - <http://example.net/root.json#item>, which it has seen defined in + <https://example.net/root.json#item>, which it has seen defined in this same document and can therefore use automatically. When an implementation encounters the reference to "other.json", it resolves - this to <http://example.net/other.json>, which is not defined in this + this to <https://example.net/other.json>, which is not defined in this document. If a schema with that identifier has otherwise been supplied to the implementation, it can also be used automatically. @@ -1912,11 +1912,11 @@ The current URI for this vocabulary, known as the Applicator vocabulary, is: - . + . The current URI for the corresponding meta-schema is: - . + . Updated vocabulary and meta-schema URIs MAY be published between @@ -2511,7 +2511,7 @@
@@ -2586,8 +2586,8 @@ http://json-schema.org/draft/2019-04/schema#/$defs/nonNegativeInteger/minimum Because this output structure can be quite large, a smaller example is given here for brevity. The URI of the full output structure of the example above is: - . + .
For convenience, JSON Schema has been provided to validate output generated by implementations. Its URI is: - . + .
@@ -2894,7 +2894,7 @@ http://json-schema.org/draft/2019-04/schema#/$defs/nonNegativeInteger/minimum
; rel="describedby" +Link: ; rel="describedby" ]]>
@@ -2940,7 +2940,7 @@ Link: ; rel="describedby" @@ -2954,7 +2954,7 @@ Content-Type: application/json; @@ -2967,9 +2967,9 @@ Content-Type: application/json; diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index 49a57586..4a087f71 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -77,7 +77,7 @@ For additional information, see - . + . To provide feedback, use this issue tracker, the communication methods listed on the @@ -289,24 +289,24 @@
The current URI for the JSON Hyper-Schema meta-schema is - . + . The current URI for this vocabulary, known as the Hyper-Schema vocabulary, is: - . + . The current URI for the corresponding meta-schema, which differs from the convenience meta-schema above in that it describes only the hyper-schema keywords ("base" and "link") is: - . + . The link description format can be used without JSON Schema, and use of this format can be declared by referencing the normative link description schema as the schema for the data structure that uses the links. The URI of the normative link description schema is: - . + . JSON Hyper-Schema implementations are free to provide output in any format. @@ -317,7 +317,7 @@ It is RECOMMENDED that implementations be capable of producing output in this format to facilitated testing. The URI of the JSON Schema describing the recommended output format is - . + . Updated vocabulary and meta-schema URIs MAY be published between @@ -1625,7 +1625,7 @@ Link: ; rel="describedBy" ; rel="describedBy" ; rel="describedBy" ; rev="up" ; rev="up" ; rev="up" . - For additional information, see . + For additional information, see . To provide feedback, use this issue tracker, the communication methods listed on the @@ -195,7 +195,7 @@
The current URI for the JSON Schema Validation meta-schema is - . + . For schema author convenience, this meta-schema describes all vocabularies defined in this specification and the JSON Schema Core specification. Individual vocabulary and vocabulary meta-schema URIs are given for @@ -221,11 +221,11 @@ The current URI for this vocabulary, known as the Validation vocabulary, is: - . + . The current URI for the corresponding meta-schema is: - . + .
@@ -546,11 +546,11 @@ The current URI for this vocabulary, known as the Format vocabulary, is: - . + . The current URI for the corresponding meta-schema is: - . + .
@@ -809,11 +809,11 @@ The current URI for this vocabulary, known as the Content vocabulary, is: - . + . The current URI for the corresponding meta-schema is: - . + .
@@ -998,11 +998,11 @@ The current URI for this vocabulary, known as the Meta-Data vocabulary, is: - . + . The current URI for the corresponding meta-schema is: - . + .
diff --git a/links.json b/links.json index a5d5469c..0e0110db 100644 --- a/links.json +++ b/links.json @@ -1,6 +1,6 @@ { - "$schema": "http://json-schema.org/draft/2019-04/hyper-schema#", - "$id": "http://json-schema.org/draft/2019-04/links", + "$schema": "https://json-schema.org/draft/2019-08/hyper-schema#", + "$id": "https://json-schema.org/draft/2019-08/links", "title": "Link Description Object", "allOf": [ { "required": [ "rel", "href" ] }, @@ -36,7 +36,7 @@ "format": "uri-template" }, "hrefSchema": { - "$recursiveRef": "http://json-schema.org/draft/2019-04/hyper-schema", + "$recursiveRef": "https://json-schema.org/draft/2019-08/hyper-schema", "default": false }, "templatePointers": { @@ -63,7 +63,7 @@ "type": "string" }, "targetSchema": { - "$recursiveRef": "http://json-schema.org/draft/2019-04/hyper-schema", + "$recursiveRef": "https://json-schema.org/draft/2019-08/hyper-schema", "default": true }, "targetMediaType": { @@ -71,7 +71,7 @@ }, "targetHints": { }, "headerSchema": { - "$recursiveRef": "http://json-schema.org/draft/2019-04/hyper-schema", + "$recursiveRef": "https://json-schema.org/draft/2019-08/hyper-schema", "default": true }, "submissionMediaType": { @@ -79,7 +79,7 @@ "default": "application/json" }, "submissionSchema": { - "$recursiveRef": "http://json-schema.org/draft/2019-04/hyper-schema", + "$recursiveRef": "https://json-schema.org/draft/2019-08/hyper-schema", "default": true }, "$comment": { diff --git a/meta/applicator.json b/meta/applicator.json index 43b104ef..d101b710 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-04/schema#", - "$id": "https://json-schema.org/draft/2019-04/meta/applicator", + "$schema": "https://json-schema.org/draft/2019-08/schema#", + "$id": "https://json-schema.org/draft/2019-08/meta/applicator", "$vocabulary": { - "https://json-schema.org/draft/2019-04/vocab/applicator": true + "https://json-schema.org/draft/2019-08/vocab/applicator": true }, "$recursiveAnchor": true, diff --git a/meta/content.json b/meta/content.json index 2262099a..185b7a49 100644 --- a/meta/content.json +++ b/meta/content.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-04/schema#", - "$id": "http://json-schema.org/draft/2019-04/meta/content", + "$schema": "https://json-schema.org/draft/2019-08/schema#", + "$id": "https://json-schema.org/draft/2019-08/meta/content", "$vocabulary": { - "https://json-schema.org/draft/2019-04/vocab/content": true + "https://json-schema.org/draft/2019-08/vocab/content": true }, "$recursiveAnchor": true, diff --git a/meta/core.json b/meta/core.json index 6ba4329e..9dd8fbc2 100644 --- a/meta/core.json +++ b/meta/core.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-04/schema#", - "$id": "https://json-schema.org/draft/2019-04/meta/core", + "$schema": "https://json-schema.org/draft/2019-08/schema#", + "$id": "https://json-schema.org/draft/2019-08/meta/core", "$vocabulary": { - "https://json-schema.org/draft/2019-04/vocab/core": true + "https://json-schema.org/draft/2019-08/vocab/core": true }, "$recursiveAnchor": true, diff --git a/meta/format.json b/meta/format.json index 02970f37..7cbf48d8 100644 --- a/meta/format.json +++ b/meta/format.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-04/schema#", - "$id": "http://json-schema.org/draft/2019-04/meta/format", + "$schema": "https://json-schema.org/draft/2019-08/schema#", + "$id": "https://json-schema.org/draft/2019-08/meta/format", "$vocabulary": { - "https://json-schema.org/draft/2019-04/vocab/format": true + "https://json-schema.org/draft/2019-08/vocab/format": true }, "$recursiveAnchor": true, diff --git a/meta/hyper-schema.json b/meta/hyper-schema.json index 8f427d4b..a1d34485 100644 --- a/meta/hyper-schema.json +++ b/meta/hyper-schema.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-04/hyper-schema#", - "$id": "http://json-schema.org/draft/2019-04/meta/hyper-schema", + "$schema": "https://json-schema.org/draft/2019-08/hyper-schema#", + "$id": "https://json-schema.org/draft/2019-08/meta/hyper-schema", "$vocabulary": { - "https://json-schema.org/draft/2019-04/vocab/hyper-schema": true + "https://json-schema.org/draft/2019-08/vocab/hyper-schema": true }, "$recursiveAnchor": true, @@ -16,7 +16,7 @@ "links": { "type": "array", "items": { - "$ref": "http://json-schema.org/draft/2019-04/links" + "$ref": "https://json-schema.org/draft/2019-08/links" } } }, diff --git a/meta/meta-data.json b/meta/meta-data.json index 1accce67..20ccf3e7 100644 --- a/meta/meta-data.json +++ b/meta/meta-data.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-04/schema#", - "$id": "http://json-schema.org/draft/2019-04/meta/meta-data", + "$schema": "https://json-schema.org/draft/2019-08/schema#", + "$id": "https://json-schema.org/draft/2019-08/meta/meta-data", "$vocabulary": { - "https://json-schema.org/draft/2019-04/vocab/meta-data": true + "https://json-schema.org/draft/2019-08/vocab/meta-data": true }, "$recursiveAnchor": true, diff --git a/meta/validation.json b/meta/validation.json index 51db8864..ad8b6d1c 100644 --- a/meta/validation.json +++ b/meta/validation.json @@ -1,8 +1,8 @@ { - "$schema": "http://json-schema.org/draft/2019-04/schema#", - "$id": "http://json-schema.org/draft/2019-04/meta/validation", + "$schema": "https://json-schema.org/draft/2019-08/schema#", + "$id": "https://json-schema.org/draft/2019-08/meta/validation", "$vocabulary": { - "https://json-schema.org/draft/2019-04/vocab/validation": true + "https://json-schema.org/draft/2019-08/vocab/validation": true }, "$recursiveAnchor": true, diff --git a/output/hyper-schema.json b/output/hyper-schema.json index 04e6e05a..307b3f8c 100644 --- a/output/hyper-schema.json +++ b/output/hyper-schema.json @@ -1,11 +1,11 @@ { - "$schema": "http://json-schema.org/draft/2019-04/schema#", - "$id": "http://json-schema.org/draft/2019-04/output/hyper-schema", + "$schema": "https://json-schema.org/draft/2019-08/schema#", + "$id": "https://json-schema.org/draft/2019-08/output/hyper-schema", "title": "JSON Hyper-Schema Output", "type": "array", "items": { "allOf": [ - {"$ref": "http://json-schema.org/draft/2019-04/links#/$defs/noRequiredFields" } + {"$ref": "https://json-schema.org/draft/2019-08/links#/$defs/noRequiredFields" } ], "type": "object", "required": [ diff --git a/output/schema.json b/output/schema.json index d9ab2cd1..e95d8d0b 100644 --- a/output/schema.json +++ b/output/schema.json @@ -1,6 +1,6 @@ { - "$schema": "http://json-schema.org/draft/2019-04/schema#", - "$id": "http://json-schema.org/draft/2019-04/output/schema", + "$schema": "https://json-schema.org/draft/2019-08/schema#", + "$id": "https://json-schema.org/draft/2019-08/output/schema", "description": "A schema that validates the minimum requirements for validation output", "oneOf": [ diff --git a/output/verbose-example.json b/output/verbose-example.json index ef50444f..161b5855 100644 --- a/output/verbose-example.json +++ b/output/verbose-example.json @@ -22,42 +22,42 @@ "valid": true, "keywordLocation": "#/items/$ref", "absoluteKeywordLocation": - "http://example.com/polygon#/items/$ref", + "https://example.com/polygon#/items/$ref", "instanceLocation": "#/0", "annotations": [ { "valid": true, "keywordLocation": "#/items/$ref", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point", + "https://example.com/polygon#/definitions/point", "instanceLocation": "#/0", "annotations": [ { "valid": true, "keywordLocation": "#/items/$ref/type", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/type", + "https://example.com/polygon#/definitions/point/type", "instanceLocation": "#/0" }, { "valid": true, "keywordLocation": "#/items/$ref/properties", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/properties", + "https://example.com/polygon#/definitions/point/properties", "instanceLocation": "#/0" }, { "valid": true, "keywordLocation": "#/items/$ref/required", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/required", + "https://example.com/polygon#/definitions/point/required", "instanceLocation": "#/0" }, { "valid": true, "keywordLocation": "#/items/$ref/additionalProperties", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/additionalProperties", + "https://example.com/polygon#/definitions/point/additionalProperties", "instanceLocation": "#/0" } ] @@ -68,49 +68,49 @@ "valid": false, "keywordLocation": "#/items/$ref", "absoluteKeywordLocation": - "http://example.com/polygon#/items/$ref", + "https://example.com/polygon#/items/$ref", "instanceLocation": "#/1", "errors": [ { "valid": false, "keywordLocation": "#/items/$ref", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point", + "https://example.com/polygon#/definitions/point", "instanceLocation": "#/1", "errors": [ { "valid": true, "keywordLocation": "#/items/$ref/type", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/type", + "https://example.com/polygon#/definitions/point/type", "instanceLocation": "#/1" }, { "valid": true, "keywordLocation": "#/items/$ref/properties", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/properties", + "https://example.com/polygon#/definitions/point/properties", "instanceLocation": "#/1" }, { "valid": false, "keywordLocation": "#/items/$ref/required", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/required", + "https://example.com/polygon#/definitions/point/required", "instanceLocation": "#/1" }, { "valid": false, "keywordLocation": "#/items/$ref/additionalProperties", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/additionalProperties", + "https://example.com/polygon#/definitions/point/additionalProperties", "instanceLocation": "#/1", "errors": [ { "valid": false, "keywordLocation": "#/items/$ref/additionalProperties", "absoluteKeywordLocation": - "http://example.com/polygon#/definitions/point/additionalProperties", + "https://example.com/polygon#/definitions/point/additionalProperties", "instanceLocation": "#/1/z" } ] diff --git a/schema.json b/schema.json index 74215b30..605d9813 100644 --- a/schema.json +++ b/schema.json @@ -1,13 +1,13 @@ { - "$schema": "http://json-schema.org/draft/2019-04/schema#", - "$id": "http://json-schema.org/draft/2019-04/schema#", + "$schema": "https://json-schema.org/draft/2019-08/schema#", + "$id": "https://json-schema.org/draft/2019-08/schema#", "$vocabulary": { - "https://json-schema.org/draft/2019-04/vocab/core": true, - "https://json-schema.org/draft/2019-04/vocab/applicator": true, - "https://json-schema.org/draft/2019-04/vocab/validation": true, - "https://json-schema.org/draft/2019-04/vocab/meta-data": true, - "https://json-schema.org/draft/2019-04/vocab/format": true, - "https://json-schema.org/draft/2019-04/vocab/content": true + "https://json-schema.org/draft/2019-08/vocab/core": true, + "https://json-schema.org/draft/2019-08/vocab/applicator": true, + "https://json-schema.org/draft/2019-08/vocab/validation": true, + "https://json-schema.org/draft/2019-08/vocab/meta-data": true, + "https://json-schema.org/draft/2019-08/vocab/format": true, + "https://json-schema.org/draft/2019-08/vocab/content": true }, "$recursiveAnchor": true, From 926c3e81bda72d7001ee48528d682b74078be525 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Mon, 15 Jul 2019 09:42:36 -0700 Subject: [PATCH 034/780] Fix typo in meta-schema URI --- jsonschema-validation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index d7804ed3..246bd96d 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -195,7 +195,7 @@
The current URI for the JSON Schema Validation meta-schema is - . + . For schema author convenience, this meta-schema describes all vocabularies defined in this specification and the JSON Schema Core specification. Individual vocabulary and vocabulary meta-schema URIs are given for From 580ab1769babe68c396d7d2f3e44e7638e4f3fd2 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 18 Jul 2019 14:51:50 -0700 Subject: [PATCH 035/780] Update my contact information I no longer work at Riverbed. --- jsonschema-core.xml | 9 +-------- jsonschema-hyperschema.xml | 9 +-------- jsonschema-validation.xml | 9 +-------- relative-json-pointer.xml | 9 +-------- 4 files changed, 4 insertions(+), 32 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 396ac498..dc406f50 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -30,15 +30,8 @@ - Riverbed Technology
- - 680 Folsom St. - San Francisco - CA - USA - - handrews@riverbed.com + andrews_henry@yahoo.com
diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index 4a087f71..e3ddf254 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -31,15 +31,8 @@ - Riverbed Technology
- - 680 Folsom St. - San Francisco - CA - USA - - handrews@riverbed.com + andrews_henry@yahoo.com
diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 246bd96d..a3cdd70f 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -41,15 +41,8 @@ - Riverbed Technology
- - 680 Folsom St. - San Francisco - CA - USA - - handrews@riverbed.com + andrews_henry@yahoo.com
diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index b3ac5ff1..7d91a52f 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -28,15 +28,8 @@ - Riverbed Technology
- - 680 Folsom St. - San Francisco - CA - USA - - handrews@riverbed.com + andrews_henry@yahoo.com
From c12a08bc6c09de48d13ea170f03c18c07c377269 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 18 Jul 2019 15:31:24 -0700 Subject: [PATCH 036/780] Fix an apparent crediting error It seems like G. Luff got put here as well as on the hyper-schema spec when the project restarted, which (based on past credits and the known authorship of the first post-restart draft) was an error. He is still listed in the acknowledgements with other past major contributors to the overall project. --- jsonschema-validation.xml | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index a3cdd70f..0400944d 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -54,17 +54,6 @@ - -
- - - Cambridge - UK - - luffgd@gmail.com -
- - Internet Engineering Task Force JSON From 58e372cbfa05a724c625606863bc94d053c10ed5 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 19 Jul 2019 16:09:59 +0100 Subject: [PATCH 037/780] Fix typo! --- jsonschema-validation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 77fff604..c8cadcd4 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1044,7 +1044,7 @@ A root schema containing "deprecated" with a value of true indicates that - the entire resource beng described MAY be removed in the future. + the entire resource being described MAY be removed in the future. When the "deprecated" keyword is used to describe an array, it's meaning will From 92301ba447a837cf67016e74f9aafc7fee4fd0d0 Mon Sep 17 00:00:00 2001 From: Phil Sturgeon Date: Fri, 19 Jul 2019 17:12:13 +0200 Subject: [PATCH 038/780] applied applicability --- jsonschema-validation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index c8cadcd4..e5bf9deb 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1047,7 +1047,7 @@ the entire resource being described MAY be removed in the future. - When the "deprecated" keyword is used to describe an array, it's meaning will + When the "deprecated" keyword is applicable to an array, it's meaning will vary depending on how "items" is used. If "items" is a single schema, it will deprecate the contents of an array, but if "items" is an array of schemas it can be used to deprecate positional schemas. From 3f54ba26dc8787dfe0f2d65e4175d6e229fafd99 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Mon, 15 Jul 2019 13:11:11 -0700 Subject: [PATCH 039/780] Specify "format" requirements in vocabulary terms Use the true vs false values of vocabulary declaration to indicate whether a schema author requires assertion behavior (such as because a keyword such as "oneOf" depends on such validation functioning correctly). Use a false value in the standard core+validation vocabulary, reflecting the historical lack of requirement for this keyword to be implemented. Define annotation behavior when the vocabulary is declared with false, to facilitate the recommended best practice of performing semantic validation in your application. While not the typical false vocabulary behavior, this seems like the best way to reframe the historically unpredictable behavior. --- hyper-schema.json | 2 +- jsonschema-validation.xml | 93 ++++++++++++++++++++++++++++++--------- schema.json | 2 +- 3 files changed, 74 insertions(+), 23 deletions(-) diff --git a/hyper-schema.json b/hyper-schema.json index 79aadc0b..bc5ba60d 100644 --- a/hyper-schema.json +++ b/hyper-schema.json @@ -6,7 +6,7 @@ "https://json-schema.org/draft/2019-08/vocab/applicator": true, "https://json-schema.org/draft/2019-08/vocab/validation": true, "https://json-schema.org/draft/2019-08/vocab/meta-data": true, - "https://json-schema.org/draft/2019-08/vocab/format": true, + "https://json-schema.org/draft/2019-08/vocab/format": false, "https://json-schema.org/draft/2019-08/vocab/content": true, "https://json-schema.org/draft/2019-08/vocab/hyper-schema": true }, diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 0400944d..793f6580 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -174,14 +174,15 @@
-
+
The current URI for the JSON Schema Validation meta-schema is . For schema author convenience, this meta-schema describes all vocabularies defined in this specification and the JSON Schema Core specification. Individual vocabulary and vocabulary meta-schema URIs are given for - each section below. + each section below. Certain vocabularies are optional to support, which + is explained in detail in the relevant sections. Updated vocabulary and meta-schema URIs MAY be published between @@ -503,28 +504,42 @@
-
+
- Structural validation alone may be insufficient to validate that an instance - meets all the requirements of an application. The "format" keyword is defined to - allow interoperable semantic validation for a fixed subset of values which are + Structural validation alone may be insufficient to allow an application to correctly + utilize certain values. The "format" annotation keyword is defined to allow schema + authors to convey semantic information for a fixed subset of values which are accurately described by authoritative resources, be they RFCs or other external specifications. + + Implementations MAY treat "format" as an assertion in addition to an annotation, + and attempt to validate the values conformance to the specified semantics. + See the Implementation Requirements below for details. + + The value of this keyword is called a format attribute. It MUST be a string. A format attribute can generally only validate a given set of instance types. If the type of the instance to validate is not in this set, validation for this - format attribute and instance SHOULD succeed. + format attribute and instance SHOULD succeed. All format attributes defined + in this section apply to strings, but a format attribute can be specified + to apply to any instance types defined in the data model defined in the + core JSON Schema. + + Note that the "type" keyword in this specification defines an "integer" type + which is not part of the data model. Therefore a format attribute can be + limited to numbers, but not specifically to integers. + Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its URI were present with a value of true, - although see the Implementation Requirements below for details. + utilize this vocabulary as if its URI were present with a value of false. + See the Implementation Requirements below for details. The current URI for this vocabulary, known as the Format vocabulary, is: @@ -539,26 +554,60 @@
- The "format" keyword functions as both an annotation - and as an assertion. While no special effort is required to - implement it as an annotation conveying semantic meaning, implementing - validation is non-trivial. - - - Implementations MAY support the "format" keyword as a validation assertion. - Should they choose to do so: - + The "format" keyword functions as an annotation, and optionally as an assertion. + Declaring the format vocabulary in "$vocabulary" with a value of true indicates + that an implementation MUST treat the keyword as an assertion. + This means that: they SHOULD implement validation for attributes defined below; they SHOULD offer an option to disable validation for this keyword. + + + Due to the complexity involved in fully validating some format attributes + defined in this specification, implementations MAY provide only limited + validation support for some format attributes. Implementations SHOULD + document any such intentional limitations. - Implementations MAY add custom format attributes. Save for agreement between - parties, schema authors SHALL NOT expect a peer implementation to support this - keyword and/or custom format attributes. + The standard core and validation meta-schema + includes this vocabulary in its "$vocabulary" keyword with a value of false, + since by default implementations are not required to support this keyword + as an assertion. + + + + When the format vocabulary is declared with a value of false, an implementation + SHOULD treat "format" as an annotation keyword, to facilitate applications which + wish to do their own semantic validation. + + This is not the normal behavior for a vocabulary declared with false, which is + why the requirement is a SHOULD. Implementations MAY ignore "format" entirely + as is allowed by false vocabulary declarations. However, due to the long history + of this keyword, treating it as something of a special case seems reasonable. + This may be revised in future drafts based on feedback. + + + + Implementations MAY treat "format" as an assertion when the vocabulary is declared + with false, as false vocabularies are optional rather than forbidden. However, + as noted above, implementations SHOULD provide a way to disable such validation. + + + Implementations MAY support custom format attributes. Save for agreement between + parties, schema authors SHALL NOT expect a peer implementation to support such + custom format attributes. An implementation MUST NOT fail + validation or cease processing due to an unknown format attribute. + If treating "format" as an annotation, implementations SHOULD collect both + known and unknown format attribute values. + + + Vocabularies do not support specifically declaring different value sets for keywords. + Due to this limitation, and the historically uneven implementation of this keyword, + it is RECOMMENDED to define additional keywords in a vocabulary rather than + additional format attributes if interoperability is desired.
@@ -1273,6 +1322,8 @@ + Update "format" implementation requirements in terms of vocabularies + Grouped keywords into formal vocabuarlies Moved "definitions" to the core spec as "$defs" Moved applicator keywords to the core spec Renamed the array form of "dependencies" to "dependentRequired", moved the schema form to the core spec diff --git a/schema.json b/schema.json index 605d9813..daca1a49 100644 --- a/schema.json +++ b/schema.json @@ -6,7 +6,7 @@ "https://json-schema.org/draft/2019-08/vocab/applicator": true, "https://json-schema.org/draft/2019-08/vocab/validation": true, "https://json-schema.org/draft/2019-08/vocab/meta-data": true, - "https://json-schema.org/draft/2019-08/vocab/format": true, + "https://json-schema.org/draft/2019-08/vocab/format": false, "https://json-schema.org/draft/2019-08/vocab/content": true }, "$recursiveAnchor": true, From 3ea9e82baac13e43071956f9c7f6fd9c758d4be9 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 23 Jul 2019 17:05:07 -0700 Subject: [PATCH 040/780] Make "format" behavior more predictable By default, a false vocabulary prevents "format" from being validated. By default, a true vocabulary requires "format" to be validated, although the degree of validation required remains somewhat vague at least for this draft. In both the true and false cases, validation can be toggled on or off when passing schemas and instances to the implementation (although in the false case, there is no guarantee at all that turning on valdiation will produce any validation behavior; this matches the previous draft's "format" specification). --- jsonschema-validation.xml | 191 +++++++++++++++++++++++++++----------- 1 file changed, 138 insertions(+), 53 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 793f6580..14fe072d 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -517,7 +517,7 @@ Implementations MAY treat "format" as an assertion in addition to an annotation, - and attempt to validate the values conformance to the specified semantics. + and attempt to validate the value's conformance to the specified semantics. See the Implementation Requirements below for details. @@ -532,7 +532,10 @@ Note that the "type" keyword in this specification defines an "integer" type which is not part of the data model. Therefore a format attribute can be - limited to numbers, but not specifically to integers. + limited to numbers, but not specifically to integers. However, a numeric + format can be used alongside the "type" keyword with a value of "integer", + or could be explicitly defined to always pass if the number is not an integer, + which produces essentially the same behavior as only applying to integers. @@ -555,60 +558,140 @@
The "format" keyword functions as an annotation, and optionally as an assertion. - Declaring the format vocabulary in "$vocabulary" with a value of true indicates - that an implementation MUST treat the keyword as an assertion. - This means that: - - they SHOULD implement validation for attributes defined below; - they SHOULD offer an option to disable validation for this keyword. - + This is due to the keyword's history, and is not in line with current + keyword design principles. In order to manage this ambiguity, the + "format" keyword is defined in its own separate vocabulary, as noted above. + 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. - - Due to the complexity involved in fully validating some format attributes - defined in this specification, implementations MAY provide only limited - validation support for some format attributes. Implementations SHOULD - document any such intentional limitations. - +
+ + The value of format MUST be collected as an annotation, if the implementation + supports annotation collection. This enables application-level validation when + schema validation is unavailable or inadequate. + + + This requirement is not affected by the boolean value of the vocabulary + declaration, nor by the configuration of "format"'s assertion + behavior described in the next section. + + Requiring annotation collection even when the vocabulary is declared with + a value of false is atypical, but necessary to ensure that the best + practice of performing application-level validation is possible even when + assertion evaluation is not implemented. Since "format" has always been + a part of this specification, requiring implementations to be aware of it + even with a false vocabulary declaration is deemed to not be a burden. + + +
- - The standard core and validation meta-schema - includes this vocabulary in its "$vocabulary" keyword with a value of false, - since by default implementations are not required to support this keyword - as an assertion. - +
+ + Regardless of the boolean value of the vocabulary declaration, + an implementation that can evaluate "format" as an assertion MUST provide + options to enable and disable such evaluation. The assertion evaluation + behavior when the option is not explicitly specified depends on + the vocabulary declaration's boolean value. + - - When the format vocabulary is declared with a value of false, an implementation - SHOULD treat "format" as an annotation keyword, to facilitate applications which - wish to do their own semantic validation. - - This is not the normal behavior for a vocabulary declared with false, which is - why the requirement is a SHOULD. Implementations MAY ignore "format" entirely - as is allowed by false vocabulary declarations. However, due to the long history - of this keyword, treating it as something of a special case seems reasonable. - This may be revised in future drafts based on feedback. - - - - Implementations MAY treat "format" as an assertion when the vocabulary is declared - with false, as false vocabularies are optional rather than forbidden. However, - as noted above, implementations SHOULD provide a way to disable such validation. - - - Implementations MAY support custom format attributes. Save for agreement between - parties, schema authors SHALL NOT expect a peer implementation to support such - custom format attributes. An implementation MUST NOT fail - validation or cease processing due to an unknown format attribute. - If treating "format" as an annotation, implementations SHOULD collect both - known and unknown format attribute values. - - - Vocabularies do not support specifically declaring different value sets for keywords. - Due to this limitation, and the historically uneven implementation of this keyword, - it is RECOMMENDED to define additional keywords in a vocabulary rather than - additional format attributes if interoperability is desired. - + + When implementing this entire specification, this vocabulary MUST + be supported with a value of false (but see details below), + and MAY be supported with a value of true. + + + + When the vocabulary is declared with a value of false, an implementation: + + + MUST NOT evaluate "format" as an assertion unless it is explicitly + configured to do so; + + + SHOULD provide an implementation-specific best effort validation + for each format attribute defined below; + + + MAY choose to implement validation of any or all format attributes + as a no-op by always producing a validation result of true; + + + SHOULD document its level of support for validation. + + + + This matches the current reality of implementations, which provide + widely varying levels of validation, including no validation at all, + for some or all format attributes. It is also designed to encourage + relying only on the annotation behavior and performing semantic + validation in the application, which is the recommended best practice. + + + + + When the vocabulary is declared with a value of true, an implementation + that supports this form of the vocabulary: + + + MUST evaluate "format" as an assertion unless it is explicitly + configured not to do so; + + + MUST implement syntactic validation for all format attributes defined + in this specification, and for any additional format attributes that + it recognizes, such that there exist possible instance values + of the correct type that will fail validation. + + + The requirement for minimal validation of format attributes is intentionally + vague and permissive, due to the complexity involved in many of the attributes. + Note in particular that the requirement is limited to syntactic checking; it is + not to be expected that an implementation would send an email, attempt to connect + to a URL, or otherwise check the existence of an entity identified by a format + instance. + + The expectation is that for simple formats such as date-time, syntactic + validation will be thorough. For a complex format such as email addresses, + which are the amalgamation of various standards and numerous adjustments + over time, with obscure and/or obsolete rules that may or may not be + restricted by other applications making use of the value, a minimal validation + is sufficient. For example, an instance string that does not contain + an "@" is clearly not a valid email address, and an "email" or "hostname" + containing characters outside of 7-bit ASCII is likewise clearly invalid. + + + + It is RECOMMENDED that implementations use a common parsing library for each format, + or a well-known regular expression. Implementations SHOULD clearly document + how and to what degree each format attribute is validated. + + + The standard core and validation meta-schema + includes this vocabulary in its "$vocabulary" keyword with a value of false, + since by default implementations are not required to support this keyword + as an assertion. Supporting the format vocabulary with a value of true is + understood to greatly increase code size and in some cases execution time, + and will not be appropriate for all implementations. + +
+
+ + Implementations MAY support custom format attributes. Save for agreement between + parties, schema authors SHALL NOT expect a peer implementation to support such + custom format attributes. An implementation MUST NOT fail + validation or cease processing due to an unknown format attribute. + When treating "format" as an annotation, implementations SHOULD collect both + known and unknown format attribute values. + + + Vocabularies do not support specifically declaring different value sets for keywords. + Due to this limitation, and the historically uneven implementation of this keyword, + it is RECOMMENDED to define additional keywords in a custom vocabulary rather than + additional format attributes if interoperability is desired. + +
@@ -1322,8 +1405,10 @@ - Update "format" implementation requirements in terms of vocabularies Grouped keywords into formal vocabuarlies + Update "format" implementation requirements in terms of vocabularies + By default, "format" MUST NOT be validated, although validation can be enabled + A vocabulary declaration can be used to require "format" validation Moved "definitions" to the core spec as "$defs" Moved applicator keywords to the core spec Renamed the array form of "dependencies" to "dependentRequired", moved the schema form to the core spec From f98af4cf5d1974350647ce2fb5980cd03534be3a Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 19 Jul 2019 13:33:53 -0700 Subject: [PATCH 041/780] Make the "content*" keywords annotations only They no longer optionally funciton as validation assertions in order to ensure consistent and interoperable behavior. --- jsonschema-validation.xml | 70 +++++++++++++++++++++------------------ 1 file changed, 38 insertions(+), 32 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 0400944d..67dbce6d 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -776,18 +776,19 @@
- Properties defined in this section indicate that an instance contains + Annotations defined in this section indicate that an instance contains non-JSON data encoded in a JSON string. - They describe the type of content and how it is encoded. These properties provide additional information required to interpret JSON data - as rich multimedia documents. + as rich multimedia documents. They describe the type of content, how it is encoded, + and/or how it may be validated. They do not function as validation assertions; + a malformed string-encoded document MUST NOT cause the containing instance + to be considered invalid. Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its URI were present with a value of true, - although see the Implementation Requirements below for details. + require this vocabulary as if its URI were present with a value of true. The current URI for this vocabulary, known as the Content vocabulary, is: @@ -801,16 +802,31 @@
- The content keywords function as both annotations and as assertions. - While no special effort is required to implement them as annotations conveying - how applications can interpret the data in the string, implementing - validation of conformance to the media type and encoding is non-trivial. + Due to security and performance concerns, as well as the open-ended nature of + possible content types, implementations MUST NOT automatically decode, parse, + and/or validate the string contents by default. This additionally supports + the use case of embedded documents intended for processing by a different + consumer than that which processed the containing document. + + + All keywords in this section apply only to strings, and have no + effect on other data types. - Implementations MAY support the "contentMediaType" and "contentEncoding" - keywords as validation assertions. - Should they choose to do so, they SHOULD offer an option to disable validation - for these keywords. + Implementations MAY offer the ability to decode, parse, and/or validate + the string contents automatically. However, it MUST NOT perform these + operations by default, and MUST provide the validation result of each + string-encoded document separately from the enclosing document. + + For now, the exact mechanism of any such automatic decoding, parsing, + and validating feature is left unspecified. Should such a feature + prove popular, it may be specified more thoroughly in a future draft. + + + + See also the Security Considerations + sections for possible vulnerabilities introduced by automatically + processing the instance string according to these keywords.
@@ -841,17 +857,11 @@ The value of this property MUST be a string. - - - The value of this property SHOULD be ignored if the instance described is not a - string. - -
- If the instance is a string, this property defines the media type + If the instance is a string, this property indicates the media type of the contents of the string. If "contentEncoding" is present, this property describes the decoded string. @@ -859,11 +869,6 @@ The value of this property MUST be a string, which MUST be a media type, as defined by RFC 2046. - - - The value of this property SHOULD be ignored if the instance described is not a - string. -
@@ -876,8 +881,7 @@ JSON Schema's data model. - The value of this property SHOULD be ignored if the instance described is not a - string, or if "contentMediaType" is not present. + The value of this property SHOULD be ignored if "contentMediaType" is not present.
@@ -897,8 +901,8 @@ ]]> - Instances described by this schema should be strings, and their values - should be interpretable as base64-encoded PNG images. + Instances described by this schema are expected to be strings, + and their values should be interpretable as base64-encoded PNG images. @@ -915,8 +919,9 @@ ]]> - Instances described by this schema should be strings containing HTML, using - whatever character set the JSON string was decoded into. Per section 8.1 of + Instances described by this schema are expected to be strings containing HTML, + using whatever character set the JSON string was decoded into. + Per section 8.1 of RFC 8259, outside of an entirely closed system, this MUST be UTF-8. @@ -1100,7 +1105,7 @@
-
+
JSON Schema validation defines a vocabulary for JSON Schema core and concerns all the security considerations listed there. @@ -1276,6 +1281,7 @@ Moved "definitions" to the core spec as "$defs" Moved applicator keywords to the core spec Renamed the array form of "dependencies" to "dependentRequired", moved the schema form to the core spec + Specified all "content*" keywords as annotations, not assertions Added "contentSchema" to allow applying a schema to a string-encoded document Also allow RFC 4648 encodings in "contentEncoding" Added "minContains" and "maxContains" From a40ef0773ae159d9eb4ddad1805573e895d37e89 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 25 Jul 2019 22:11:44 -0700 Subject: [PATCH 042/780] Review feedback on "content*" Better explanation of automatic decode/parse/validate. --- jsonschema-validation.xml | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 67dbce6d..f4765cef 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -816,9 +816,13 @@ Implementations MAY offer the ability to decode, parse, and/or validate the string contents automatically. However, it MUST NOT perform these operations by default, and MUST provide the validation result of each - string-encoded document separately from the enclosing document. + string-encoded document separately from the enclosing document. This + process SHOULD be equivalent to fully evaluating the instance against + the original schema, followed by using the annotations to decode, parse, + and/or validate each string-encoded document. - For now, the exact mechanism of any such automatic decoding, parsing, + For now, the exact mechanism of performing and returning parsed + data and/or validation results from such an automatic decoding, parsing, and validating feature is left unspecified. Should such a feature prove popular, it may be specified more thoroughly in a future draft. From 4050ae4b913949d2dbc7eb449b04f5e5f6b1b6b7 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 25 Jul 2019 22:27:55 -0700 Subject: [PATCH 043/780] Clarify annotation collection with applicators In particular, "contains" collects annotations. I'm not sure where the exception came from, as it was not present in the previous draft (to the extent that that draft mentioned annotations). The CREF actually did talk about annotation collection so apparently this was a bit of a muddled mess anyway. This makes "contains" behave like all other applicators, producing both assertion and annotation results. --- jsonschema-core.xml | 21 ++++++++++----------- jsonschema-validation.xml | 6 +++--- 2 files changed, 13 insertions(+), 14 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index dc406f50..269d4f96 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -654,7 +654,10 @@ Evaluation of a parent schema object can complete once all of its subschemas have been evaluated, although in some circumstances evaluation - may be short-circuited due to assertion results. + may be short-circuited due to assertion results. When annotations are + being collected, some assertion result short-circuiting is not possible + due to the need to collect annotations from all subschemas, including + those that cannot further change the assertion result.
@@ -1981,6 +1984,8 @@ An instance validates successfully against this keyword if it validates successfully against at least one schema defined by this keyword's value. + Note that when annotations are being collected, they MUST be collected + from all subschemas if any subschema validates successfully.
@@ -2245,16 +2250,10 @@ An array instance is valid against "contains" if at least one of - its elements is valid against the given schema. This keyword - does not produce annotation results. - - Should it produce a set of the indices for which the - array element is valid against the subschema? "contains" - does not affect "additionalItems" or any other current - or proposed keyword, but the information could be useful, - and implementation that collect annotations need to - apply "contains" to every element anyway. - + its elements is valid against the given schema. Note that when + collecting annotations, the subschema MUST be applied to every + array element even after the first match has been found. This + is to ensure that all possible annotations are collected.
diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 0400944d..37321dff 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1220,9 +1220,9 @@ their results, without asserting any conditions of their own. Without assertion keywords, these applicators can only cause assertion failures by using the false boolean schema, or by inverting the result - of the true boolean schema. For this reason, they are better defined - as a generic mechanism on which validation, hyper-schema, and extension - vocabularies can all be based + of the true boolean schema (or equivalent schema objects). + For this reason, they are better defined as a generic mechanism on which + validation, hyper-schema, and extension vocabularies can all be based. This keyword had two different modes of behavior, which made it From 4b55933a5c7ff92a545c04794a60a6bc70d46394 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 27 Jul 2019 11:04:58 -0700 Subject: [PATCH 044/780] Example of assertion independence per awwright Based on awwright's suggesetion in the slack channel. --- jsonschema-core.xml | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index dc406f50..8e0c51a7 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -748,11 +748,38 @@ to the assertion. - For example, the "maxLength" keyword from the companion validation - vocabulary will only restrict certain strings + For example, the "maxLength" keyword from the companion + validation vocabulary: + will only restrict certain strings (that are too long) from being valid. If the instance is a number, boolean, null, array, or object, then it is valid against this assertion. + + This behavior allows keywords to be used more easily with instances + that can be of multiple primitive types. The companion validation + vocabulary also includes a "type" keyword which can independently + restrict the instance to one or more primitive types. This allows + for a concise expression of use cases such as a function that might + return either a string of a certain length or a null value: + +
+ + + + + If "maxLength" also restricted the instance type to be a string, + then this would be substantially more cumbersome to express because + the example as written would not actually allow null values. + Each keyword is evaluated separately unless explicitly specified + otherwise, so if "maxLength" restricted the instance to strings, + then including "null" in "type" would not have any useful effect. + +
From 69b313c1a0c146163cbe1e9287b91696297d3bdd Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 27 Jul 2019 11:38:37 -0700 Subject: [PATCH 045/780] Clarify examining for vs collecting annotations You have to look at all subschemas in the cases in question, which may or may not result in actual collection of annotations, depending on the assertion outcomes of the individual subschemas. --- jsonschema-core.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 269d4f96..593893da 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -656,7 +656,7 @@ subschemas have been evaluated, although in some circumstances evaluation may be short-circuited due to assertion results. When annotations are being collected, some assertion result short-circuiting is not possible - due to the need to collect annotations from all subschemas, including + due to the need to examine all subschemas for annotation collection, including those that cannot further change the assertion result.
@@ -1984,8 +1984,9 @@ An instance validates successfully against this keyword if it validates successfully against at least one schema defined by this keyword's value. - Note that when annotations are being collected, they MUST be collected - from all subschemas if any subschema validates successfully. + Note that when annotations are being collected, all subschemas MUST + be examined so that annotations are collected from each subschema + that validates successfully.
From 78090387562204100c7ba184b27259fe9351b888 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sun, 28 Jul 2019 22:43:11 -0700 Subject: [PATCH 046/780] Restructure vocabulary-related sections Attempt to make this more understandable by removing some duplication, putting things in the right order, and explaning certain things more clearly. Hopefully. --- jsonschema-core.xml | 239 ++++++++++++++++++++++++++------------------ 1 file changed, 141 insertions(+), 98 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index dc406f50..0f745657 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -293,7 +293,7 @@ A JSON Schema document, or simply a schema, is a JSON document used to describe an instance. - A schema is itself interpreted as an instance, but SHOULD always be given + A schema can itself be interpreted as an instance, but SHOULD always be given the media type "application/schema+json" rather than "application/schema-instance+json". The "application/schema+json" media type is defined to offer a superset of the media type parameter and @@ -356,7 +356,7 @@ Always passes validation, as if the empty schema {} - Always fails validation, as if the schema { "not":{} } + Always fails validation, as if the schema { "not": {} } While the empty schema object is unambiguous, there are many @@ -365,6 +365,36 @@ and implementations.
+
+ + A schema vocabulary, or simply a vocabulary, is a set of keywords, + their syntax, and their semantics. A vocabulary is generally organized + around a particular purpose. Different uses of JSON Schema will + involve different sets of vocabularies. + + + Vocabularies are the primary unit of re-use in JSON Schema, as schema + authors can indicate what vocabularies are required or optional in + order to process the schema. While keywords can be supported outside + of any vocabulary, there is no analogous mechanism to indicate individual + keyword usage. + +
+
+ + A schema that itself describes a schema is called a meta-schema. + Meta-schemas are used to validate JSON Schemas and specify which vocabularies + they are using. + + + Typically, a meta-schema will specify a set of vocabularies, and validate + schemas that conform to the syntax of those vocabularies. However, meta-schemas + and vocabularies are separate in order to allow meta-schemas to validate + schema conformance more strictly or more loosely than the vocabularies' + specifications call for. Meta-schemas may also describe and validate + additional keywords that are not part of a formal vocabulary. + +
The root schema is the schema that comprises the entire JSON document @@ -438,7 +468,7 @@ Lexical and dynamic scopes align until a reference keyword - is encountered. While following the reference keyword jumps + is encountered. While following the reference keyword moves processing from one lexical scope into a different one, from the perspective of dynamic scope, following reference is no different from descending into a subschema present as a value. A keyword on the far side of @@ -447,9 +477,13 @@ dynamic parent, rather than examining the local lexically enclosing parent. - The concept of dynamic scope is primarily used with "$recursiveRef", + The concept of dynamic scope is primarily used with "$recursiveRef" and "$recursiveAnchor", and should be considered an advanced feature - and used with caution when defining additional keywords. + and used with caution when defining additional keywords. It also appears + when reporting errors and collected annotations, as it may be possible + to revisit the same lexical scope repeatedly with different dynamic + scopes. In such cases, it is important to inform the user of the + dynamic path that produced the error or annotation.
@@ -590,37 +624,9 @@ Implementations SHOULD ignore keywords they do not support. - Vocabulary authors SHOULD - take care to avoid keyword name collisions if the vocabulary is intended - for broad use, and potentially combined with other vocabularies. JSON - Schema does not provide any formal namespacing system, but also does - not constrain keyword names, allowing for any number of namespacing - approaches. - - - Vocabularies may build on each other, such as by defining the behavior - of their keywords with respect to the behavior of keywords from another - vocabulary, or by using a keyword from another vocabulary with - a restricted or expanded set of acceptable values. Not all such - vocabulary re-use will result in a new vocabulary that is compatible - with the vocabulary on which it is built. Vocabulary authors SHOULD - clearly document what level of compatibility, if any, is expected. - - - A schema that itself describes a schema is called a meta-schema. - Meta-schemas are used to validate JSON Schemas and specify which vocabulary - they are using. - - - Authors of extensions to JSON Schema are encouraged to write their own - meta-schemas, which extend the existing meta-schemas using "allOf". - This extended meta-schema SHOULD be referenced using the "$schema" keyword, to - allow tools to follow the correct behaviour. - - - The recursive nature of meta-schemas makes the "$recursiveAnchor" - and "$recursiveRef" keywords particularly useful for such extensions, - as can be seen in the JSON Hyper-Schema meta-schema. + Implementations MAY provide the ability to register or load handlers + for vocabularies that they do not support directly. The exact mechanism + for registering and implementing such handlers is implementation-dependent.
@@ -792,47 +798,43 @@
Two concepts, meta-schemas and vocabularies, are used to inform an implementation - how to interpret a schema. A schema S declares its meta-schema M with the "$schema" - keyword, and meta-schemas declare vocabularies with the "$vocabulary" keyword. - The vocabularies declared in M are those that are expected to be used in S. - The meta-schema M may itself use a different set of vocabularies, which are - declared in its own meta-schema, M'. - - - The role of the meta-schema is to constrain the structure of conforming schemas, - as well as simplify the process of composing multiple vocabularies into a usable - feature set. Schema authoring is expected to be a common activity, so - schema authors need only understand how to reference a single meta-schema. - - - Meta-schema authoring is an advanced usage of JSON Schema, so the design of - meta-schema features emphasizes flexibility over simplicity. + how to interpret a schema. Every schema has a meta-schema, typically identified + using the "$schema" keyword. - A JSON Schema vocabulary is a set of keywords defined for a particular - purpose. The vocabulary specifies the meaning of its keywords as - assertions, annotations, and/or any vocabulary-defined keyword category. - - - The role of a vocabulary is to declare which keywords (including sub-keywords - such as those in JSON Hyper-Schema's Link Description Object) are in use, - and with which semantics. The semantics are indicated by the document - that publicizes the vocabulary URI. At this time, there is no machine-readable - description of keywords other than validation rules, which appear in the - meta-schema. + The meta-schema serves two purposes: + + + The "$vocabulary" keyword, when it appears in a meta-schema, declares + which vocabularies are available to be used in schemas that refer + to that meta-schema. Vocabularies define keyword semantics, + as well as their general syntax. + + + A schema MUST successfully validate against its meta-schema, which + constrains the syntax of the available keywords. The syntax described + is expected to be compatible with the vocabularies declared; while + it is possible to describe an incompatible syntax, such a meta-schema + would be unlikely to be useful. + + - Meta-schemas are separate from vocabularies to allow for the same sets of + Meta-schemas are separate from vocabularies to allow for vocabularies to be combined in different ways, and for meta-schema authors to impose additional constraints such as forbidding certain keywords, or performing unusually strict syntactical validation, as might be done during a development and testing cycle. + + Meta-schema authoring is an advanced usage of JSON Schema, so the design of + meta-schema features emphasizes flexibility over simplicity. +
The "$schema" keyword is both used as a JSON Schema feature set identifier and - the location of a resource which is itself a JSON Schema, which describes any - schema written for this particular feature set. + as the identifier of a resource which is itself a JSON Schema, which describes the + set of valid schemas written for this particular feature set. The value of this keyword MUST be a URI @@ -845,7 +847,8 @@ The "$schema" keyword SHOULD be used in a root schema. - It MUST NOT appear in subschemas. + It MUST NOT appear in subschemas. If absent from the root schema, the + resulting behavior is implementation-defined. @@ -872,11 +875,11 @@
- The "$vocabulary" keyword, which appears in a meta-schema, identifies - what sets of keywords are expected to be used in schemas described - by that meta-schema, and with what semantics. This is conceptually - analogous to how most other keywords used in meta-schemas describe - the syntax of keywords used in schemas described by that meta-schema. + The "$vocabulary" keyword is used in meta-schemas to identify the + vocabularies available for use in schemas described by that meta-schema. + It is also used to indicate whether each vocabulary is required or optional, + in the sense that an implementation MUST understand the required vocabularies + in order to successfully process the schema. The value of this keyword MUST be an object. The property names in the @@ -885,16 +888,17 @@ keywords and their semantics. - The URI MAY be a URL, but the nature of the retrievable resources is + The URI MAY be a URL, but the nature of the retrievable resource is currently undefined, and reserved for future use. Vocabulary authors - SHOULD NOT serve a document at that URL. A server MAY respond with - the relevant protocol's successful "no content" message, such as - an HTTP 204 status. + MAY use the URL of the vocabulary specification, in a human-readable + media type such as text/html or text/plain, as the vocabulary URI. Vocabulary documents may be added shortly, or in the next draft. For now, identifying the keyword set is deemed sufficient as that, along with meta-schema validation, is how the current "vocabularies" - work today. + work today. Any future vocabulary document format will be specified + as a JSON document, so using text/html or other non-JSON formats + in the meantime will not produce any future ambiguity. @@ -920,24 +924,40 @@ a meta-schema M against its own meta-schema M' without requiring the validator to understand the vocabularies declared by M. - - Note that the processing restrictions on "$vocabulary" mean that - meta-schemas that reference other meta-schemas using "$ref" or - similar keywords do not automatically inherit the vocabulary - declarations of those other meta-schemas. All such declarations - must be repeated in the root of each schema document intended - for use as a meta-schema. This is demonstrated in - the example meta-schema. - - - If "$vocabulary" is absent, an implementation MAY determine - behavior based on the meta-schema if it is recognized from the - URI value of the referring schema's "$schema" keyword. - If the meta-schema, as referenced by the schema, is not recognized, - then implementations MUST assume the use of the core vocabulary, - and SHOULD assume the use of all vocabularies in this - specification and the companion Validation specification. - +
+ + If "$vocabulary" is absent, an implementation MAY determine + behavior based on the meta-schema if it is recognized from the + URI value of the referring schema's "$schema" keyword. + This is how behavior (such as Hyper-Schema usage) has been + recognized prior to the existence of vocabularies. + + + If the meta-schema, as referenced by the schema, is not recognized, + or is missing, then the behavior is implementation-defined. + If the implementation + proceeds with processing the schema, it MUST assume the use of the + core vocabulary. If the implementation is built for a specific purpose, + then it SHOULD assume the use of all of the most relevant vocabularies + for that purpose. + + + For example, an implementation that is a validator + SHOULD assume the use of all vocabularies in this + specification and the companion Validation specification. + +
+
+ + Note that the processing restrictions on "$vocabulary" mean that + meta-schemas that reference other meta-schemas using "$ref" or + similar keywords do not automatically inherit the vocabulary + declarations of those other meta-schemas. All such declarations + must be repeated in the root of each schema document intended + for use as a meta-schema. This is demonstrated in + the example meta-schema. + +
@@ -956,7 +976,7 @@ the course of one session. - Implementations MAY allow a schema to be passed as a meta-schema, + Implementations MAY allow a schema to be explicitly passed as a meta-schema, for implementation-specific purposes, such as pre-loading a commonly used meta-schema and checking its vocabulary support requirements up front. Meta-schema authors MUST NOT expect such features to be @@ -964,6 +984,23 @@
+ + Vocabulary authors SHOULD + take care to avoid keyword name collisions if the vocabulary is intended + for broad use, and potentially combined with other vocabularies. JSON + Schema does not provide any formal namespacing system, but also does + not constrain keyword names, allowing for any number of namespacing + approaches. + + + Vocabularies may build on each other, such as by defining the behavior + of their keywords with respect to the behavior of keywords from another + vocabulary, or by using a keyword from another vocabulary with + a restricted or expanded set of acceptable values. Not all such + vocabulary re-use will result in a new vocabulary that is compatible + with the vocabulary on which it is built. Vocabulary authors SHOULD + clearly document what level of compatibility, if any, is expected. + Meta-schema authors SHOULD NOT use "$vocabulary" to combine multiple vocabularies that define conflicting syntax or semantics for the same @@ -974,9 +1011,9 @@ Vocabulary authors SHOULD provide a meta-schema that validates the - expected usage of the vocabulary's keywords. Such meta-schemas - SHOULD NOT forbid additional keywords, and MUST NOT forbid - the "$id", "$schema", or "$vocabulary" keywords in the root schema. + expected usage of the vocabulary's keywords on their own. Such meta-schemas + SHOULD NOT forbid additional keywords, and MUST NOT forbid any + keywords from the Core vocabulary. It is RECOMMENDED that meta-schema authors reference each vocabulary's @@ -984,6 +1021,12 @@ although other mechanisms for constructing the meta-schema may be appropriate for certain use cases. + + The recursive nature of meta-schemas makes the "$recursiveAnchor" + and "$recursiveRef" keywords particularly useful for extending + existing meta-schemas, as can be seen in the JSON Hyper-Schema meta-schema + which extends the Validation meta-schema. + Meta-schemas MAY impose additional constraints, including describing keywords not present in any vocabulary, beyond what the meta-schemas From c50a8ce279344d4cac7221e0f400767961170e52 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 7 Aug 2019 08:49:42 +0100 Subject: [PATCH 047/780] Fix typo --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index dc406f50..d950743c 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1328,7 +1328,7 @@ as "original" as it is the schema to be extended, describes an object with one string property and one recursive reference property, "r". The second schema, identified as "extension", - references the first, and describes an additional things" property, + references the first, and describes an additional "things" property, which is an array of recursive references. It also repeats the description of "r" from the original schema. From 646116e09153d9067e9aeaedbf48ece4721cf7ca Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 9 Aug 2019 00:16:22 -0700 Subject: [PATCH 048/780] Review feedback on vocabs. --- jsonschema-core.xml | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0f745657..ff9c7e16 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -369,13 +369,16 @@ A schema vocabulary, or simply a vocabulary, is a set of keywords, their syntax, and their semantics. A vocabulary is generally organized - around a particular purpose. Different uses of JSON Schema will + around a particular purpose. Different uses of JSON Schema, such + as validation, hypermedia, or user interface generation, will involve different sets of vocabularies. Vocabularies are the primary unit of re-use in JSON Schema, as schema authors can indicate what vocabularies are required or optional in - order to process the schema. While keywords can be supported outside + order to process the schema. Since vocabularies are identified by URIs + in the meta-schema, generic implementations can load extensions to support + previously unkonw vocabularies. While keywords can be supported outside of any vocabulary, there is no analogous mechanism to indicate individual keyword usage. @@ -798,7 +801,7 @@
Two concepts, meta-schemas and vocabularies, are used to inform an implementation - how to interpret a schema. Every schema has a meta-schema, typically identified + how to interpret a schema. Every schema has a meta-schema, which can be declared using the "$schema" keyword. @@ -824,7 +827,8 @@ vocabularies to be combined in different ways, and for meta-schema authors to impose additional constraints such as forbidding certain keywords, or performing unusually strict syntactical validation, as might be done - during a development and testing cycle. + during a development and testing cycle. Each vocabulary typically identifies + a meta-schema consisting only of the vocabulary's keywords. Meta-schema authoring is an advanced usage of JSON Schema, so the design of From 0c32da95188cb6e3cb390dd9aaceea9fcb7746f8 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 9 Aug 2019 12:28:21 -0700 Subject: [PATCH 049/780] Give ECMA 262 reference section for RegExp dialect. --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index dc406f50..8754d055 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -552,8 +552,8 @@ Keywords MAY use regular expressions to express constraints, or constrain the instance value to be a regular expression. - These regular expressions SHOULD be valid according to the - ECMA 262 regular expression dialect. + These regular expressions SHOULD be valid according to the regular expression + dialect described in ECMA 262, section 15.10.1. Furthermore, given the high disparity in regular expression constructs support, From 13c0129f75e4271ddbdbdcedcf59684b0c05cec6 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 9 Aug 2019 15:50:26 -0700 Subject: [PATCH 050/780] Consolidate keyword behavior sections Several sections related to fundamental keyword behavior had ended up scattered around the document. The bit about scopes makes more sense near the top of the keyword behaviors section, as it is really talking about how keywords interact with the concept of scopes. It probably does not need to be in the basic description of schema documents, where it was. The section on referenced and referencing keywords is closely associated with applicators, so it becomes a subsection of that. Finally, the entire section on how to collect annotations gets moved under the annotations section in keyword behaviors. This consolidates all generic keyword behavior descriptions into section 7. Keyword Behaviors. As you would expect from the name. --- jsonschema-core.xml | 530 ++++++++++++++++++++++---------------------- 1 file changed, 265 insertions(+), 265 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 104333da..9067b4cd 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -426,93 +426,6 @@ As with the root schema, a subschema is either an object or a boolean.
-
- - While most JSON Schema keywords can be evaluated on their own, - or at most need to take into account the values or results of - adjacent keywords in the same schema object, a few have more - complex behavior. - - - The lexical scope of a keyword is determined by the nested JSON - data structure of objects and arrays. The largest such scope - is an entire schema document. The smallest scope is a single - schema object with no subschemas. - - - Keywords MAY be defined with a partial value, such as a URI-reference, - which must be resolved against another value, such as another - URI-reference or a full URI, which is found through the lexical - structure of the JSON document. The "$id" core keyword and - the "base" JSON Hyper-Schema keyword are examples of this sort - of behavior. Additionally, "$ref" and "$recursiveRef" from - this specification resolve their values in this way, although - they do not change how further values are resolved. - - - Note that some keywords, such as "$schema", apply to the lexical - scope of the entire schema document, and therefore MUST only - appear in the document's root schema. - - - Other keywords may take into account the dynamic scope that - exists during the evaluation of a schema, typically together - with an instance document. The outermost dynamic scope is the - root schema of the schema document in which processing begins. - The path from this root schema to any particular keyword (that - includes any "$ref" and "$recursiveRef" keywords that may have - been resolved) is considered the keyword's "validation path." - - Or should this be the schema object at which processing - begins, even if it is not a root? This has some implications - for the case where "$recursiveAnchor" is only allowed in the - root schema but processing begins in a subschema. - - - - Lexical and dynamic scopes align until a reference keyword - is encountered. While following the reference keyword moves processing - from one lexical scope into a different one, from the perspective - of dynamic scope, following reference is no different from descending - into a subschema present as a value. A keyword on the far side of - that reference that resolves information through the dynamic scope - will consider the originating side of the reference to be their - dynamic parent, rather than examining the local lexically enclosing parent. - - - The concept of dynamic scope is primarily used with "$recursiveRef" and - "$recursiveAnchor", and should be considered an advanced feature - and used with caution when defining additional keywords. It also appears - when reporting errors and collected annotations, as it may be possible - to revisit the same lexical scope repeatedly with different dynamic - scopes. In such cases, it is important to inform the user of the - dynamic path that produced the error or annotation. - -
-
- - As noted in , an applicator keyword may - refer to a schema to be applied, rather than including it as a - subschema in the applicator's value. In such situations, the - schema being applied is known as the referenced schema, while - the schema containing the applicator keyword is the referencing schema. - - - While root schemas and subschemas are static concepts based on a - schema's position within a schema document, referenced and referencing - schemas are dynamic. Different pairs of schemas may find themselves - in various referenced and referencing arrangements during the evaluation - of an instance against a schema. - - - For some by-reference applicators, such as - "$ref", the referenced schema can be determined - by static analysis of the schema document's lexical scope. Others, - such as "$recursiveRef" and "$recursiveAnchor", may make use of dynamic - scoping, and therefore only be resolvable in the process of evaluating - the schema with an instance. - -
@@ -668,6 +581,69 @@ due to the need to examine all subschemas for annotation collection, including those that cannot further change the assertion result. +
+ + While most JSON Schema keywords can be evaluated on their own, + or at most need to take into account the values or results of + adjacent keywords in the same schema object, a few have more + complex behavior. + + + The lexical scope of a keyword is determined by the nested JSON + data structure of objects and arrays. The largest such scope + is an entire schema document. The smallest scope is a single + schema object with no subschemas. + + + Keywords MAY be defined with a partial value, such as a URI-reference, + which must be resolved against another value, such as another + URI-reference or a full URI, which is found through the lexical + structure of the JSON document. The "$id" core keyword and + the "base" JSON Hyper-Schema keyword are examples of this sort + of behavior. Additionally, "$ref" and "$recursiveRef" from + this specification resolve their values in this way, although + they do not change how further values are resolved. + + + Note that some keywords, such as "$schema", apply to the lexical + scope of the entire schema document, and therefore MUST only + appear in the document's root schema. + + + Other keywords may take into account the dynamic scope that + exists during the evaluation of a schema, typically together + with an instance document. The outermost dynamic scope is the + root schema of the schema document in which processing begins. + The path from this root schema to any particular keyword (that + includes any "$ref" and "$recursiveRef" keywords that may have + been resolved) is considered the keyword's "validation path." + + Or should this be the schema object at which processing + begins, even if it is not a root? This has some implications + for the case where "$recursiveAnchor" is only allowed in the + root schema but processing begins in a subschema. + + + + Lexical and dynamic scopes align until a reference keyword + is encountered. While following the reference keyword moves processing + from one lexical scope into a different one, from the perspective + of dynamic scope, following reference is no different from descending + into a subschema present as a value. A keyword on the far side of + that reference that resolves information through the dynamic scope + will consider the originating side of the reference to be their + dynamic parent, rather than examining the local lexically enclosing parent. + + + The concept of dynamic scope is primarily used with "$recursiveRef" and + "$recursiveAnchor", and should be considered an advanced feature + and used with caution when defining additional keywords. It also appears + when reporting errors and collected annotations, as it may be possible + to revisit the same lexical scope repeatedly with different dynamic + scopes. In such cases, it is important to inform the user of the + dynamic path that produced the error or annotation. + +
Keyword behavior MAY be defined in terms of the annotation results @@ -736,6 +712,30 @@ Annotation results are combined according to the rules specified by each annotation keyword. +
+ + As noted in , an applicator keyword may + refer to a schema to be applied, rather than including it as a + subschema in the applicator's value. In such situations, the + schema being applied is known as the referenced schema, while + the schema containing the applicator keyword is the referencing schema. + + + While root schemas and subschemas are static concepts based on a + schema's position within a schema document, referenced and referencing + schemas are dynamic. Different pairs of schemas may find themselves + in various referenced and referencing arrangements during the evaluation + of an instance against a schema. + + + For some by-reference applicators, such as + "$ref", the referenced schema can be determined + by static analysis of the schema document's lexical scope. Others, + such as "$recursiveRef" and "$recursiveAnchor", may make use of dynamic + scoping, and therefore only be resolvable in the process of evaluating + the schema with an instance. + +
@@ -798,6 +798,184 @@ annotations requires examining all schemas that apply to an instance location, even if they cannot change the overall assertion result. + +
+ + Annotations are collected by keywords that explicitly define + annotation-collecting behavior. Note that boolean schemas cannot + produce annotations as they do not make use of keywords. + + + A collected annotation MUST include the following information: + + + The name of the keyword that produces the annotation + + + The instance location to which it is attached, as a JSON Pointer + + + The schema location path, indicating how reference keywords + such as "$ref" were followed to reach the absolute schema location. + + + The absolute schema location of the attaching keyword, as a URI. + This MAY be omitted if it is the same as the schema location path + from above. + + + The attached value(s) + + + + + If the same keyword attaches values from multiple schema locations + to the same instance location, and the annotation defines a process + for combining such values, then the combined value MUST also be associated + with the instance location. + +
+ + Applications MAY make decisions on which of multiple annotation values + to use based on the schema location that contributed the value. + This is intended to allow flexible usage. Collecting the schema location + facilitates such usage. + + + For example, consider this schema, which uses annotations and assertions from + the Validation specification: + +
+ + Note that some lines are wrapped for clarity. + + + + +
+ + In this example, both Feature A and Feature B make use of the re-usable + "enabledToggle" schema. That schema uses the "title", "description", + and "default" annotations, none of which define special behavior for + handling multiple values. Therefore the application has to decide how + to handle the additional "default" value for Feature A, and the additional + "description" value for Feature B. + + + The application programmer and the schema author need to agree on the + usage. For this example, let's assume that they agree that the most + specific "default" value will be used, and any additional, more generic + "default" values will be silently ignored. Let's also assume that they + agree that all "description" text is to be used, starting with the most + generic, and ending with the most specific. This requires the schema + author to write descriptions that work when combined in this way. + + + The application can use the schema location path to determine which + values are which. The values in the feature's immediate "enabled" + property schema are more specific, while the values under the re-usable + schema that is referenced to with "$ref" are more generic. The schema + location path will show whether each value was found by crossing a + "$ref" or not. + + + Feature A will therefore use a default value of true, while Feature B + will use the generic default value of null. Feature A will only + have the generic description from the "enabledToggle" schema, while + Feature B will use that description, and also append its locally + defined description that explains how to interpret a null value. + + + Note that there are other reasonable approaches that a different application + might take. For example, an application may consider the presence of + two different values for "default" to be an error, regardless of their + schema locations. + +
+
+ + Schema objects that produce a false assertion result MUST NOT + produce any annotation results, whether from their own keywords + or from keywords in subschemas. + + + Note that the overall schema results may still include annotations + collected from other schema locations. Given this schema: + +
+ + + +
+ + And the instance "This is a string", the + title annotation "Integer Value" is discarded because the type assertion + in that schema object fails. The title annotation "String Value" + is kept, as the instance passes the string type assertions. + +
+
+ + In addition to possibly defining annotation results of their own, + applicator keywords aggregate the annotations collected in their + subschema(s) or referenced schema(s). The rules for aggregating + annotation values are defined by each annotation keyword, and are + not directly affected by the logic used for combining assertion + results. + +
+
@@ -1766,184 +1944,6 @@
-
- - Annotations are collected by keywords that explicitly define - annotation-collecting behavior. Note that boolean schemas cannot - produce annotations as they do not make use of keywords. - - - A collected annotation MUST include the following information: - - - The name of the keyword that produces the annotation - - - The instance location to which it is attached, as a JSON Pointer - - - The schema location path, indicating how reference keywords - such as "$ref" were followed to reach the absolute schema location. - - - The absolute schema location of the attaching keyword, as a URI. - This MAY be omitted if it is the same as the schema location path - from above. - - - The attached value(s) - - - - - If the same keyword attaches values from multiple schema locations - to the same instance location, and the annotation defines a process - for combining such values, then the combined value MUST also be associated - with the instance location. - -
- - Applications MAY make decisions on which of multiple annotation values - to use based on the schema location that contributed the value. - This is intended to allow flexible usage. Collecting the schema location - facilitates such usage. - - - For example, consider this schema, which uses annotations and assertions from - the Validation specification: - -
- - Note that some lines are wrapped for clarity. - - - - -
- - In this example, both Feature A and Feature B make use of the re-usable - "enabledToggle" schema. That schema uses the "title", "description", - and "default" annotations, none of which define special behavior for - handling multiple values. Therefore the application has to decide how - to handle the additional "default" value for Feature A, and the additional - "description" value for Feature B. - - - The application programmer and the schema author need to agree on the - usage. For this example, let's assume that they agree that the most - specific "default" value will be used, and any additional, more generic - "default" values will be silently ignored. Let's also assume that they - agree that all "description" text is to be used, starting with the most - generic, and ending with the most specific. This requires the schema - author to write descriptions that work when combined in this way. - - - The application can use the schema location path to determine which - values are which. The values in the feature's immediate "enabled" - property schema are more specific, while the values under the re-usable - schema that is referenced to with "$ref" are more generic. The schema - location path will show whether each value was found by crossing a - "$ref" or not. - - - Feature A will therefore use a default value of true, while Feature B - will use the generic default value of null. Feature A will only - have the generic description from the "enabledToggle" schema, while - Feature B will use that description, and also append its locally - defined description that explains how to interpret a null value. - - - Note that there are other reasonable approaches that a different application - might take. For example, an application may consider the presence of - two different values for "default" to be an error, regardless of their - schema locations. - -
-
- - Schema objects that produce a false assertion result MUST NOT - produce any annotation results, whether from their own keywords - or from keywords in subschemas. - - - Note that the overall schema results may still include annotations - collected from other schema locations. Given this schema: - -
- - - -
- - And the instance "This is a string", the - title annotation "Integer Value" is discarded because the type assertion - in that schema object fails. The title annotation "String Value" - is kept, as the instance passes the string type assertions. - -
-
- - In addition to possibly defining annotation results of their own, - applicator keywords aggregate the annotations collected in their - subschema(s) or referenced schema(s). The rules for aggregating - annotation values are defined by each annotation keyword, and are - not directly affected by the logic used for combining assertion - results. - -
-
-
This section defines a vocabulary of applicator keywords that From 5409706ab9c9bacffc8c7df3c4c4add828fb6caa Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 9 Aug 2019 15:42:06 -0700 Subject: [PATCH 051/780] Wrap the core vocab in the core vocab section. Really, it should be like any other vocabulary, grouped into a single section. The text will get some further tweaking to fix issues related to having to introduce a vocabulary before the concept of vocabularies are fully introduced. --- jsonschema-core.xml | 1524 +++++++++++++++++++++---------------------- 1 file changed, 762 insertions(+), 762 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 2b1d6f98..e97c6494 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1005,313 +1005,312 @@
- -
+
- Two concepts, meta-schemas and vocabularies, are used to inform an implementation - how to interpret a schema. Every schema has a meta-schema, which can be declared - using the "$schema" keyword. + Keywords declared in in this specification that begin with "$" make up + the JSON Schema Core vocabulary. These keywords are either required in + order process any schema or meta-schema, including those split across + multiple documents, or exist to reserve keywords for purposes that + require guaranteed interoperability. - The meta-schema serves two purposes: - - - The "$vocabulary" keyword, when it appears in a meta-schema, declares - which vocabularies are available to be used in schemas that refer - to that meta-schema. Vocabularies define keyword semantics, - as well as their general syntax. - - - A schema MUST successfully validate against its meta-schema, which - constrains the syntax of the available keywords. The syntax described - is expected to be compatible with the vocabularies declared; while - it is possible to describe an incompatible syntax, such a meta-schema - would be unlikely to be useful. - - + The Core vocabulary MUST be considered mandatory at all times, in order + to bootstrap the processing of further vocabularies. Meta-schemas + that use "$vocabulary" MUST explicitly list the Core vocabulary, + which MUST have a value of true indicating that it is required. - Meta-schemas are separate from vocabularies to allow for - vocabularies to be combined in different ways, and for meta-schema authors - to impose additional constraints such as forbidding certain keywords, or - performing unusually strict syntactical validation, as might be done - during a development and testing cycle. Each vocabulary typically identifies - a meta-schema consisting only of the vocabulary's keywords. + The behavior of a false value for this vocabulary (and only this + vocabulary) is undefined, as is the behavior when "$vocabulary" + is present but the Core vocabulary is not included. However, it + is RECOMMENDED that implementations detect these cases and raise + an error when they occur. - Meta-schema authoring is an advanced usage of JSON Schema, so the design of - meta-schema features emphasizes flexibility over simplicity. + Meta-schemas that do not use "$vocabulary" MUST be considered to + require the Core vocabulary as if its URI were present with a value of true. -
- - The "$schema" keyword is both used as a JSON Schema feature set identifier and - as the identifier of a resource which is itself a JSON Schema, which describes the - set of valid schemas written for this particular feature set. - - - The value of this keyword MUST be a URI - (containing a scheme) and this URI MUST be normalized. - The current schema MUST be valid against the meta-schema identified by this URI. - - - If this URI identifies a retrievable resource, that resource SHOULD be of - media type "application/schema+json". - - - The "$schema" keyword SHOULD be used in a root schema. - It MUST NOT appear in subschemas. If absent from the root schema, the - resulting behavior is implementation-defined. - - - - Using multiple "$schema" keywords in the same document would imply that the - feature set and therefore behavior can change within a document. This would - necessitate resolving a number of implementation concerns that have not yet - been clearly defined. So, while the pattern of using "$schema" only in root - schemas is likely to remain the best practice for schema authoring, - implementation behavior is subject to be revised or liberalized in - future drafts. - - - - - Values for this property are defined elsewhere in this and other documents, - and by other parties. - -
-
- - The "$vocabulary" keyword is used in meta-schemas to identify the - vocabularies available for use in schemas described by that meta-schema. - It is also used to indicate whether each vocabulary is required or optional, - in the sense that an implementation MUST understand the required vocabularies - in order to successfully process the schema. - - - The value of this keyword MUST be an object. The property names in the - object MUST be URIs (containing a scheme) and this URI MUST be normalized. - Each URI that appears as a property name identifies a specific set of - keywords and their semantics. - - - The URI MAY be a URL, but the nature of the retrievable resource is - currently undefined, and reserved for future use. Vocabulary authors - MAY use the URL of the vocabulary specification, in a human-readable - media type such as text/html or text/plain, as the vocabulary URI. - - Vocabulary documents may be added shortly, or in the next draft. - For now, identifying the keyword set is deemed sufficient as that, - along with meta-schema validation, is how the current "vocabularies" - work today. Any future vocabulary document format will be specified - as a JSON document, so using text/html or other non-JSON formats - in the meantime will not produce any future ambiguity. - - + + The current URI for the Core vocabulary is: + . + + + The current URI for the corresponding meta-schema is: + . + + + Updated vocabulary and meta-schema URIs MAY be published between + specification drafts in order to correct errors. Implementations + SHOULD consider URIs dated after this specification draft and + before the next to indicate the same syntax and semantics + as those listed here. + + +
- The values of the object properties MUST be booleans. - 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 MAY choose to proceed with processing - such schemas. + Two concepts, meta-schemas and vocabularies, are used to inform an implementation + how to interpret a schema. Every schema has a meta-schema, which can be declared + using the "$schema" keyword. - When processing a schema that uses unrecognized vocabularies, keywords - declared by those vocabularies are treated like any other unrecognized - keyword, and ignored. + The meta-schema serves two purposes: + + + The "$vocabulary" keyword, when it appears in a meta-schema, declares + which vocabularies are available to be used in schemas that refer + to that meta-schema. Vocabularies define keyword semantics, + as well as their general syntax. + + + A schema MUST successfully validate against its meta-schema, which + constrains the syntax of the available keywords. The syntax described + is expected to be compatible with the vocabularies declared; while + it is possible to describe an incompatible syntax, such a meta-schema + would be unlikely to be useful. + + - The "$vocabulary" keyword SHOULD be used in the root schema of any schema - document intended for use as a meta-schema. It MUST NOT appear in subschemas. + Meta-schemas are separate from vocabularies to allow for + vocabularies to be combined in different ways, and for meta-schema authors + to impose additional constraints such as forbidding certain keywords, or + performing unusually strict syntactical validation, as might be done + during a development and testing cycle. Each vocabulary typically identifies + a meta-schema consisting only of the vocabulary's keywords. - The "$vocabulary" keyword MUST be ignored in schema documents that - are not being processed as a meta-schema. This allows validating - a meta-schema M against its own meta-schema M' without requiring - the validator to understand the vocabularies declared by M. + Meta-schema authoring is an advanced usage of JSON Schema, so the design of + meta-schema features emphasizes flexibility over simplicity. -
+
+ + The "$schema" keyword is both used as a JSON Schema feature set identifier and + as the identifier of a resource which is itself a JSON Schema, which describes the + set of valid schemas written for this particular feature set. + - If "$vocabulary" is absent, an implementation MAY determine - behavior based on the meta-schema if it is recognized from the - URI value of the referring schema's "$schema" keyword. - This is how behavior (such as Hyper-Schema usage) has been - recognized prior to the existence of vocabularies. + The value of this keyword MUST be a URI + (containing a scheme) and this URI MUST be normalized. + The current schema MUST be valid against the meta-schema identified by this URI. - If the meta-schema, as referenced by the schema, is not recognized, - or is missing, then the behavior is implementation-defined. - If the implementation - proceeds with processing the schema, it MUST assume the use of the - core vocabulary. If the implementation is built for a specific purpose, - then it SHOULD assume the use of all of the most relevant vocabularies - for that purpose. + If this URI identifies a retrievable resource, that resource SHOULD be of + media type "application/schema+json". - For example, an implementation that is a validator - SHOULD assume the use of all vocabularies in this - specification and the companion Validation specification. + The "$schema" keyword SHOULD be used in a root schema. + It MUST NOT appear in subschemas. If absent from the root schema, the + resulting behavior is implementation-defined. + + + + Using multiple "$schema" keywords in the same document would imply that the + feature set and therefore behavior can change within a document. This would + necessitate resolving a number of implementation concerns that have not yet + been clearly defined. So, while the pattern of using "$schema" only in root + schemas is likely to remain the best practice for schema authoring, + implementation behavior is subject to be revised or liberalized in + future drafts. + + + + + Values for this property are defined elsewhere in this and other documents, + and by other parties.
-
+
- Note that the processing restrictions on "$vocabulary" mean that - meta-schemas that reference other meta-schemas using "$ref" or - similar keywords do not automatically inherit the vocabulary - declarations of those other meta-schemas. All such declarations - must be repeated in the root of each schema document intended - for use as a meta-schema. This is demonstrated in - the example meta-schema. + The "$vocabulary" keyword is used in meta-schemas to identify the + vocabularies available for use in schemas described by that meta-schema. + It is also used to indicate whether each vocabulary is required or optional, + in the sense that an implementation MUST understand the required vocabularies + in order to successfully process the schema. + + The value of this keyword MUST be an object. The property names in the + object MUST be URIs (containing a scheme) and this URI MUST be normalized. + Each URI that appears as a property name identifies a specific set of + keywords and their semantics. + + + The URI MAY be a URL, but the nature of the retrievable resource is + currently undefined, and reserved for future use. Vocabulary authors + MAY use the URL of the vocabulary specification, in a human-readable + media type such as text/html or text/plain, as the vocabulary URI. + + Vocabulary documents may be added shortly, or in the next draft. + For now, identifying the keyword set is deemed sufficient as that, + along with meta-schema validation, is how the current "vocabularies" + work today. Any future vocabulary document format will be specified + as a JSON document, so using text/html or other non-JSON formats + in the meantime will not produce any future ambiguity. + + + + The values of the object properties MUST be booleans. + 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 MAY choose to proceed with processing + such schemas. + + + When processing a schema that uses unrecognized vocabularies, keywords + declared by those vocabularies are treated like any other unrecognized + keyword, and ignored. + + + The "$vocabulary" keyword SHOULD be used in the root schema of any schema + document intended for use as a meta-schema. It MUST NOT appear in subschemas. + + + The "$vocabulary" keyword MUST be ignored in schema documents that + are not being processed as a meta-schema. This allows validating + a meta-schema M against its own meta-schema M' without requiring + the validator to understand the vocabularies declared by M. + +
+ + If "$vocabulary" is absent, an implementation MAY determine + behavior based on the meta-schema if it is recognized from the + URI value of the referring schema's "$schema" keyword. + This is how behavior (such as Hyper-Schema usage) has been + recognized prior to the existence of vocabularies. + + + If the meta-schema, as referenced by the schema, is not recognized, + or is missing, then the behavior is implementation-defined. + If the implementation + proceeds with processing the schema, it MUST assume the use of the + core vocabulary. If the implementation is built for a specific purpose, + then it SHOULD assume the use of all of the most relevant vocabularies + for that purpose. + + + For example, an implementation that is a validator + SHOULD assume the use of all vocabularies in this + specification and the companion Validation specification. + +
+
+ + Note that the processing restrictions on "$vocabulary" mean that + meta-schemas that reference other meta-schemas using "$ref" or + similar keywords do not automatically inherit the vocabulary + declarations of those other meta-schemas. All such declarations + must be repeated in the root of each schema document intended + for use as a meta-schema. This is demonstrated in + the example meta-schema. + +
-
-
- - Implementations MUST recognize a schema as a meta-schema if it - is being examined because it was identified as such by another - schema's "$schema" keyword. This means that a single schema - document might sometimes be considered a regular schema, and - other times be considered a meta-schema. - - - In the case of examining a schema which is its own meta-schema, - when an implementation begins processing it as a regular schema, - it is processed under those rules. However, when loaded a second - time as a result of checking its own "$schema" value, it is treated - as a meta-schema. So the same document is processed both ways in - the course of one session. - - - Implementations MAY allow a schema to be explicitly passed as a meta-schema, - for implementation-specific purposes, such as pre-loading a commonly - used meta-schema and checking its vocabulary support requirements - up front. Meta-schema authors MUST NOT expect such features to be - interoperable across implementations. - -
-
- - Vocabulary authors SHOULD - take care to avoid keyword name collisions if the vocabulary is intended - for broad use, and potentially combined with other vocabularies. JSON - Schema does not provide any formal namespacing system, but also does - not constrain keyword names, allowing for any number of namespacing - approaches. - - - Vocabularies may build on each other, such as by defining the behavior - of their keywords with respect to the behavior of keywords from another - vocabulary, or by using a keyword from another vocabulary with - a restricted or expanded set of acceptable values. Not all such - vocabulary re-use will result in a new vocabulary that is compatible - with the vocabulary on which it is built. Vocabulary authors SHOULD - clearly document what level of compatibility, if any, is expected. - - - Meta-schema authors SHOULD NOT use "$vocabulary" to combine multiple - vocabularies that define conflicting syntax or semantics for the same - keyword. As semantic conflicts are not generally detectable through - schema validation, implementations are not expected to detect such - conflicts. If conflicting vocabularies are declared, the resulting - behavior is undefined. - - - Vocabulary authors SHOULD provide a meta-schema that validates the - expected usage of the vocabulary's keywords on their own. Such meta-schemas - SHOULD NOT forbid additional keywords, and MUST NOT forbid any - keywords from the Core vocabulary. - - - It is RECOMMENDED that meta-schema authors reference each vocabulary's - meta-schema using the "allOf" keyword, - although other mechanisms for constructing the meta-schema may be - appropriate for certain use cases. - - - The recursive nature of meta-schemas makes the "$recursiveAnchor" - and "$recursiveRef" keywords particularly useful for extending - existing meta-schemas, as can be seen in the JSON Hyper-Schema meta-schema - which extends the Validation meta-schema. - - - Meta-schemas MAY impose additional constraints, including describing - keywords not present in any vocabulary, beyond what the meta-schemas - associated with the declared vocabularies describe. This allows for - restricting usage to a subset of a vocabulary, and for validating - locally defined keywords not intended for re-use. - - - However, meta-schemas SHOULD NOT contradict any vocabularies that - they declare, such as by requiring a different JSON type than - the vocabulary expects. The resulting behavior is undefined. - - - Meta-schemas intended for local use, with no need to test for - vocabulary support in arbitrary implementations, can safely omit - "$vocabulary" entirely. - -
-
- - Keywords declared in in this specification that begin with "$" make up - the JSON Schema Core vocabulary. These keywords are either required in - order process any schema or meta-schema, including those split across - multiple documents, or exist to reserve keywords for purposes that - require guaranteed interoperability. - - - The Core vocabulary MUST be considered mandatory at all times, in order - to bootstrap the processing of further vocabularies. Meta-schemas - that use "$vocabulary" MUST explicitly list the Core vocabulary, - which MUST have a value of true indicating that it is required. - - - The behavior of a false value for this vocabulary (and only this - vocabulary) is undefined, as is the behavior when "$vocabulary" - is present but the Core vocabulary is not included. However, it - is RECOMMENDED that implementations detect these cases and raise - an error when they occur. - - - Meta-schemas that do not use "$vocabulary" MUST be considered to - require the Core vocabulary as if its URI were present with a value of true. - - - The current URI for the Core vocabulary is: - . - - - The current URI for the corresponding meta-schema is: - . - - - Updated vocabulary and meta-schema URIs MAY be published between - specification drafts in order to correct errors. Implementations - SHOULD consider URIs dated after this specification draft and - before the next to indicate the same syntax and semantics - as those listed here. - -
-
-
- - This meta-schema explicitly declares both the Core and Applicator - vocabularies, and combines their meta-schemas with an "allOf". - It additionally restricts the usage of the Applicator vocabulary - by forbidding the keyword prefixed with "unevaluated". It also - describes a keyword, "localKeyword", that is not part of either - vocabulary. Note that it is its own meta-schema, - as it relies on both the Core vocabulary (as all schemas do) - and the Applicator vocabulary (for "allOf"). - - +
+ + Implementations MUST recognize a schema as a meta-schema if it + is being examined because it was identified as such by another + schema's "$schema" keyword. This means that a single schema + document might sometimes be considered a regular schema, and + other times be considered a meta-schema. + + + In the case of examining a schema which is its own meta-schema, + when an implementation begins processing it as a regular schema, + it is processed under those rules. However, when loaded a second + time as a result of checking its own "$schema" value, it is treated + as a meta-schema. So the same document is processed both ways in + the course of one session. + + + Implementations MAY allow a schema to be explicitly passed as a meta-schema, + for implementation-specific purposes, such as pre-loading a commonly + used meta-schema and checking its vocabulary support requirements + up front. Meta-schema authors MUST NOT expect such features to be + interoperable across implementations. + +
+
+ + Vocabulary authors SHOULD + take care to avoid keyword name collisions if the vocabulary is intended + for broad use, and potentially combined with other vocabularies. JSON + Schema does not provide any formal namespacing system, but also does + not constrain keyword names, allowing for any number of namespacing + approaches. + + + Vocabularies may build on each other, such as by defining the behavior + of their keywords with respect to the behavior of keywords from another + vocabulary, or by using a keyword from another vocabulary with + a restricted or expanded set of acceptable values. Not all such + vocabulary re-use will result in a new vocabulary that is compatible + with the vocabulary on which it is built. Vocabulary authors SHOULD + clearly document what level of compatibility, if any, is expected. + + + Meta-schema authors SHOULD NOT use "$vocabulary" to combine multiple + vocabularies that define conflicting syntax or semantics for the same + keyword. As semantic conflicts are not generally detectable through + schema validation, implementations are not expected to detect such + conflicts. If conflicting vocabularies are declared, the resulting + behavior is undefined. + + + Vocabulary authors SHOULD provide a meta-schema that validates the + expected usage of the vocabulary's keywords on their own. Such meta-schemas + SHOULD NOT forbid additional keywords, and MUST NOT forbid any + keywords from the Core vocabulary. + + + It is RECOMMENDED that meta-schema authors reference each vocabulary's + meta-schema using the "allOf" keyword, + although other mechanisms for constructing the meta-schema may be + appropriate for certain use cases. + + + The recursive nature of meta-schemas makes the "$recursiveAnchor" + and "$recursiveRef" keywords particularly useful for extending + existing meta-schemas, as can be seen in the JSON Hyper-Schema meta-schema + which extends the Validation meta-schema. + + + Meta-schemas MAY impose additional constraints, including describing + keywords not present in any vocabulary, beyond what the meta-schemas + associated with the declared vocabularies describe. This allows for + restricting usage to a subset of a vocabulary, and for validating + locally defined keywords not intended for re-use. + + + However, meta-schemas SHOULD NOT contradict any vocabularies that + they declare, such as by requiring a different JSON type than + the vocabulary expects. The resulting behavior is undefined. + + + Meta-schemas intended for local use, with no need to test for + vocabulary support in arbitrary implementations, can safely omit + "$vocabulary" entirely. + +
+
+
+ + This meta-schema explicitly declares both the Core and Applicator + vocabularies, and combines their meta-schemas with an "allOf". + It additionally restricts the usage of the Applicator vocabulary + by forbidding the keyword prefixed with "unevaluated". It also + describes a keyword, "localKeyword", that is not part of either + vocabulary. Note that it is its own meta-schema, + as it relies on both the Core vocabulary (as all schemas do) + and the Applicator vocabulary (for "allOf"). + + - - - As shown above, even though each of the referenced standard - meta-schemas declares its corresponding vocabulary, this new - meta-schema must re-declare them for itself. It would be - valid to leave the core vocabulary out of the "$vocabulary" keyword, - but it needs to be referenced through the "allOf" keyword in order - for its terms to be validated. There is no special case for - validation of core keywords. - -
- - The standard meta-schemas that combine all vocabularies defined by - the Core and Validation specification, and that combine all vocabularies - defined by those specifications as well as the Hyper-Schema specification, - demonstrate additional complex combinations. These URIs for these - meta-schemas may be found in the Validation and Hyper-Schema specifications, - respectively. - + + + As shown above, even though each of the referenced standard + meta-schemas declares its corresponding vocabulary, this new + meta-schema must re-declare them for itself. It would be + valid to leave the core vocabulary out of the "$vocabulary" keyword, + but it needs to be referenced through the "allOf" keyword in order + for its terms to be validated. There is no special case for + validation of core keywords. + +
+ + The standard meta-schemas that combine all vocabularies defined by + the Core and Validation specification, and that combine all vocabularies + defined by those specifications as well as the Hyper-Schema specification, + demonstrate additional complex combinations. These URIs for these + meta-schemas may be found in the Validation and Hyper-Schema specifications, + respectively. + +
-
-
- - To differentiate between schemas in a vast ecosystem, schemas are - identified by URI, and can embed references - to other schemas by specifying their URI. - - -
- - RFC3986 Section 5.1 defines how to determine the - default base URI of a document. - - - Informatively, the initial base URI of a schema is the URI at which it was - found, whether that was a network location, a local filesystem, or any other - situation identifiable by a URI of any known scheme. - +
- If a schema document defines no explicit base URI with "$id" (embedded in content), - the base URI is that determined per - RFC 3986 section 5. + To differentiate between schemas in a vast ecosystem, schemas are + identified by URI, and can embed references + to other schemas by specifying their URI. - - If no source is known, or no URI scheme is known for the source, a suitable - implementation-specific default URI MAY be used as described in - RFC 3986 Section 5.1.4. It is RECOMMENDED - that implementations document any default base URI that they assume. - -
-
- - The "$id" keyword defines a URI for the schema, and the base URI that - other URI references within the schema are resolved against. - A subschema's "$id" is resolved against the base URI of its parent schema. - If no parent schema defines an explicit base URI with "$id", the base URI - is that of the entire document, as determined per - RFC 3986 section 5. - - - If present, the value for this keyword MUST be a string, and MUST represent a - valid URI-reference. - This value SHOULD be normalized, and SHOULD NOT be an empty fragment <#> - or an empty string <>. - -
+
- The root schema of a JSON Schema document SHOULD contain an "$id" keyword with - an absolute-URI (containing a scheme, but no fragment), - or this absolute URI but with an empty fragment. - + RFC3986 Section 5.1 defines how to determine the + default base URI of a document. -
-
- When an "$id" sets the base URI, the object containing that "$id" and all of - its subschemas can be identified by using a JSON Pointer fragment starting - from that location. This is true even of subschemas that further change the - base URI. Therefore, a single subschema may be accessible by multiple URIs, - each consisting of base URI declared in the subschema or a parent, along with - a JSON Pointer fragment identifying the path from the schema object that - declares the base to the subschema being identified. Examples of this are - shown in section . + Informatively, the initial base URI of a schema is the URI at which it was + found, whether that was a network location, a local filesystem, or any other + situation identifiable by a URI of any known scheme. -
-
- Using JSON Pointer fragments requires knowledge of the structure of the schema. - When writing schema documents with the intention to provide re-usable - schemas, it may be preferable to use a plain name fragment that is not tied to - any particular structural location. This allows a subschema to be relocated - without requiring JSON Pointer references to be updated. + If a schema document defines no explicit base URI with "$id" (embedded in content), + the base URI is that determined per + RFC 3986 section 5. - To specify such a subschema identifier, - the "$id" keyword is set to a URI reference with a plain name fragment (not a JSON Pointer fragment). - This value MUST begin with the number sign that specifies a fragment ("#"), - then a letter ([A-Za-z]), - followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), - colons (":"), or periods ("."). + If no source is known, or no URI scheme is known for the source, a suitable + implementation-specific default URI MAY be used as described in + RFC 3986 Section 5.1.4. It is RECOMMENDED + that implementations document any default base URI that they assume. +
+ +
- The effect of using a fragment in "$id" that isn't blank or doesn't follow the - plain name syntax is undefined. - - How should an "$id" URI reference containing a fragment with other components - be interpreted? There are two cases: when the other components match - the current base URI and when they change the base URI. - + The "$id" keyword defines a URI for the schema, and the base URI that + other URI references within the schema are resolved against. + A subschema's "$id" is resolved against the base URI of its parent schema. + If no parent schema defines an explicit base URI with "$id", the base URI + is that of the entire document, as determined per + RFC 3986 section 5. -
-
-
- - Consider the following schema, which shows "$id" being used to identify - the root schema, change the base URI for subschemas, and assign plain - name fragments to subschemas: - - + + If present, the value for this keyword MUST be a string, and MUST represent a + valid URI-reference. + This value SHOULD be normalized, and SHOULD NOT be an empty fragment <#> + or an empty string <>. + +
+ + The root schema of a JSON Schema document SHOULD contain an "$id" keyword with + an absolute-URI (containing a scheme, but no fragment), + or this absolute URI but with an empty fragment. + + +
+
+ + When an "$id" sets the base URI, the object containing that "$id" and all of + its subschemas can be identified by using a JSON Pointer fragment starting + from that location. This is true even of subschemas that further change the + base URI. Therefore, a single subschema may be accessible by multiple URIs, + each consisting of base URI declared in the subschema or a parent, along with + a JSON Pointer fragment identifying the path from the schema object that + declares the base to the subschema being identified. Examples of this are + shown in section . + +
+
+ + Using JSON Pointer fragments requires knowledge of the structure of the schema. + When writing schema documents with the intention to provide re-usable + schemas, it may be preferable to use a plain name fragment that is not tied to + any particular structural location. This allows a subschema to be relocated + without requiring JSON Pointer references to be updated. + + + To specify such a subschema identifier, + the "$id" keyword is set to a URI reference with a plain name fragment (not a JSON Pointer fragment). + This value MUST begin with the number sign that specifies a fragment ("#"), + then a letter ([A-Za-z]), + followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), + colons (":"), or periods ("."). + + + The effect of using a fragment in "$id" that isn't blank or doesn't follow the + plain name syntax is undefined. + + How should an "$id" URI reference containing a fragment with other components + be interpreted? There are two cases: when the other components match + the current base URI and when they change the base URI. + + +
+
+
+ + Consider the following schema, which shows "$id" being used to identify + the root schema, change the base URI for subschemas, and assign plain + name fragments to subschemas: + + - -
- - The schemas at the following URI-encoded JSON - Pointers (relative to the root schema) have the following - base URIs, and are identifiable by any listed URI in accordance with - Section above: - - - - - - https://example.com/root.json - https://example.com/root.json# - - - - - https://example.com/root.json#foo - https://example.com/root.json#/$defs/A - - - - - https://example.com/other.json - https://example.com/other.json# - https://example.com/root.json#/$defs/B - - - - - https://example.com/other.json#bar - https://example.com/other.json#/$defs/X - https://example.com/root.json#/$defs/B/$defs/X - - - - - https://example.com/t/inner.json - https://example.com/t/inner.json# - https://example.com/other.json#/$defs/Y - https://example.com/root.json#/$defs/B/$defs/Y - - - - - urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f - urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f# - https://example.com/root.json#/$defs/C - - - - + +
+ + The schemas at the following URI-encoded JSON + Pointers (relative to the root schema) have the following + base URIs, and are identifiable by any listed URI in accordance with + Section above: + + + + + + https://example.com/root.json + https://example.com/root.json# + + + + + https://example.com/root.json#foo + https://example.com/root.json#/$defs/A + + + + + https://example.com/other.json + https://example.com/other.json# + https://example.com/root.json#/$defs/B + + + + + https://example.com/other.json#bar + https://example.com/other.json#/$defs/X + https://example.com/root.json#/$defs/B/$defs/X + + + + + https://example.com/t/inner.json + https://example.com/t/inner.json# + https://example.com/other.json#/$defs/Y + https://example.com/root.json#/$defs/B/$defs/Y + + + + + urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f + urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f# + https://example.com/root.json#/$defs/C + + + + +
-
- -
- - Several keywords can be used to reference a schema which is to be applied to the - current instance location. "$ref" and "$recursiveRef" are applicator - keywords, applying the referenced schema to the instance. "$recursiveAnchor" - is a helper keyword that controls how the referenced schema of "$recursiveRef" - is determined. - - - As the value of "$ref" and "$recursiveRef" are URI References, this allows - the possibility to externalise or divide a schema across multiple files, - and provides the ability to validate recursive structures through - self-reference. - - - The resolved URI produced by these keywords is not necessarily a network - locator, only an identifier. A schema need not be downloadable from the - address if it is a network-addressable URL, and implementations SHOULD NOT - assume they should perform a network operation when they encounter - a network-addressable URI. - -
+
- The "$ref" keyword is used to reference a statically identified schema. + Several keywords can be used to reference a schema which is to be applied to the + current instance location. "$ref" and "$recursiveRef" are applicator + keywords, applying the referenced schema to the instance. "$recursiveAnchor" + is a helper keyword that controls how the referenced schema of "$recursiveRef" + is determined. - The value of the "$ref" property MUST be a string which is a URI Reference. - Resolved against the current URI base, it identifies the URI of a schema - to use. - -
- -
- - The "$recursiveRef" and "$recursiveAnchor" keywords are used to construct - extensible recursive schemas. A recursive schema is one that has - a reference to its own root, identified by the empty fragment - URI reference ("#"). + As the value of "$ref" and "$recursiveRef" are URI References, this allows + the possibility to externalise or divide a schema across multiple files, + and provides the ability to validate recursive structures through + self-reference. - Extending a recursive schema with "$ref" alone involves redefining all - recursive references in the source schema to point to the root of the - extension. This produces the correct recursive behavior in the extension, - which is that all recursion should reference the root of the extension. + The resolved URI produced by these keywords is not necessarily a network + locator, only an identifier. A schema need not be downloadable from the + address if it is a network-addressable URL, and implementations SHOULD NOT + assume they should perform a network operation when they encounter + a network-addressable URI. -
- - Consider the following two schemas. The first schema, identified - as "original" as it is the schema to be extended, describes - an object with one string property and one recursive reference - property, "r". The second schema, identified as "extension", - references the first, and describes an additional "things" property, - which is an array of recursive references. - It also repeats the description of "r" from the original schema. - - + +
+ + The "$ref" keyword is used to reference a statically identified schema. + + + The value of the "$ref" property MUST be a string which is a URI Reference. + Resolved against the current URI base, it identifies the URI of a schema + to use. + +
+ +
+ + The "$recursiveRef" and "$recursiveAnchor" keywords are used to construct + extensible recursive schemas. A recursive schema is one that has + a reference to its own root, identified by the empty fragment + URI reference ("#"). + + + Extending a recursive schema with "$ref" alone involves redefining all + recursive references in the source schema to point to the root of the + extension. This produces the correct recursive behavior in the extension, + which is that all recursion should reference the root of the extension. + +
+ + Consider the following two schemas. The first schema, identified + as "original" as it is the schema to be extended, describes + an object with one string property and one recursive reference + property, "r". The second schema, identified as "extension", + references the first, and describes an additional "things" property, + which is an array of recursive references. + It also repeats the description of "r" from the original schema. + + - - - This apparent duplication is important because - it resolves to "https://example.com/extension#", meaning that - for instance validated against the extension schema, the value - of "r" must be valid according to the extension, and not just the - original schema as "r" was described there. - -
- - This approach is fine for a single recursive field, but the more - complicated the original schema, the more redefinitions are necessary - in the extension. This leads to a verbose and error-prone extension, - which must be kept synchronized with the original schema if the - original changes its recursive fields. - This approach can be seen in the meta-schema for JSON Hyper-Schema - in all prior drafts. - -
- - The desired behavior is for the recursive reference, "r", in the - original schema to resolve to the original schema when that - is the only schema being used, but to resolve to the extension - schema when using the extension. Then there would be no need - to redefine the "r" property, or others like it, in the extension. - - - In order to create a recursive reference, we must do three things: - - - In our original schema, indicate that the schema author - intends for it to be extensible recursively. - - - In our extension schema, indicate that it is intended - to be a recursive extension. - - - Use a reference keyword that explicitly activates the - recursive behavior at the point of reference. - - - These three things together ensure that all schema authors - are intentionally constructing a recursive extension, which in - turn gives all uses of the regular "$ref" keyword confidence - that it only behaves as it appears to, using lexical scoping. - - - The "$recursiveAnchor" keyword is how schema authors indicate - that a schema can be extended recursively, and be a recursive - schema. This keyword MAY appear in the root schema of a - schema document, and MUST NOT appear in any subschema. - - - The value of "$recursiveAnchor" MUST be of type boolean, and - MUST be true. The value false is reserved for possible future use. - -
-
- - The "$recursiveRef" keyword behaves identically to "$ref", except - that if the referenced schema has "$recursiveAnchor" set to true, - then the implementation MUST examine the dynamic scope for the - outermost (first seen) schema document with "$recursiveAnchor" - set to true. If such a schema document exists, then the target - of the "$recursiveRef" MUST be set to that document's URI, in - place of the URI produced by the rules for "$ref". - + + + This apparent duplication is important because + it resolves to "https://example.com/extension#", meaning that + for instance validated against the extension schema, the value + of "r" must be valid according to the extension, and not just the + original schema as "r" was described there. + +
- Note that if the schema referenced by "$recursiveRef" does not - contain "$recursiveAnchor" set to true, or if there are no other - "$recursiveAnchor" keywords set to true anywhere further back in - the dynamic scope, then "$recursiveRef"'s behavior is identical - to that of "$ref". + This approach is fine for a single recursive field, but the more + complicated the original schema, the more redefinitions are necessary + in the extension. This leads to a verbose and error-prone extension, + which must be kept synchronized with the original schema if the + original changes its recursive fields. + This approach can be seen in the meta-schema for JSON Hyper-Schema + in all prior drafts. -
- - With this in mind, we can rewrite the previous example: - - +
+ + The desired behavior is for the recursive reference, "r", in the + original schema to resolve to the original schema when that + is the only schema being used, but to resolve to the extension + schema when using the extension. Then there would be no need + to redefine the "r" property, or others like it, in the extension. + + + In order to create a recursive reference, we must do three things: + + + In our original schema, indicate that the schema author + intends for it to be extensible recursively. + + + In our extension schema, indicate that it is intended + to be a recursive extension. + + + Use a reference keyword that explicitly activates the + recursive behavior at the point of reference. + + + These three things together ensure that all schema authors + are intentionally constructing a recursive extension, which in + turn gives all uses of the regular "$ref" keyword confidence + that it only behaves as it appears to, using lexical scoping. + + + The "$recursiveAnchor" keyword is how schema authors indicate + that a schema can be extended recursively, and be a recursive + schema. This keyword MAY appear in the root schema of a + schema document, and MUST NOT appear in any subschema. + + + The value of "$recursiveAnchor" MUST be of type boolean, and + MUST be true. The value false is reserved for possible future use. + +
+
+ + The "$recursiveRef" keyword behaves identically to "$ref", except + that if the referenced schema has "$recursiveAnchor" set to true, + then the implementation MUST examine the dynamic scope for the + outermost (first seen) schema document with "$recursiveAnchor" + set to true. If such a schema document exists, then the target + of the "$recursiveRef" MUST be set to that document's URI, in + place of the URI produced by the rules for "$ref". + + + Note that if the schema referenced by "$recursiveRef" does not + contain "$recursiveAnchor" set to true, or if there are no other + "$recursiveAnchor" keywords set to true anywhere further back in + the dynamic scope, then "$recursiveRef"'s behavior is identical + to that of "$ref". + +
+ + With this in mind, we can rewrite the previous example: + + - - - Note that the "r" property no longer appears in the - extension schema. Instead, all "$ref"s have been changed - to "$recursiveRef"s, and both schemas have "$recursiveAnchor" - set to true in their root schema. - -
+ + + Note that the "r" property no longer appears in the + extension schema. Instead, all "$ref"s have been changed + to "$recursiveRef"s, and both schemas have "$recursiveAnchor" + set to true in their root schema. + +
+ + When using the original schema on its own, there is no change + in behavior. The "$recursiveRef" does lead to a schema where + "$recursiveAnchor" is set to true, but since the original schema + is the only schema document in the dynamics scope (it references + itself, and does not reference any other schema documents), the + behavior is effectively the same as "$ref". + + + When using the extension schema, the "$recursiveRef" within + that schema (for the array items within "things") also effectively + behaves like "$ref". The extension schema is the outermost + dynamic scope, so the reference target is not changed. + + + In contrast, when using the extension schema, the "$recursiveRef" + for "r" in the original schema now behaves differently. Its + initial target is the root schema of the original schema document, + which has "$recursiveAnchor" set to true. In this case, the + outermost dynamic scope that also has "$recursiveAnchor" set to + true is the extension schema. So when using the extensions schema, + "r"'s reference in the original schema will resolve to + "https://example.com/extension#", not "https://example.com/original#". + +
+
+ +
- When using the original schema on its own, there is no change - in behavior. The "$recursiveRef" does lead to a schema where - "$recursiveAnchor" is set to true, but since the original schema - is the only schema document in the dynamics scope (it references - itself, and does not reference any other schema documents), the - behavior is effectively the same as "$ref". + A schema MUST NOT be run into an infinite loop against an instance. For + example, if two schemas "#alice" and "#bob" both have an "allOf" property + that refers to the other, a naive validator might get stuck in an infinite + recursive loop trying to validate the instance. Schemas SHOULD NOT make + use of infinite recursive nesting like this; the behavior is undefined. + +
+ +
+ + Subschema objects (or booleans) are recognized by their use with known + applicator keywords. These keywords may be the standard applicators + from this document, or extension keywords from a known vocabulary, or + implementation-specific custom keywords. + + + Multi-level structures of unknown keywords are capable of introducing + nested subschemas, which would be subject to the processing rules for + "$id". Therefore, having a reference target in such an unrecognized + structure cannot be reliably implemented, and the resulting behavior + is undefined. Similarly, a reference target under a known keyword, + for which the value is known not to be a schema, results in undefined + behavior in order to avoid burdening implementations with the need + to detect such targets. + + These scenarios are analogous to fetching a schema over HTTP + but receiving a response with a Content-Type other than + application/schema+json. An implementation can certainly + try to interpret it as a schema, but the origin server + offered no guarantee that it actually is any such thing. + Therefore, interpreting it as such has security implications + and may produce unpredictable results. + + + + Note that single-level custom keywords with identical syntax and + semantics to "$defs" do not allow for any intervening "$id" keywords, + and therefore will behave correctly under implementations that attempt + to use any reference target as a schema. However, this behavior is + implementation-specific and MUST NOT be relied upon for interoperability. + +
+ +
+ + The use of URIs to identify remote schemas does not necessarily mean anything is downloaded, + but instead JSON Schema implementations SHOULD understand ahead of time which schemas they will be using, + and the URIs that identify them. - When using the extension schema, the "$recursiveRef" within - that schema (for the array items within "things") also effectively - behaves like "$ref". The extension schema is the outermost - dynamic scope, so the reference target is not changed. + When schemas are downloaded, + for example by a generic user-agent that doesn't know until runtime which schemas to download, + see Usage for Hypermedia. - In contrast, when using the extension schema, the "$recursiveRef" - for "r" in the original schema now behaves differently. Its - initial target is the root schema of the original schema document, - which has "$recursiveAnchor" set to true. In this case, the - outermost dynamic scope that also has "$recursiveAnchor" set to - true is the extension schema. So when using the extensions schema, - "r"'s reference in the original schema will resolve to - "https://example.com/extension#", not "https://example.com/original#". + Implementations SHOULD be able to associate arbitrary URIs with an arbitrary + schema and/or automatically associate a schema's "$id"-given URI, depending + on the trust that the validator has in the schema. Such URIs and schemas + can be supplied to an implementation prior to processing instances, or may + be noted within a schema document as it is processed, producing associations + as shown in section . + + + A schema MAY (and likely will) have multiple URIs, but there is no way for a + URI to identify more than one schema. When multiple schemas try to identify + as the same URI, validators SHOULD raise an error condition.
-
- -
- - A schema MUST NOT be run into an infinite loop against an instance. For - example, if two schemas "#alice" and "#bob" both have an "allOf" property - that refers to the other, a naive validator might get stuck in an infinite - recursive loop trying to validate the instance. Schemas SHOULD NOT make - use of infinite recursive nesting like this; the behavior is undefined. - -
- -
- - Subschema objects (or booleans) are recognized by their use with known - applicator keywords. These keywords may be the standard applicators - from this document, or extension keywords from a known vocabulary, or - implementation-specific custom keywords. - - - Multi-level structures of unknown keywords are capable of introducing - nested subschemas, which would be subject to the processing rules for - "$id". Therefore, having a reference target in such an unrecognized - structure cannot be reliably implemented, and the resulting behavior - is undefined. Similarly, a reference target under a known keyword, - for which the value is known not to be a schema, results in undefined - behavior in order to avoid burdening implementations with the need - to detect such targets. - - These scenarios are analogous to fetching a schema over HTTP - but receiving a response with a Content-Type other than - application/schema+json. An implementation can certainly - try to interpret it as a schema, but the origin server - offered no guarantee that it actually is any such thing. - Therefore, interpreting it as such has security implications - and may produce unpredictable results. - - - - Note that single-level custom keywords with identical syntax and - semantics to "$defs" do not allow for any intervening "$id" keywords, - and therefore will behave correctly under implementations that attempt - to use any reference target as a schema. However, this behavior is - implementation-specific and MUST NOT be relied upon for interoperability. - -
- -
- - The use of URIs to identify remote schemas does not necessarily mean anything is downloaded, - but instead JSON Schema implementations SHOULD understand ahead of time which schemas they will be using, - and the URIs that identify them. - - - When schemas are downloaded, - for example by a generic user-agent that doesn't know until runtime which schemas to download, - see Usage for Hypermedia. - - - Implementations SHOULD be able to associate arbitrary URIs with an arbitrary - schema and/or automatically associate a schema's "$id"-given URI, depending - on the trust that the validator has in the schema. Such URIs and schemas - can be supplied to an implementation prior to processing instances, or may - be noted within a schema document as it is processed, producing associations - as shown in section . - - - A schema MAY (and likely will) have multiple URIs, but there is no way for a - URI to identify more than one schema. When multiple schemas try to identify - as the same URI, validators SHOULD raise an error condition. - -
-
- - Schemas can be identified by any URI that has been given to them, including - a JSON Pointer or their URI given directly by "$id". In all cases, - dereferencing a "$ref" reference involves first resolving its value as a - URI reference against the current base URI per - RFC 3986. - - - If the resulting URI identifies a schema within the current document, or - within another schema document that has been made available to the implementation, - then that schema SHOULD be used automatically. - - - For example, consider this schema: - +
+ + Schemas can be identified by any URI that has been given to them, including + a JSON Pointer or their URI given directly by "$id". In all cases, + dereferencing a "$ref" reference involves first resolving its value as a + URI reference against the current base URI per + RFC 3986. + + + If the resulting URI identifies a schema within the current document, or + within another schema document that has been made available to the implementation, + then that schema SHOULD be used automatically. + + + For example, consider this schema: + -
- +
+ - -
+ +
+ + When an implementation encounters the <#/$defs/single> schema, + it resolves the "$id" URI reference against the current base URI to form + <https://example.net/root.json#item>. + + + When an implementation then looks inside the <#/items> schema, it + encounters the <#item> reference, and resolves this to + <https://example.net/root.json#item>, which it has seen defined in + this same document and can therefore use automatically. + + + When an implementation encounters the reference to "other.json", it resolves + this to <https://example.net/other.json>, which is not defined in this + document. If a schema with that identifier has otherwise been supplied to + the implementation, it can also be used automatically. + + What should implementations do when the referenced schema is not known? + Are there circumstances in which automatic network dereferencing is + allowed? A same origin policy? A user-configurable option? In the + case of an evolving API described by Hyper-Schema, it is expected that + new schemas will be added to the system dynamically, so placing an + absolute requirement of pre-loading schema documents is not feasible. + + +
+
+ +
- When an implementation encounters the <#/$defs/single> schema, - it resolves the "$id" URI reference against the current base URI to form - <https://example.net/root.json#item>. + The "$defs" keyword provides a standardized location for schema + authors to inline re-usable JSON Schemas into a more general schema. + The keyword does not directly affect the validation result. - When an implementation then looks inside the <#/items> schema, it - encounters the <#item> reference, and resolves this to - <https://example.net/root.json#item>, which it has seen defined in - this same document and can therefore use automatically. + This keyword's value MUST be an object. + Each member value of this object MUST be a valid JSON Schema. - When an implementation encounters the reference to "other.json", it resolves - this to <https://example.net/other.json>, which is not defined in this - document. If a schema with that identifier has otherwise been supplied to - the implementation, it can also be used automatically. - - What should implementations do when the referenced schema is not known? - Are there circumstances in which automatic network dereferencing is - allowed? A same origin policy? A user-configurable option? In the - case of an evolving API described by Hyper-Schema, it is expected that - new schemas will be added to the system dynamically, so placing an - absolute requirement of pre-loading schema documents is not feasible. - - -
-
+ As an example, here is a schema describing an array of positive + integers, where the positive integer constraint is a subschema in + "$defs": -
- - The "$defs" keyword provides a standardized location for schema - authors to inline re-usable JSON Schemas into a more general schema. - The keyword does not directly affect the validation result. - - - This keyword's value MUST be an object. - Each member value of this object MUST be a valid JSON Schema. - - - As an example, here is a schema describing an array of positive - integers, where the positive integer constraint is a subschema in - "$defs": - -
- +
+ - -
- + +
+ +
-
-
- - This keyword is reserved for comments from schema authors to readers or - maintainers of the schema. - - The value of this keyword MUST be a string. Implementations MUST NOT present this - string to end users. Tools for editing schemas SHOULD support displaying and - editing this keyword. The value of this keyword MAY be used in debug or error - output which is intended for developers making use of schemas. - - Schema vocabularies SHOULD allow "$comment" within any object containing - vocabulary keywords. Implementations MAY assume "$comment" is allowed - unless the vocabulary specifically forbids it. Vocabularies MUST NOT - specify any effect of "$comment" beyond what is described in this - specification. - - Tools that translate other media types or programming languages - to and from application/schema+json MAY choose to convert that media type or - programming language's native comments to or from "$comment" values. - The behavior of such translation when both native comments and "$comment" - properties are present is implementation-dependent. - - Implementations SHOULD treat "$comment" identically to an unknown extension - keyword. They MAY strip "$comment" values at any point during processing. - In particular, this allows for shortening schemas when the size of deployed - schemas is a concern. - - Implementations MUST NOT take any other action based on the presence, absence, - or contents of "$comment" properties. In particular, the value of "$comment" - MUST NOT be collected as an annotation result. - +
+ + This keyword is reserved for comments from schema authors to readers or + maintainers of the schema. + + The value of this keyword MUST be a string. Implementations MUST NOT present this + string to end users. Tools for editing schemas SHOULD support displaying and + editing this keyword. The value of this keyword MAY be used in debug or error + output which is intended for developers making use of schemas. + + Schema vocabularies SHOULD allow "$comment" within any object containing + vocabulary keywords. Implementations MAY assume "$comment" is allowed + unless the vocabulary specifically forbids it. Vocabularies MUST NOT + specify any effect of "$comment" beyond what is described in this + specification. + + Tools that translate other media types or programming languages + to and from application/schema+json MAY choose to convert that media type or + programming language's native comments to or from "$comment" values. + The behavior of such translation when both native comments and "$comment" + properties are present is implementation-dependent. + + Implementations SHOULD treat "$comment" identically to an unknown extension + keyword. They MAY strip "$comment" values at any point during processing. + In particular, this allows for shortening schemas when the size of deployed + schemas is a concern. + + Implementations MUST NOT take any other action based on the presence, absence, + or contents of "$comment" properties. In particular, the value of "$comment" + MUST NOT be collected as an annotation result. + +
From fc4665caa105480be2f460e882687266daedafdd Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 9 Aug 2019 15:35:19 -0700 Subject: [PATCH 052/780] Rework core vocab text for new section layout. A few minor clarifications are added, including a RECOMMENDATION against using "$" as the first character of extension keywords. The paragraph about bug-fix meta-schema and vocabulary URIs seemed out of place, and worth calling out more clearly, so it became its own section. --- jsonschema-core.xml | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e97c6494..651c8ba1 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1007,7 +1007,7 @@
- Keywords declared in in this specification that begin with "$" make up + Keywords declared in in this section, which all begin with "$", make up the JSON Schema Core vocabulary. These keywords are either required in order process any schema or meta-schema, including those split across multiple documents, or exist to reserve keywords for purposes that @@ -1016,7 +1016,8 @@ The Core vocabulary MUST be considered mandatory at all times, in order to bootstrap the processing of further vocabularies. Meta-schemas - that use "$vocabulary" MUST explicitly list the Core vocabulary, + that use the "$vocabulary" keyword + to declare the vocabularies in use MUST explicitly list the Core vocabulary, which MUST have a value of true indicating that it is required. @@ -1024,7 +1025,8 @@ vocabulary) is undefined, as is the behavior when "$vocabulary" is present but the Core vocabulary is not included. However, it is RECOMMENDED that implementations detect these cases and raise - an error when they occur. + an error when they occur. It is not meaningful to declare that + a meta-schema optionally uses Core. Meta-schemas that do not use "$vocabulary" MUST be considered to @@ -1039,11 +1041,9 @@ . - Updated vocabulary and meta-schema URIs MAY be published between - specification drafts in order to correct errors. Implementations - SHOULD consider URIs dated after this specification draft and - before the next to indicate the same syntax and semantics - as those listed here. + While the "$" prefix is not formally reserved for the Core vocabulary, + it is RECOMMENDED that extension keywords (in vocabularies or otherwise) + begin with a character other than "$" to avoid possible future collisions.
@@ -1211,6 +1211,15 @@
+
+ + Updated vocabulary and meta-schema URIs MAY be published between + specification drafts in order to correct errors. Implementations + SHOULD consider URIs dated after this specification draft and + before the next to indicate the same syntax and semantics + as those listed here. + +
Implementations MUST recognize a schema as a meta-schema if it From ba61045b890db7595e5692a30b580a70513243eb Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 17 Aug 2019 14:03:54 -0700 Subject: [PATCH 053/780] Vocab explanation improvements from gregsdennis Two improvements extracted from an older PR by Greg: * better wording around "forthcoming drafts" (kept verbatim) * clarification around keywords from unknown vocabularies (loosely inspired by Greg's wording). --- jsonschema-core.xml | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 651c8ba1..6a4388f9 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -531,7 +531,7 @@
-
+
Additional schema keywords and schema vocabularies MAY be defined by any entity. Save for explicit agreement, schema authors SHALL NOT @@ -1145,7 +1145,7 @@ MAY use the URL of the vocabulary specification, in a human-readable media type such as text/html or text/plain, as the vocabulary URI. - Vocabulary documents may be added shortly, or in the next draft. + Vocabulary documents may be added in forthcoming drafts. For now, identifying the keyword set is deemed sufficient as that, along with meta-schema validation, is how the current "vocabularies" work today. Any future vocabulary document format will be specified @@ -1158,13 +1158,15 @@ 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 MAY choose to proceed with processing + that do not recognize the vocabulary SHOULD proceed with processing such schemas. - When processing a schema that uses unrecognized vocabularies, keywords - declared by those vocabularies are treated like any other unrecognized - keyword, and ignored. + Per , unrecognized + keywords SHOULD be ignored. This remains the case for keywords defined + by unrecognized vocabularies. It is not currently possible to distinguish + between unrecognized keywords that are defined in vocabularies from + those that are not part of any vocabulary. The "$vocabulary" keyword SHOULD be used in the root schema of any schema From 61a77479ab703c284de6ca05dd7963c7b00c215d Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 17 Aug 2019 16:31:26 -0700 Subject: [PATCH 054/780] Improve vocab example per gregsdennis suggestions This incorporates most of the ideas from an earlier PR by gregsdennis, updated and enhanced by some clarifications and enhancments that were made after that PR was originally written. The example now follows the best practices from the previous section by showing separate general purpose and single-vocabulary meta-schemas, and discusses how they are used together. --- jsonschema-core.xml | 112 ++++++++++++++++++++++++++++++++++---------- 1 file changed, 86 insertions(+), 26 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 651c8ba1..be29f48d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1208,6 +1208,15 @@ must be repeated in the root of each schema document intended for use as a meta-schema. This is demonstrated in the example meta-schema. + + This requirement allows implementations to find all vocabulary + requirement information in a single place for each meta-schema. + As schema extensibility means that there are endless potential + ways to combine more fine-grained meta-schemas by reference, + requiring implementations to anticipate all possibilities and + search for vocabularies in referenced meta-schemas would + be overly burdensome. +
@@ -1308,53 +1317,93 @@
+ + This meta-schema explicitly declares both the Core and Applicator vocabularies, + together with an extension vocabulary, and combines their meta-schemas with + an "allOf". The extension vocabulary's meta-schema, which describes only the + keywords in that vocabulary, is shown after the main example meta-schema. + + + The main example meta-schema also restricts the usage of the Applicator + vocabulary by forbidding the keywords prefixed with "unevaluated", which + are particularly complex to implement. This does not change the semantics + or set of keywords defined by the Applicator vocabulary. It just ensures + that schemas using this meta-schema that attempt to use the keywords + prefixed with "unevaluted" will fail validation against this meta-schema. + + + Finally, this meta-schema describes the syntax of a keyword, "localKeyword", + that is not part of any vocabulary. Presumably, the implementors and users + of this meta-schema will understand the semantics of "localKeyword". + JSON Schema does not define any mechanism for expressing keyword semantics + outside of vocabularies, making them unsuitable for use except in a + specific environment in which they are understood. +
- This meta-schema explicitly declares both the Core and Applicator - vocabularies, and combines their meta-schemas with an "allOf". - It additionally restricts the usage of the Applicator vocabulary - by forbidding the keyword prefixed with "unevaluated". It also - describes a keyword, "localKeyword", that is not part of either - vocabulary. Note that it is its own meta-schema, - as it relies on both the Core vocabulary (as all schemas do) - and the Applicator vocabulary (for "allOf"). + This meta-schema combines several vocabularies for general use. - - As shown above, even though each of the referenced standard - meta-schemas declares its corresponding vocabulary, this new - meta-schema must re-declare them for itself. It would be - valid to leave the core vocabulary out of the "$vocabulary" keyword, - but it needs to be referenced through the "allOf" keyword in order - for its terms to be validated. There is no special case for - validation of core keywords. - +
+
+ + This meta-schema describes only a single extension vocabulary. + + + +
+ + As shown above, even though each of the single-vocabulary meta-schemas + referenced in the general-use meta-schema's "allOf" declares its + corresponding vocabulary, this new meta-schema must re-declare them. + The standard meta-schemas that combine all vocabularies defined by the Core and Validation specification, and that combine all vocabularies @@ -1363,6 +1412,17 @@ meta-schemas may be found in the Validation and Hyper-Schema specifications, respectively. + + While the general-use meta-schema can validate the syntax of "minDate", + it is the vocabulary that defines the logic behind the semantic meaning + of "minDate". Without an understanding of the semantics (in this example, + that the instance value must be a date equal to or after the date + provided as the keyword's value in the schema), an implementation can + only validate the syntactic usage. In this case, that means validating + that it is a date-formatted string (using "pattern" to ensure that it is + validated even when "format" functions purely as an annotation, as explained + in the Validation specification. +
@@ -1598,7 +1658,7 @@ Date: Mon, 19 Aug 2019 14:32:33 +0200 Subject: [PATCH 055/780] attempt at clarification --- jsonschema-validation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index e5bf9deb..031de5fb 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1050,7 +1050,7 @@ When the "deprecated" keyword is applicable to an array, it's meaning will vary depending on how "items" is used. If "items" is a single schema, it will deprecate the contents of an array, but if "items" is an array of schemas it - can be used to deprecate positional schemas. + should be defined in the sub-schema targetted for deprecation. Omitting this keyword has the same behavior as a value of false. From 646f2a34caeaea860be076911089c1f50072dbdd Mon Sep 17 00:00:00 2001 From: garethsb-sony Date: Mon, 19 Aug 2019 13:59:22 +0100 Subject: [PATCH 056/780] Fix verbose example to match 5b088711e78d472905ed37481d5ca055f370ba05 and resolve #752. --- output/verbose-example.json | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/output/verbose-example.json b/output/verbose-example.json index 161b5855..37acb2d5 100644 --- a/output/verbose-example.json +++ b/output/verbose-example.json @@ -5,7 +5,7 @@ "errors": [ { "valid": true, - "keywordLocation": "#/definitions", + "keywordLocation": "#/$defs", "instanceLocation": "#" }, { @@ -29,35 +29,35 @@ "valid": true, "keywordLocation": "#/items/$ref", "absoluteKeywordLocation": - "https://example.com/polygon#/definitions/point", + "https://example.com/polygon#/$defs/point", "instanceLocation": "#/0", "annotations": [ { "valid": true, "keywordLocation": "#/items/$ref/type", "absoluteKeywordLocation": - "https://example.com/polygon#/definitions/point/type", + "https://example.com/polygon#/$defs/point/type", "instanceLocation": "#/0" }, { "valid": true, "keywordLocation": "#/items/$ref/properties", "absoluteKeywordLocation": - "https://example.com/polygon#/definitions/point/properties", + "https://example.com/polygon#/$defs/point/properties", "instanceLocation": "#/0" }, { "valid": true, "keywordLocation": "#/items/$ref/required", "absoluteKeywordLocation": - "https://example.com/polygon#/definitions/point/required", + "https://example.com/polygon#/$defs/point/required", "instanceLocation": "#/0" }, { "valid": true, "keywordLocation": "#/items/$ref/additionalProperties", "absoluteKeywordLocation": - "https://example.com/polygon#/definitions/point/additionalProperties", + "https://example.com/polygon#/$defs/point/additionalProperties", "instanceLocation": "#/0" } ] @@ -75,42 +75,42 @@ "valid": false, "keywordLocation": "#/items/$ref", "absoluteKeywordLocation": - "https://example.com/polygon#/definitions/point", + "https://example.com/polygon#/$defs/point", "instanceLocation": "#/1", "errors": [ { "valid": true, "keywordLocation": "#/items/$ref/type", "absoluteKeywordLocation": - "https://example.com/polygon#/definitions/point/type", + "https://example.com/polygon#/$defs/point/type", "instanceLocation": "#/1" }, { "valid": true, "keywordLocation": "#/items/$ref/properties", "absoluteKeywordLocation": - "https://example.com/polygon#/definitions/point/properties", + "https://example.com/polygon#/$defs/point/properties", "instanceLocation": "#/1" }, { "valid": false, "keywordLocation": "#/items/$ref/required", "absoluteKeywordLocation": - "https://example.com/polygon#/definitions/point/required", + "https://example.com/polygon#/$defs/point/required", "instanceLocation": "#/1" }, { "valid": false, "keywordLocation": "#/items/$ref/additionalProperties", "absoluteKeywordLocation": - "https://example.com/polygon#/definitions/point/additionalProperties", + "https://example.com/polygon#/$defs/point/additionalProperties", "instanceLocation": "#/1", "errors": [ { "valid": false, "keywordLocation": "#/items/$ref/additionalProperties", "absoluteKeywordLocation": - "https://example.com/polygon#/definitions/point/additionalProperties", + "https://example.com/polygon#/$defs/point/additionalProperties", "instanceLocation": "#/1/z" } ] From 55d9467e363dd67e1e0b717de104ab667f427822 Mon Sep 17 00:00:00 2001 From: Phil Sturgeon Date: Mon, 19 Aug 2019 17:59:16 +0200 Subject: [PATCH 057/780] nailed it this time --- jsonschema-validation.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 031de5fb..c964b55b 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1047,10 +1047,10 @@ the entire resource being described MAY be removed in the future. - When the "deprecated" keyword is applicable to an array, it's meaning will - vary depending on how "items" is used. If "items" is a single schema, it will - deprecate the contents of an array, but if "items" is an array of schemas it - should be defined in the sub-schema targetted for deprecation. + When the deprecated keyword is applied to an item in an array by means of + items, if items is a single schema, the deprecation relates to the whole + array, while if items is an array of schemas, the deprecation relates to + the corrosponding item according to the subschemas position. Omitting this keyword has the same behavior as a value of false. From fbfb8520ffa6d1c8bea0bbb106361e3b4fce740a Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 20 Aug 2019 14:51:15 -0700 Subject: [PATCH 058/780] Less confusing name for example ...and fix inconsistency in the example name. Oops. --- jsonschema-core.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index be29f48d..0ceb2e0a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1353,13 +1353,13 @@ "https://json-schema.org/draft/2019-08/vocab/core": true, "https://json-schema.org/draft/2019-08/vocab/applicator": true, "https://json-schema.org/draft/2019-08/vocab/validation": true, - "https://example.com/vocab/core-app-example": true + "https://example.com/vocab/example-vocab": true }, "allOf": [ {"$ref": "https://json-schema.org/draft/2019-08/meta/core"}, {"$ref": "https://json-schema.org/draft/2019-08/meta/applicator"}, {"$ref": "https://json-schema.org/draft/2019-08/meta/validation"}, - {"$ref": "https://example.com/meta/core-app-example-vocab", + {"$ref": "https://example.com/meta/example-vocab", ], "patternProperties": { "^unevaluated.*$": false @@ -1382,10 +1382,10 @@ Date: Sat, 17 Aug 2019 17:04:54 -0700 Subject: [PATCH 059/780] Clarify the nature of schema placeholder keywords Acknowledge that "$defs" and placeholders like it also indicate that their values are schemas, which is relevant to whether they can be detected as a proper "$ref" target or place where "$id" may appear. This ensures that similar extension keywords are understood to have the same concerns as extension applicator keywords. --- jsonschema-core.xml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 9c53b2d9..3044e1b5 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1851,7 +1851,9 @@
Subschema objects (or booleans) are recognized by their use with known - applicator keywords. These keywords may be the standard applicators + applicator keywords, or with placeholder keywords such as + "$defs" that take one or more subschemas + as a value. These keywords may be "$defs" and the standard applicators from this document, or extension keywords from a known vocabulary, or implementation-specific custom keywords. @@ -1973,7 +1975,7 @@
-
+
The "$defs" keyword provides a standardized location for schema authors to inline re-usable JSON Schemas into a more general schema. From d4f897b72fe63e760bd8565d5006af5702d966eb Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Mon, 19 Aug 2019 21:19:24 -0700 Subject: [PATCH 060/780] Further clarification of $defs/definitions Introduce the category of reserved location keywords, which are basically just $defs and $comment. This should make it more clear that you can create keywords of your own like this, and fits them more nicely into the overall keyword taxonomy. Part of this change refers to the typical core+validation meta-schema as the "default meta-schema", which is a change made in another PR. --- jsonschema-core.xml | 32 ++++++++++++++++++++++++++------ jsonschema-validation.xml | 9 +++++++-- 2 files changed, 33 insertions(+), 8 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 3044e1b5..ef24d479 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -307,7 +307,7 @@ Object properties that are applied to the instance are called keywords, or schema keywords. Broadly speaking, keywords fall into one - of three categories: + of four categories: produce a boolean result when applied to an instance @@ -319,6 +319,10 @@ apply one or more subschemas to a particular location in the instance, and combine or modify their results + + do not directly affect results, but reserve a place + for a specific purpose to ensure interoperability + @@ -1004,6 +1008,22 @@
+
+ + A fourth category of keywords simply reserve a location to hold re-usable + components or data of interest to schema authors that is not suitable + for re-use. These keywords do not affect validation or annotation results. + Their purpose in the core vocabulary is to ensure that locations are + available for certain purposes and will not be redefined by extension + keywords. + + + While these keywords do not directly affect results, as explained in section + unrecognized + extension keywords that reserve locations for re-usable schemas may have + undesirable interactions with references in certain circumstances. + +
@@ -1848,10 +1868,10 @@
-
+
Subschema objects (or booleans) are recognized by their use with known - applicator keywords, or with placeholder keywords such as + applicator keywords or with placeholder keywords such as "$defs" that take one or more subschemas as a value. These keywords may be "$defs" and the standard applicators from this document, or extension keywords from a known vocabulary, or @@ -1977,7 +1997,7 @@
- The "$defs" keyword provides a standardized location for schema + The "$defs" keyword reserves a location for schema authors to inline re-usable JSON Schemas into a more general schema. The keyword does not directly affect the validation result. @@ -2012,8 +2032,8 @@
- This keyword is reserved for comments from schema authors to readers or - maintainers of the schema. + This keyword is reserved a location for comments from schema authors + to readers or maintainers of the schema. The value of this keyword MUST be a string. Implementations MUST NOT present this string to end users. Tools for editing schemas SHOULD support displaying and diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 48babe35..f0881992 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -179,7 +179,8 @@ The current URI for the JSON Schema Validation meta-schema is . For schema author convenience, this meta-schema describes all vocabularies - defined in this specification and the JSON Schema Core specification. + defined in this specification and the JSON Schema Core specification, + as well as two former keywords which are reserved for a transitional period. Individual vocabulary and vocabulary meta-schema URIs are given for each section below. Certain vocabularies are optional to support, which is explained in detail in the relevant sections. @@ -1352,7 +1353,11 @@ Renamed to "$defs" to match "$ref" and be shorter to type. Schema vocabulary authors SHOULD NOT define a "definitions" keyword with different behavior in order to avoid invalidating schemas that - still use the older name. + still use the older name. While "definitions" is absent in the + single-vocabulary meta-schemas referenced by this document, it + remains present in the default meta-schema, and implementations + SHOULD assume that "$defs" and "definitions" have the same + behavior when that meta-schema is used. - This keyword is reserved a location for comments from schema authors + This keyword reserves a location for comments from schema authors to readers or maintainers of the schema. The value of this keyword MUST be a string. Implementations MUST NOT present this From eeec848e0a8a81db3733003e58cbf81c5dc4563a Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 15 Aug 2019 17:51:07 -0700 Subject: [PATCH 062/780] Introduce "schema resource" and canonical URIs This lets us talk more clearly about what an "$id" really is, as will be seen in the next commit. It also introduces the idea of a schema resource having a canonical URI, which is important for explaining why JSON Pointer fragments relative to parent base URIs (meaning that they "cross" a subschema "$id") should have undefined behavior. --- jsonschema-core.xml | 29 ++++++++++++++++++++++++----- 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 2d91ffe6..c28e2bb4 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2,6 +2,7 @@ + @@ -402,10 +403,22 @@ additional keywords that are not part of a formal vocabulary.
-
+
+ + A JSON Schema resource is a schema which is + canonically identified by an + absolute URI. + + + As discussed in section + , a JSON Schema document + can contain multiple JSON Schema resources. + The root schema is the schema that comprises the entire JSON document - in question. + in question. The root schema is always a schema resource, where the + URI is determined as described in section + . Some keywords take schemas themselves, allowing JSON Schemas to be nested: @@ -1455,7 +1468,7 @@ to other schemas by specifying their URI. -
+
RFC3986 Section 5.1 defines how to determine the default base URI of a document. @@ -1466,8 +1479,8 @@ situation identifiable by a URI of any known scheme. - If a schema document defines no explicit base URI with "$id" (embedded in content), - the base URI is that determined per + If a schema document defines no explicit base URI with "$id" + (embedded in content), the base URI is that determined per RFC 3986 section 5. @@ -1476,6 +1489,11 @@ RFC 3986 Section 5.1.4. It is RECOMMENDED that implementations document any default base URI that they assume. + + Unless the "$id" keyword described in the next section is present in the + root schema, this base URI SHOULD be considered the canonical URI of the + schema document's root schema resource. +
@@ -3349,6 +3367,7 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0 + &RFC6596; &RFC7049; &RFC7231; &RFC8288; From a93b605d2f5d72b0de824081567e435782c32ce2 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 15 Aug 2019 18:10:52 -0700 Subject: [PATCH 063/780] Canonical URIs and avoiding shadowed JSON Pointers This implements the recent decision to strongly discourage using fragments that cross a base URI change (e.g. an "$id" appearance). This is done by describing schemas identified by absolute URIs as resources (per the literal definition of Univeral Resource Identifier), which was done in the previous commit, and declaring the URI resulting from the "$id" to be the resource's canonical URI. While URIs for subschemas with "$id" and their chidren can be constructed using the base URI from a parent schema, these URIs are non-canonical, and their behavior is undefined. This is on the grounds that switching between embedding and referencing schema resources should behave essentially identically. A difficulty with how annotation collection works in the event of such as switch is noted in a CREF. --- jsonschema-core.xml | 115 +++++++++++++++++++++++++++----------------- 1 file changed, 72 insertions(+), 43 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index c28e2bb4..f8e4e562 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1467,6 +1467,11 @@ identified by URI, and can embed references to other schemas by specifying their URI. + + Several keywords can accept a relative URI-reference, + or a value used to construct a relative URI-reference. For these keywords, + it is necessary to establish a base URI in order to resolve the reference. +
@@ -1498,63 +1503,87 @@
- The "$id" keyword defines a URI for the schema, and the base URI that - other URI references within the schema are resolved against. - A subschema's "$id" is resolved against the base URI of its parent schema. - If no parent schema defines an explicit base URI with "$id", the base URI - is that of the entire document, as determined per - RFC 3986 section 5. + The "$id" keyword identifies a schema resource with its + canonical URI. + + + Note that this URI is an identifier and not necessarily a network locator. + In the case of a network-addressable URL, a schema need not be downloadable + from its canonical URI. If present, the value for this keyword MUST be a string, and MUST represent a - valid URI-reference. - This value SHOULD be normalized, and SHOULD NOT be an empty fragment <#> - or an empty string <>. + valid URI-reference. This URI-reference + SHOULD be normalized, and MUST resolve to an + absolute-URI (without a fragment). + + + This URI also serves as the base URI for relative URI-references in keywords + within the schema resource, in accordance with + RFC 3986 section 5.1.1 regarding base URIs + embedded in content. + + + The presence of "$id" in a subschema indicates that the subschema constitutes + a distinct schema resource within a single schema document. Furthermore, + in accordance with RFC 3986 section 5.1.2 + regarding encapsulating entities, if an "$id" in a subschema is a relative + URI-reference, the base URI for resolving that reference is the URI of + the parent schema resource. + + + If no parent schema object explicitly identifies itself as a resource + with "$id", the base URI is that of the entire document, as established + by the steps given in the previous section.
- The root schema of a JSON Schema document SHOULD contain an "$id" keyword with - an absolute-URI (containing a scheme, but no fragment), - or this absolute URI but with an empty fragment. - + The root schema of a JSON Schema document SHOULD contain an "$id" keyword + with an absolute-URI (containing a scheme, + but no fragment).
-
+
- When an "$id" sets the base URI, the object containing that "$id" and all of - its subschemas can be identified by using a JSON Pointer fragment starting - from that location. This is true even of subschemas that further change the - base URI. Therefore, a single subschema may be accessible by multiple URIs, - each consisting of base URI declared in the subschema or a parent, along with - a JSON Pointer fragment identifying the path from the schema object that - declares the base to the subschema being identified. Examples of this are - shown in section . + Since JSON Pointer URI fragments are constructed based on the structure + of the schema document, an embedded schema resource and its subschemas + can be identified by JSON Pointer fragments relative to either its own + canonical URI, or relative to the containing resource's URI. -
-
- Using JSON Pointer fragments requires knowledge of the structure of the schema. - When writing schema documents with the intention to provide re-usable - schemas, it may be preferable to use a plain name fragment that is not tied to - any particular structural location. This allows a subschema to be relocated - without requiring JSON Pointer references to be updated. + Conceptually, a set of linked schemas should behave identically whether + each schema is a separate document connected with + schema references, or is structured as + a single document with one or more schema resources embedded as + subschemas. + + Note that when using schema references, the reference keyword + appears in the runtime path in the standard output format for + errors and annotations. This means that while the validation + outcome is unchanged when switching between an embedded schema + resource and a referenced one, the runtime paths of annotations + do change. A future draft may allow directly replacing the value + of the reference keyword with its target while leaving the keyword + itself in place in order to make embedding vs referencing transparent + to annotation collection. This would allow replacing + {"$ref": "/foo"} with {"$ref": {"type": "string"}}, assuming + the schema at "verb">"/foo" consists of just a "type" keyword with + value "string". Feedback on this topic is highly encouraged. + - To specify such a subschema identifier, - the "$id" keyword is set to a URI reference with a plain name fragment (not a JSON Pointer fragment). - This value MUST begin with the number sign that specifies a fragment ("#"), - then a letter ([A-Za-z]), - followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), - colons (":"), or periods ("."). + Since URIs involving JSON Pointer fragments relative to the parent + schema resource's URI cease to be valid when the embedded schema + is moved to a separate document and referenced, applications and schemas + SHOULD NOT use such URIs to identify embedded schema resources or + locations within them. The effect of using such URIs is undefined. + Implementations MAY produce an error requiring that the canonical + URI for the embedded resource be used. - The effect of using a fragment in "$id" that isn't blank or doesn't follow the - plain name syntax is undefined. - - How should an "$id" URI reference containing a fragment with other components - be interpreted? There are two cases: when the other components match - the current base URI and when they change the base URI. - + Examples of such URIs with undefined behavior, as well as the appropriate + canonical URIs to use instead, are provided in section + .
@@ -1639,7 +1668,7 @@
-
+
Several keywords can be used to reference a schema which is to be applied to the current instance location. "$ref" and "$recursiveRef" are applicator From 7656e944f0766eb9b03d629caeaae34f3f7234ba Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 15 Aug 2019 18:13:13 -0700 Subject: [PATCH 064/780] Split $anchor from $id, update examples This adds the $anchor keyword in place of the fragment-only form of $id, and updates the schema identification examples for $anchor and canonical vs non-canonical URIs. --- jsonschema-core.xml | 202 +++++++++++++++++++++++++++++--------------- 1 file changed, 136 insertions(+), 66 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f8e4e562..9c0476c0 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1461,7 +1461,7 @@
-
+
To differentiate between schemas in a vast ecosystem, schemas are identified by URI, and can embed references @@ -1586,24 +1586,60 @@ .
-
-
- - Consider the following schema, which shows "$id" being used to identify - the root schema, change the base URI for subschemas, and assign plain - name fragments to subschemas: - - +
+
+ + Using JSON Pointer fragments requires knowledge of the structure of the schema. + When writing schema documents with the intention to provide re-usable + schemas, it may be preferable to use a plain name fragment that is not tied to + any particular structural location. This allows a subschema to be relocated + without requiring JSON Pointer references to be updated. + + + The "$anchor" keyword is used to specify such a fragment. + + + If present, the value of this keyword MUST be a string, which MUST start with + a letter ([A-Za-z]), followed by any number of letters, digits ([0-9]), + hyphens ("-"), underscores ("_"), colons (":"), or periods ("."). + + Note that the anchor string does not include the "#" character, + as it is not a URI-reference. An "$anchor": "foo" becomes the + fragment "#foo" when used in a URI. See below for full examples. + + + + The base URI to which the resulting fragment is appended is determined + by the "$id" keyword as explained in the previous section. + Two "$anchor" keywords in the same schema document MAY have the same + value if they apply to different base URIs, as the resulting full URIs + will be distinct. However, the effect of two "$anchor" keywords with the + same value and the same base URI is undefined. Implementations MAY + raise an error if such usage is detected. + +
+
+
+ + Consider the following schema, which shows "$id" being used to identify + both the root schema and various subschemas, and "$anchor" being used + to define plain name fragment identifiers. + + - -
- - The schemas at the following URI-encoded JSON - Pointers (relative to the root schema) have the following - base URIs, and are identifiable by any listed URI in accordance with - Section above: - - - - - - https://example.com/root.json - https://example.com/root.json# - - - - - https://example.com/root.json#foo - https://example.com/root.json#/$defs/A - - - - - https://example.com/other.json - https://example.com/other.json# - https://example.com/root.json#/$defs/B - - - - - https://example.com/other.json#bar - https://example.com/other.json#/$defs/X - https://example.com/root.json#/$defs/B/$defs/X - - - - - https://example.com/t/inner.json - https://example.com/t/inner.json# - https://example.com/other.json#/$defs/Y - https://example.com/root.json#/$defs/B/$defs/Y - - - - - urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f - urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f# - https://example.com/root.json#/$defs/C - - - - -
+ + + + The schemas at the following URI-encoded JSON + Pointers (relative to the root schema) have the following + base URIs, and are identifiable by any listed URI in accordance with + Section above: + + + + + + + https://example.com/root.json + + + https://example.com/root.json# + + + + + + https://example.com/root.json + + https://example.com/root.json#foo + + + https://example.com/root.json#/$defs/A + + + + + + https://example.com/other.json + + https://example.com/other.json# + + + https://example.com/root.json#/$defs/B + + + + + + https://example.com/other.json + + https://example.com/other.json#bar + + + https://example.com/other.json#/$defs/X + + + https://example.com/root.json#/$defs/B/$defs/X + + + + + + https://example.com/t/inner.json + + https://example.com/t/inner.json#bar + + + https://example.com/t/inner.json# + + + https://example.com/other.json#/$defs/Y + + + https://example.com/root.json#/$defs/B/$defs/Y + + + + + + + urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f + + + urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f# + + + https://example.com/root.json#/$defs/C + + + + +
From bd2b330bff5ef39315e16f937db92e847e7ce43c Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 16 Aug 2019 00:00:48 -0700 Subject: [PATCH 065/780] Review feedback on canonical $id $id cannot contain a fragment except for an empty one, mostly because a lot of people do that out of habit it seems. This also reworks the wording around non-canonical URIs to avoid an overly broad "undefined behavior." This still doesn't feel ideal but is hopefully an improvement. --- jsonschema-core.xml | 53 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 41 insertions(+), 12 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 9c0476c0..b6c3d8e5 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1515,7 +1515,21 @@ If present, the value for this keyword MUST be a string, and MUST represent a valid URI-reference. This URI-reference SHOULD be normalized, and MUST resolve to an - absolute-URI (without a fragment). + absolute-URI (without a fragment). Therefore, + "$id" MUST NOT contain a non-empty fragment, and SHOULD NOT contain an + empty fragment. + + + Since an empty fragment in the context of the application/schema+json media + type refers to the same resource as the base URI without a fragment, + an implementation MAY normalize a URI ending with an empty fragment by removing + the fragment. However, schema authors SHOULD NOT rely on this behavior + across implementations. + + This is primarily allowed because older meta-schemas have an empty + fragment in their $id (or previously, id). A future draft may outright + forbid even empty fragments in "$id". + This URI also serves as the base URI for relative URI-references in keywords @@ -1543,7 +1557,8 @@ but no fragment).
-
+
Since JSON Pointer URI fragments are constructed based on the structure of the schema document, an embedded schema resource and its subschemas @@ -1576,12 +1591,24 @@ schema resource's URI cease to be valid when the embedded schema is moved to a separate document and referenced, applications and schemas SHOULD NOT use such URIs to identify embedded schema resources or - locations within them. The effect of using such URIs is undefined. - Implementations MAY produce an error requiring that the canonical - URI for the embedded resource be used. + locations within them. + + + Using such URIs is unreliable, and an implementation MAY choose not to + support them. If an embedded schema were to be replaced with a reference, + then the JSON Pointer fragment URI for that schema relative to its + parent's base URI would then identify the reference, while JSON Pointers + to locations within the formerly embedded resource would become invalid. + + If the change regarding reference replacement noted in the previous + CREF were to be implemented, the pointer behavior would be more + consistent. Really it is the pointers to deeper locations within + embedded schemas which should be strongly discouraged and + need not be supported. + - Examples of such URIs with undefined behavior, as well as the appropriate + Examples of such non-canonical URIs, as well as the appropriate canonical URIs to use instead, are provided in section . @@ -1654,7 +1681,9 @@ The schemas at the following URI-encoded JSON Pointers (relative to the root schema) have the following base URIs, and are identifiable by any listed URI in accordance with - Section above: + sections and + above. As previously + noted, support for non-canonical URIs is OPTIONAL. @@ -1685,7 +1714,7 @@ https://example.com/other.json# - + https://example.com/root.json#/$defs/B @@ -1699,7 +1728,7 @@ https://example.com/other.json#/$defs/X - + https://example.com/root.json#/$defs/B/$defs/X @@ -1713,10 +1742,10 @@ https://example.com/t/inner.json# - + https://example.com/other.json#/$defs/Y - + https://example.com/root.json#/$defs/B/$defs/Y @@ -1729,7 +1758,7 @@ urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f# - + https://example.com/root.json#/$defs/C From 4f110e769c6a264dc794ed87d44ac59287c7cc2a Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 15 Aug 2019 23:05:40 -0700 Subject: [PATCH 066/780] Add $anchor to meta-schema, update $id --- hyper-schema.json | 2 +- links.json | 2 +- meta/core.json | 8 +++++++- schema.json | 4 ++-- 4 files changed, 11 insertions(+), 5 deletions(-) diff --git a/hyper-schema.json b/hyper-schema.json index bc5ba60d..54728855 100644 --- a/hyper-schema.json +++ b/hyper-schema.json @@ -1,5 +1,5 @@ { - "$schema": "https://json-schema.org/draft/2019-08/hyper-schema#", + "$schema": "https://json-schema.org/draft/2019-08/hyper-schema", "$id": "https://json-schema.org/draft/2019-08/hyper-schema", "$vocabulary": { "https://json-schema.org/draft/2019-08/vocab/core": true, diff --git a/links.json b/links.json index 0e0110db..51aeb18b 100644 --- a/links.json +++ b/links.json @@ -1,5 +1,5 @@ { - "$schema": "https://json-schema.org/draft/2019-08/hyper-schema#", + "$schema": "https://json-schema.org/draft/2019-08/hyper-schema", "$id": "https://json-schema.org/draft/2019-08/links", "title": "Link Description Object", "allOf": [ diff --git a/meta/core.json b/meta/core.json index 9dd8fbc2..73e09a85 100644 --- a/meta/core.json +++ b/meta/core.json @@ -11,12 +11,18 @@ "properties": { "$id": { "type": "string", - "format": "uri-reference" + "format": "uri-reference", + "$comment": "Non-empty fragments not allowed.", + "pattern": "^[^#]#?$" }, "$schema": { "type": "string", "format": "uri" }, + "$anchor": { + "type": "string", + "pattern": "^[A-Za-z][-A-Za-z0-9.:_]*$" + }, "$ref": { "type": "string", "format": "uri-reference" diff --git a/schema.json b/schema.json index daca1a49..80c73c70 100644 --- a/schema.json +++ b/schema.json @@ -1,6 +1,6 @@ { - "$schema": "https://json-schema.org/draft/2019-08/schema#", - "$id": "https://json-schema.org/draft/2019-08/schema#", + "$schema": "https://json-schema.org/draft/2019-08/schema", + "$id": "https://json-schema.org/draft/2019-08/schema", "$vocabulary": { "https://json-schema.org/draft/2019-08/vocab/core": true, "https://json-schema.org/draft/2019-08/vocab/applicator": true, From e1e3441bea7c7d33e8bab4dbc73d63d30b5f65a2 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 15 Aug 2019 23:04:50 -0700 Subject: [PATCH 067/780] Fix more examples for $anchor and canonical $id --- jsonschema-core.xml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b6c3d8e5..504e0df5 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2104,7 +2104,7 @@ }, "$defs": { "single": { - "$id": "#item", + "$anchor": "item", "type": "object", "additionalProperties": { "$ref": "other.json" } } @@ -2892,8 +2892,8 @@ https://json-schema.org/draft/2019-08/schema#/$defs/nonNegativeInteger/minimum Date: Thu, 15 Aug 2019 23:06:16 -0700 Subject: [PATCH 068/780] Changelog for $id and $anchor --- jsonschema-core.xml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 504e0df5..01a3aad3 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3579,6 +3579,9 @@ User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0 Additional guidance on initial base URIs beyond network retrieval Allow "schema" media type parameter for "application/schema+json" Better explanation of media type parameters and the HTTP Accept header + Use "$id" to establish canonical and base absolute-URIs only, no fragments + Replace plain-name-fragment-only form of $id with $anchor + Clarified that the behavior of JSON Pointers across $id boundary is unreliable From 428be3ccaef4f641fc2cd0465f6eff77cf13c1d4 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 17 Aug 2019 20:53:13 -0700 Subject: [PATCH 069/780] Missed a xref change to $anchor --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 01a3aad3..e292e275 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -479,7 +479,7 @@ Defining and referencing a plain name fragment identifier within an "application/schema+json" document are specified - in the "$id" keyword section. + in the "$anchor" keyword section. From 472ed6bf4701204c2a478e651526f243b2862f48 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Mon, 19 Aug 2019 22:06:03 -0700 Subject: [PATCH 070/780] Refer to the "default" meta-schema Now that the core spec explicitly defines this as the default, let's call it that. Because calling it the "core and validation" meta-schema is annoying. --- jsonschema-validation.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index f0881992..432d2bc9 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -176,8 +176,8 @@
- The current URI for the JSON Schema Validation meta-schema is - . + The current URI for the default JSON Schema meta-schema is + . For schema author convenience, this meta-schema describes all vocabularies defined in this specification and the JSON Schema Core specification, as well as two former keywords which are reserved for a transitional period. From 2da139a0df4c513cc419eb5480184458cf201fdf Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Mon, 19 Aug 2019 22:16:53 -0700 Subject: [PATCH 071/780] Dont use # in $schema values Since we're now very strongly discouraging fragments in $id, let's not use them in $schema either. It works either way, but I like the consistency. Stylistically, referring to "#" internally makes sense, while using an absolute-URI per RFC 3986 (no fragment) makes sense externally. --- jsonschema-hyperschema.xml | 12 ++++++------ meta/applicator.json | 2 +- meta/content.json | 2 +- meta/core.json | 2 +- meta/format.json | 2 +- meta/hyper-schema.json | 2 +- meta/meta-data.json | 2 +- meta/validation.json | 2 +- output/hyper-schema.json | 2 +- output/schema.json | 2 +- 10 files changed, 15 insertions(+), 15 deletions(-) diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index e3ddf254..94b3ecfe 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -1618,7 +1618,7 @@ Link: ; rel="describedBy" ; rel="describedBy" ; rel="describedBy" ; rev="up" ; rev="up" ; rev="up" Date: Thu, 22 Aug 2019 22:11:48 -0700 Subject: [PATCH 072/780] Improve guidance on annotations and output Remove wording that is no longer meaningful now that we have recommended output formats. Also do not use meta-schema as example for relative and absolute paths because my brain broke trying to figure out what it was doing. --- jsonschema-core.xml | 44 ++++++++++++++++++++++++++------------- jsonschema-validation.xml | 17 ++++++++------- 2 files changed, 38 insertions(+), 23 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 2d91ffe6..3dfce27f 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -812,22 +812,26 @@ location, annotation keywords need to specify any unusual handling of multiple applicable occurrences of the keyword with different values. - - The default behavior is simply to collect all values in a list in - indeterminate order. Given the extensibility of keywords, including - applicators, it is not possible to define a universally predictable - order of processing. - Unlike assertion results, annotation data can take a wide variety of forms, which are provided to applications to use as they see fit. JSON Schema implementations are not expected to make use of the collected information on behalf of applications. + + Unless otherwise specified, the value of an annotation keyword's + annotation is the keyword's value. However, other behaviors are possible. + For example, JSON Hyper-Schema's + "links" keyword is a complex annotation that produces a value based + in part on the instance data. + While "short-circuit" evaluation is possible for assertions, collecting annotations requires examining all schemas that apply to an instance location, even if they cannot change the overall assertion result. + The only exception is that subschemas of a schema object that has + failed validation MAY be skipped, as annotations are not retained + for failing schemas.
@@ -863,7 +867,9 @@ If the same keyword attaches values from multiple schema locations to the same instance location, and the annotation defines a process for combining such values, then the combined value MUST also be associated - with the instance location. + with the instance location. The output formats + described in this specification that include annotation information + meet this requirement.
@@ -2649,13 +2655,13 @@
- Note that this pointer may not be resolvable due to the inclusion of these - applicator keywords. + Note that this pointer may not be resolvable by the normal JSON Pointer process + due to the inclusion of these by-reference applicator keywords. The JSON key for this information is "keywordLocation". @@ -2665,13 +2671,16 @@
The absolute, dereferenced location of the validating keyword. The value MUST - be expressed as an absolute URI, and it MUST NOT include by-reference applicators - such as "$ref" or "$recursiveRef". + be expressed as an absolute URI using the canonical URI of the relevant + schema object, and it MUST NOT include by-reference applicators + such as "$ref" or "$recursiveRef" as non-terminal path components. + It MAY end in such keywords if the error or annotation is for that + keyword, such as an unresolvable reference.
@@ -2687,7 +2696,7 @@ https://json-schema.org/draft/2019-08/schema#/$defs/nonNegativeInteger/minimum
The location of the JSON value within the instance being validated. The - value MUST be expressed as a JSON Pointer. + value MUST be expressed as a URI fragment-encoded JSON Pointer. The JSON key for this information is "instanceLocation". @@ -2702,6 +2711,10 @@ https://json-schema.org/draft/2019-08/schema#/$defs/nonNegativeInteger/minimum For errors, the specific wording for the message is not defined by this specification. Implementations will need to provide this. + + For annotations, each keyword that produces an annotation specifies its + format. By default, it is the keyword's value. + The JSON key for failed validations is "error"; for successful validations it is "annotation". @@ -2715,7 +2728,8 @@ https://json-schema.org/draft/2019-08/schema#/$defs/nonNegativeInteger/minimum The JSON key for nested results in failed validations is "errors"; for - successful validations it is "annotations". + successful validations it is "annotations". Note the plural forms, as + a keyword with nested results can also have a local error or annotation.
diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index f0881992..8ea2d668 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -137,9 +137,10 @@ This specification defines a set of assertion keywords, as well as a small vocabulary of metadata keywords that can be used to annotate the JSON instance with - useful information. The and - keywords are also useful as annotations as well as being optional assertions, - as they convey additional usage guidance for the instance data. + useful information. The keyword is intended primarily + as an annotation, but can optionally be used as an assertion. The + keywords are annotations for working with documents + embedded as JSON strings.
@@ -1157,9 +1158,9 @@
The value of this keyword MUST be a boolean. When multiple occurrences - of this keyword are applicable to a single sub-instance, the resulting - value MUST be true if any occurrence specifies a true value, and MUST - be false otherwise. + of this keyword are applicable to a single sub-instance, applications + SHOULD consider the instance location to be deprecated if any occurrence + specifies a true value. If "deprecated" has a value of boolean true, it indicates that applications @@ -1179,8 +1180,8 @@ The value of these keywords MUST be a boolean. When multiple occurrences of these keywords are applicable to a single sub-instance, the resulting - value MUST be true if any occurrence specifies a true value, and MUST - be false otherwise. + behavior SHOULD be as for a true value if any occurrence specifies a true value, + and SHOULD be as for a false value otherwise. If "readOnly" has a value of boolean true, it indicates that the value From 7db77ac1da2e103e73b9dc3c058f0d3deab00ca2 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 24 Aug 2019 00:15:24 -0700 Subject: [PATCH 073/780] More consistent concept of schema resources This further clarifies the schema resource concept and how it is used. It provides an example to simplify the explanation of how non-canonical URIs can be problematic. This also relaxes a restriction on "$schema" that has no functional impact but avoids requiring implementations to detect and handle a rather complex case (embedding schema resources with different "$schema" values). And also means that embedding can work without having to change the embedded value by removing the "$schema" keyword. Additional best practices for embedding will follow in a separate commit. --- jsonschema-core.xml | 134 +++++++++++++++++++++++++++++++------------- 1 file changed, 94 insertions(+), 40 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e292e275..7ba27e8c 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -409,11 +409,6 @@ canonically identified by an absolute URI. - - As discussed in section - , a JSON Schema document - can contain multiple JSON Schema resources. - The root schema is the schema that comprises the entire JSON document in question. The root schema is always a schema resource, where the @@ -442,6 +437,15 @@ As with the root schema, a subschema is either an object or a boolean. + + As discussed in section + , a JSON Schema document + can contain multiple JSON Schema resources. When used without qualification, + the term "root schema" refers to the document's root schema. In some + cases, resource root schemas are discussed. A resource's root schema + is its top-level schema object, which would also be a document root schema + if the resource were to be extracted to a standalone JSON Schema document. +
@@ -624,7 +628,7 @@ Note that some keywords, such as "$schema", apply to the lexical scope of the entire schema document, and therefore MUST only - appear in the document's root schema. + appear in a schema resource's root schema. Other keywords may take into account the dynamic scope that @@ -1131,11 +1135,15 @@ media type "application/schema+json". - The "$schema" keyword SHOULD be used in a root schema. - It MUST NOT appear in subschemas. If absent from the root schema, the + The "$schema" keyword SHOULD be used in a resource root schema. + It MUST NOT appear in resource subschemas. If absent from the root schema, the resulting behavior is implementation-defined. + If multiple schema resources are present in a single document, then all + schema resources SHOULD Have the same value for "$schema". The result of + differing values for "$schema" within the same schema document is + implementation-defined. Using multiple "$schema" keywords in the same document would imply that the feature set and therefore behavior can change within a document. This would @@ -1145,6 +1153,12 @@ implementation behavior is subject to be revised or liberalized in future drafts. + + The exception made for embedded schema resources is to + allow bundling multiple schema resources into a single schema document + without needing to change their contents, as described later in this + specification. + \ No newline at end of file From b9d4b315f291b85421d79b977459ac879b4ed72b Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Sat, 19 Oct 2019 17:45:26 -0700 Subject: [PATCH 103/780] Added .github/PULL_REQUEST_TEMPLATE.md (optional) --- .github/PULL_REQUEST_TEMPLATE.md | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 .github/PULL_REQUEST_TEMPLATE.md diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md new file mode 100644 index 00000000..9ea9e2fb --- /dev/null +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -0,0 +1,2 @@ + \ No newline at end of file From fbb839d30c1307be6d7bec7686519cb6529acb67 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Sat, 19 Oct 2019 17:45:26 -0700 Subject: [PATCH 104/780] Updated CONTRIBUTING.md (optional) --- CONTRIBUTING.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 44e9bed2..ddeda4cd 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -43,3 +43,39 @@ As an informative document, bugs in the meta-schema may be fixed in place to ali ## Conduct All official channels including the mailing list, GitHub organization, and Freenode channel, follow the IETF Guidelines for Conduct as specified in [RFC7154](https://tools.ietf.org/html/rfc7154). + + +## Financial contributions + +We also welcome financial contributions in full transparency on our [open collective](https://opencollective.com/json-schema). +Anyone can file an expense. If the expense makes sense for the development of the community, it will be "merged" in the ledger of our open collective by the core contributors and the person who filed the expense will be reimbursed. + +## Credits + +### Code Contributors + +This project exists thanks to all the people who contribute. [[Contribute](CONTRIBUTING.md)]. + + +### Financial Contributors + +Become a financial contributor and help us sustain our community. [[Contribute](https://opencollective.com/json-schema/contribute)] + +#### Individuals + + + +#### Organizations + +Support this project with your organization. Your logo will show up here with a link to your website. [[Contribute](https://opencollective.com/json-schema/contribute)] + + + + + + + + + + + \ No newline at end of file From 23623eb3408e64b78d236e92c3f2053ad8882f4e Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Sat, 19 Oct 2019 17:49:30 -0700 Subject: [PATCH 105/780] Added financial contributors to the README --- README.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/README.md b/README.md index d6528e65..e8659d28 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,5 @@ # Welcome to JSON Schema +[![Financial Contributors on Open Collective](https://opencollective.com/json-schema/all/badge.svg?label=financial+contributors)](https://opencollective.com/json-schema) JSON Schema is a vocabulary that allows you to validate, annotate, and manipulate JSON documents. @@ -55,6 +56,36 @@ The JSON Schema web site is at http://json-schema.org/ The source for the website is [maintained in a separate repository](https://github.com/json-schema-org/json-schema-org.github.io). +## Contributors + +### Code Contributors + +This project exists thanks to all the people who contribute. [[Contribute](CONTRIBUTING.md)]. + + +### Financial Contributors + +Become a financial contributor and help us sustain our community. [[Contribute](https://opencollective.com/json-schema/contribute)] + +#### Individuals + + + +#### Organizations + +Support this project with your organization. Your logo will show up here with a link to your website. [[Contribute](https://opencollective.com/json-schema/contribute)] + + + + + + + + + + + + ## License The source material in this repository is licensed under the AFL or BSD license. From 59cd1d45e40b13ae1dd975cf5bd8489afd1f6bf1 Mon Sep 17 00:00:00 2001 From: Bryon Wicklund Date: Mon, 9 Dec 2019 16:38:09 -0600 Subject: [PATCH 106/780] Update to 10.4 "Output Structure" Per the following issue: https://github.com/json-schema-org/json-schema-spec/issues/824 --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 3f99e8e8..3fbbeedf 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2636,13 +2636,13 @@ https://example.com/schemas/common#/$defs/count/minimum Specifically, the errors it will produce are: - The second element in the "vertices" property is missing a "y" property. + The second "point" object is missing a "y" property. - The second element in the "vertices" property has a disallowed "z" property. + The second "point" object has a disallowed "z" property. - There are only two vertices, but three are required. + There are only two "point", but three are required. Note that the error message wording as depicted in these examples is not a From 2b28a947eff18ccba385eaf182d9c4f6b7bf3b56 Mon Sep 17 00:00:00 2001 From: Bryon Wicklund Date: Tue, 10 Dec 2019 17:04:19 -0600 Subject: [PATCH 107/780] Remove "points" --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 3fbbeedf..49676c6f 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2636,13 +2636,13 @@ https://example.com/schemas/common#/$defs/count/minimum Specifically, the errors it will produce are: - The second "point" object is missing a "y" property. + The second object is missing a "y" property. - The second "point" object has a disallowed "z" property. + The second object has a disallowed "z" property. - There are only two "point", but three are required. + There are only two objects, but three are required. Note that the error message wording as depicted in these examples is not a From 4cd07c369de340df24c528ac0ada6b8d9fee6219 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 8 Jan 2020 13:49:40 +0000 Subject: [PATCH 108/780] Update funding Add link to open collective --- .github/FUNDING.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml index b7c9fe2b..79117de7 100644 --- a/.github/FUNDING.yml +++ b/.github/FUNDING.yml @@ -2,7 +2,7 @@ github: # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2] patreon: # Replace with a single Patreon username -open_collective: # Replace with a single Open Collective username +open_collective: json-schema ko_fi: relequestual tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry From 50158068298fca550d2f136faeb9f859d261c416 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 8 Jan 2020 13:50:22 +0000 Subject: [PATCH 109/780] Update FUNDING.yml Add link to github sposnorship --- .github/FUNDING.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml index 79117de7..9285b3c1 100644 --- a/.github/FUNDING.yml +++ b/.github/FUNDING.yml @@ -1,6 +1,6 @@ # These are supported funding model platforms -github: # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2] +github: [relequestual] # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2] patreon: # Replace with a single Patreon username open_collective: json-schema ko_fi: relequestual From a68e14bc5ef542c9de37175f8b4612f0abceb234 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 16 Jan 2020 13:14:11 +0000 Subject: [PATCH 110/780] Update Open Collective ordering and display --- README.md | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index e8659d28..aa7bb73f 100644 --- a/README.md +++ b/README.md @@ -66,25 +66,26 @@ This project exists thanks to all the people who contribute. [[Contribute](CONTR ### Financial Contributors Become a financial contributor and help us sustain our community. [[Contribute](https://opencollective.com/json-schema/contribute)] +#### Sponsors -#### Individuals +Here are our top sponsors. You could be next! - +[[Become a sponsor](https://opencollective.com/json-schema#sponsor)] -#### Organizations + + + + + + + + + + -Support this project with your organization. Your logo will show up here with a link to your website. [[Contribute](https://opencollective.com/json-schema/contribute)] +#### Individuals - - - - - - - - - - + ## License From 2e4d23884c6862298dfc2c7524c375b5a2779e8d Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 16 Jan 2020 13:16:07 +0000 Subject: [PATCH 111/780] Fix sponsor display --- README.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/README.md b/README.md index aa7bb73f..5b42c293 100644 --- a/README.md +++ b/README.md @@ -68,9 +68,7 @@ This project exists thanks to all the people who contribute. [[Contribute](CONTR Become a financial contributor and help us sustain our community. [[Contribute](https://opencollective.com/json-schema/contribute)] #### Sponsors -Here are our top sponsors. You could be next! - -[[Become a sponsor](https://opencollective.com/json-schema#sponsor)] +Here are our top sponsors. You could be next! [[Become a sponsor](https://opencollective.com/json-schema#sponsor)] From 5d0d2095815c1cce55bea5914c57727f777410a6 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 28 Jan 2020 12:06:41 +0000 Subject: [PATCH 112/780] Make sure xref is wrapped in `t` tag to fix #814 --- relative-json-pointer.xml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index c1147a9d..b39faa0a 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -133,9 +133,12 @@ the new referenced value is that object. + + If the remainder of the Relative JSON Pointer is a JSON Pointer, then - evaluation proceeds as per RFC 6901, Section 4 - ("Evaluation"), with the modification that the initial reference + evaluation proceeds as per + RFC 6901, Section 5 + with the modification that the initial reference being used is the reference currently being held (which may not be root of the document). From 87148518f4d7f43e691516787db0e818141bf8bf Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 28 Jan 2020 13:14:17 +0000 Subject: [PATCH 113/780] `figure` should be a child of `section`, not `t`. Fixes 834 --- jsonschema-core.xml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 3f99e8e8..544a60ce 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3040,14 +3040,14 @@ Link: ;rel="schema", ;rel="schema" implementation or software product. Since symbols are listed in decreasing order of significance, the JSON Schema library name/version should precede the more generic HTTP library name (if any). For example: -
- + +
+ - -
- + +
Clients SHOULD be able to make requests with a "From" header so that server operators can contact the owner of a potentially misbehaving script. From 56c7625aeb058ecfeee670ddcb919ec80c79e1c8 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 3 Feb 2020 12:19:06 +0000 Subject: [PATCH 114/780] Don't refer to JSON values as "productions". Fixes #735 --- jsonschema-core.xml | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index fcd5d3d1..67f8014d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -211,12 +211,12 @@ depending on the type: - A JSON "null" production - A "true" or "false" value, from the JSON "true" or "false" productions - An unordered set of properties mapping a string to an instance, from the JSON "object" production - An ordered list of instances, from the JSON "array" production - An arbitrary-precision, base-10 decimal number value, from the JSON "number" production - A string of Unicode code points, from the JSON "string" production + A JSON "null" value + A "true" or "false" value, from the JSON "true" or "false" value + An unordered set of properties mapping a string to an instance, from the JSON "object" value + An ordered list of instances, from the JSON "array" value + An arbitrary-precision, base-10 decimal number value, from the JSON "number" value + A string of Unicode code points, from the JSON "string" value @@ -231,8 +231,8 @@ Since an object cannot have two properties with the same key, behavior for a - JSON document that tries to define two properties (the "member" production) with - the same key (the "string" production) in a single object is undefined. + JSON document that tries to define two properties with + the same key in a single object is undefined. Note that JSON Schema vocabularies are free to define their own extended From 47b65a0e3c947e0fc7c0a1114261db7fbbfab67f Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 3 Feb 2020 12:33:15 +0000 Subject: [PATCH 115/780] Remove white space --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index fcd5d3d1..64ea001a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1509,7 +1509,7 @@ An implementation MAY choose not to support addressing schemas - by non-canonical URIs. As such, it is RECOMENDED that schema authors only + by non-canonical URIs. As such, it is RECOMENDED that schema authors only use canonical URIs, as using non-canonical URIs may reduce schema interoperability. From 53d5fc5028e098d16dac51e1de3e2e32f2ae7ba5 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 5 Feb 2020 17:57:51 +0000 Subject: [PATCH 116/780] Fix figure tag location Resolves 842 --- jsonschema-core.xml | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b446b0fa..19ef4c5e 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1847,9 +1847,9 @@ As an example, here is a schema describing an array of positive integers, where the positive integer constraint is a subschema in "$defs": - -
- + +
+ - -
- + +
From 0c5cd460cd91c7fcb595bc3f2dc418a6dfcc6ff6 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 11 Feb 2020 00:47:00 -0800 Subject: [PATCH 117/780] Consolidate schema loading sections We are adding a section dealing with loading, processing, and referencing schemas. These sections have been moved without any changes to text or formatting beyond adjusting the indentation to fit the new location. --- jsonschema-core.xml | 587 ++++++++++++++++++++++---------------------- 1 file changed, 300 insertions(+), 287 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 19ef4c5e..e5ddec9d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1306,30 +1306,6 @@ as those listed here.
-
- - Implementations MUST recognize a schema as a meta-schema if it - is being examined because it was identified as such by another - schema's "$schema" keyword. This means that a single schema - document might sometimes be considered a regular schema, and - other times be considered a meta-schema. - - - In the case of examining a schema which is its own meta-schema, - when an implementation begins processing it as a regular schema, - it is processed under those rules. However, when loaded a second - time as a result of checking its own "$schema" value, it is treated - as a meta-schema. So the same document is processed both ways in - the course of one session. - - - Implementations MAY allow a schema to be explicitly passed as a meta-schema, - for implementation-specific purposes, such as pre-loading a commonly - used meta-schema and checking its vocabulary support requirements - up front. Meta-schema authors MUST NOT expect such features to be - interoperable across implementations. - -
@@ -1344,34 +1320,6 @@ it is necessary to establish a base URI in order to resolve the reference. -
- - RFC3986 Section 5.1 defines how to determine the - default base URI of a document. - - - Informatively, the initial base URI of a schema is the URI at which it was - found, whether that was a network location, a local filesystem, or any other - situation identifiable by a URI of any known scheme. - - - If a schema document defines no explicit base URI with "$id" - (embedded in content), the base URI is that determined per - RFC 3986 section 5. - - - If no source is known, or no URI scheme is known for the source, a suitable - implementation-specific default URI MAY be used as described in - RFC 3986 Section 5.1.4. It is RECOMMENDED - that implementations document any default base URI that they assume. - - - Unless the "$id" keyword described in the next section is present in the - root schema, this base URI SHOULD be considered the canonical URI of the - schema document's root schema resource. - -
-
The "$id" keyword identifies a schema resource with its @@ -1428,106 +1376,6 @@ but no fragment).
-
- - Since JSON Pointer URI fragments are constructed based on the structure - of the schema document, an embedded schema resource and its subschemas - can be identified by JSON Pointer fragments relative to either its own - canonical URI, or relative to the containing resource's URI. - - - Conceptually, a set of linked schema resources should behave - identically whether each resource is a separate document connected with - schema references, or is structured as - a single document with one or more schema resources embedded as - subschemas. - - - Since URIs involving JSON Pointer fragments relative to the parent - schema resource's URI cease to be valid when the embedded schema - is moved to a separate document and referenced, applications and schemas - SHOULD NOT use such URIs to identify embedded schema resources or - locations within them. - -
- - Consider the following schema document that contains another - schema resource embedded within it: - - - - - - The URI "https://example.com/foo#/items/additionalProperties" - points to the schema of the "additionalProperties" keyword in - the embedded resource. The canonical URI of that schema, however, - is "https://example.com/bar#/additionalProperties". - -
-
- - Now consider the following two schema resources linked by reference - using a URI value for "$ref": - - - - - - Here we see that the canonical URI for that "additionalProperties" - subschema is still valid, while the non-canonical URI with the fragment - beginning with "#/items/$ref" now resolves to nothing. - -
- - Note also that "https://example.com/foo#/items" is valid in both - arrangments, but resolves to a different value. This URI ends up - functioning similarly to a retrieval URI for a resource. While valid, - examining the resolved value and either using the "$id" (if the value - is a subschema), or resolving the reference and using the "$id" of the - reference target, is preferable. - - - An implementation MAY choose not to support addressing schemas - by non-canonical URIs. As such, it is RECOMENDED that schema authors only - use canonical URIs, as using non-canonical URIs may reduce - schema interoperability. - - This is to avoid requiring implementations to keep track of a whole - stack of possible base URIs and JSON Pointer fragments for each, - given that all but one will be fragile if the schema resources - are reorganized. Some have argued that this is easy so there is - no point in forbidding it, while others have argued that it complicates - schema identification and should be forbidden. Feedback on this - topic is encouraged. - - - - Further examples of such non-canonical URIs, as well as the appropriate - canonical URIs to use instead, are provided in appendix - . - -
@@ -1696,141 +1544,6 @@
-
- - A schema MUST NOT be run into an infinite loop against an instance. For - example, if two schemas "#alice" and "#bob" both have an "allOf" property - that refers to the other, a naive validator might get stuck in an infinite - recursive loop trying to validate the instance. Schemas SHOULD NOT make - use of infinite recursive nesting like this; the behavior is undefined. - -
- -
- - Subschema objects (or booleans) are recognized by their use with known - applicator keywords or with location-reserving keywords such as - "$defs" that take one or more subschemas - as a value. These keywords may be "$defs" and the standard applicators - from this document, or extension keywords from a known vocabulary, or - implementation-specific custom keywords. - - - Multi-level structures of unknown keywords are capable of introducing - nested subschemas, which would be subject to the processing rules for - "$id". Therefore, having a reference target in such an unrecognized - structure cannot be reliably implemented, and the resulting behavior - is undefined. Similarly, a reference target under a known keyword, - for which the value is known not to be a schema, results in undefined - behavior in order to avoid burdening implementations with the need - to detect such targets. - - These scenarios are analogous to fetching a schema over HTTP - but receiving a response with a Content-Type other than - application/schema+json. An implementation can certainly - try to interpret it as a schema, but the origin server - offered no guarantee that it actually is any such thing. - Therefore, interpreting it as such has security implications - and may produce unpredictable results. - - - - Note that single-level custom keywords with identical syntax and - semantics to "$defs" do not allow for any intervening "$id" keywords, - and therefore will behave correctly under implementations that attempt - to use any reference target as a schema. However, this behavior is - implementation-specific and MUST NOT be relied upon for interoperability. - -
- -
- - The use of URIs to identify remote schemas does not necessarily mean anything is downloaded, - but instead JSON Schema implementations SHOULD understand ahead of time which schemas they will be using, - and the URIs that identify them. - - - When schemas are downloaded, - for example by a generic user-agent that doesn't know until runtime which schemas to download, - see Usage for Hypermedia. - - - Implementations SHOULD be able to associate arbitrary URIs with an arbitrary - schema and/or automatically associate a schema's "$id"-given URI, depending - on the trust that the validator has in the schema. Such URIs and schemas - can be supplied to an implementation prior to processing instances, or may - be noted within a schema document as it is processed, producing associations - as shown in appendix . - - - A schema MAY (and likely will) have multiple URIs, but there is no way for a - URI to identify more than one schema. When multiple schemas try to identify - as the same URI, validators SHOULD raise an error condition. - -
-
- - Schemas can be identified by any URI that has been given to them, including - a JSON Pointer or their URI given directly by "$id". In all cases, - dereferencing a "$ref" reference involves first resolving its value as a - URI reference against the current base URI per - RFC 3986. - - - If the resulting URI identifies a schema within the current document, or - within another schema document that has been made available to the implementation, - then that schema SHOULD be used automatically. - - - For example, consider this schema: - - -
- - - -
- - When an implementation encounters the <#/$defs/single> schema, - it resolves the "$id" URI reference against the current base URI to form - <https://example.net/root.json#item>. - - - When an implementation then looks inside the <#/items> schema, it - encounters the <#item> reference, and resolves this to - <https://example.net/root.json#item>, which it has seen defined in - this same document and can therefore use automatically. - - - When an implementation encounters the reference to "other.json", it resolves - this to <https://example.net/other.json>, which is not defined in this - document. If a schema with that identifier has otherwise been supplied to - the implementation, it can also be used automatically. - - What should implementations do when the referenced schema is not known? - Are there circumstances in which automatic network dereferencing is - allowed? A same origin policy? A user-configurable option? In the - case of an evolving API described by Hyper-Schema, it is expected that - new schemas will be added to the system dynamically, so placing an - absolute requirement of pre-loading schema documents is not feasible. - - -
@@ -1906,6 +1619,306 @@
+
+ + +
+
+ + RFC3986 Section 5.1 defines how to determine the + default base URI of a document. + + + Informatively, the initial base URI of a schema is the URI at which it was + found, whether that was a network location, a local filesystem, or any other + situation identifiable by a URI of any known scheme. + + + If a schema document defines no explicit base URI with "$id" + (embedded in content), the base URI is that determined per + RFC 3986 section 5. + + + If no source is known, or no URI scheme is known for the source, a suitable + implementation-specific default URI MAY be used as described in + RFC 3986 Section 5.1.4. It is RECOMMENDED + that implementations document any default base URI that they assume. + + + Unless the "$id" keyword described in the next section is present in the + root schema, this base URI SHOULD be considered the canonical URI of the + schema document's root schema resource. + +
+ +
+ + The use of URIs to identify remote schemas does not necessarily mean anything is downloaded, + but instead JSON Schema implementations SHOULD understand ahead of time which schemas they will be using, + and the URIs that identify them. + + + When schemas are downloaded, + for example by a generic user-agent that doesn't know until runtime which schemas to download, + see Usage for Hypermedia. + + + Implementations SHOULD be able to associate arbitrary URIs with an arbitrary + schema and/or automatically associate a schema's "$id"-given URI, depending + on the trust that the validator has in the schema. Such URIs and schemas + can be supplied to an implementation prior to processing instances, or may + be noted within a schema document as it is processed, producing associations + as shown in appendix . + + + A schema MAY (and likely will) have multiple URIs, but there is no way for a + URI to identify more than one schema. When multiple schemas try to identify + as the same URI, validators SHOULD raise an error condition. + +
+ +
+ + Implementations MUST recognize a schema as a meta-schema if it + is being examined because it was identified as such by another + schema's "$schema" keyword. This means that a single schema + document might sometimes be considered a regular schema, and + other times be considered a meta-schema. + + + In the case of examining a schema which is its own meta-schema, + when an implementation begins processing it as a regular schema, + it is processed under those rules. However, when loaded a second + time as a result of checking its own "$schema" value, it is treated + as a meta-schema. So the same document is processed both ways in + the course of one session. + + + Implementations MAY allow a schema to be explicitly passed as a meta-schema, + for implementation-specific purposes, such as pre-loading a commonly + used meta-schema and checking its vocabulary support requirements + up front. Meta-schema authors MUST NOT expect such features to be + interoperable across implementations. + +
+
+ +
+ + Schemas can be identified by any URI that has been given to them, including + a JSON Pointer or their URI given directly by "$id". In all cases, + dereferencing a "$ref" reference involves first resolving its value as a + URI reference against the current base URI per + RFC 3986. + + + If the resulting URI identifies a schema within the current document, or + within another schema document that has been made available to the implementation, + then that schema SHOULD be used automatically. + + + For example, consider this schema: + + +
+ + + +
+ + When an implementation encounters the <#/$defs/single> schema, + it resolves the "$id" URI reference against the current base URI to form + <https://example.net/root.json#item>. + + + When an implementation then looks inside the <#/items> schema, it + encounters the <#item> reference, and resolves this to + <https://example.net/root.json#item>, which it has seen defined in + this same document and can therefore use automatically. + + + When an implementation encounters the reference to "other.json", it resolves + this to <https://example.net/other.json>, which is not defined in this + document. If a schema with that identifier has otherwise been supplied to + the implementation, it can also be used automatically. + + What should implementations do when the referenced schema is not known? + Are there circumstances in which automatic network dereferencing is + allowed? A same origin policy? A user-configurable option? In the + case of an evolving API described by Hyper-Schema, it is expected that + new schemas will be added to the system dynamically, so placing an + absolute requirement of pre-loading schema documents is not feasible. + + + +
+ + Since JSON Pointer URI fragments are constructed based on the structure + of the schema document, an embedded schema resource and its subschemas + can be identified by JSON Pointer fragments relative to either its own + canonical URI, or relative to the containing resource's URI. + + + Conceptually, a set of linked schema resources should behave + identically whether each resource is a separate document connected with + schema references, or is structured as + a single document with one or more schema resources embedded as + subschemas. + + + Since URIs involving JSON Pointer fragments relative to the parent + schema resource's URI cease to be valid when the embedded schema + is moved to a separate document and referenced, applications and schemas + SHOULD NOT use such URIs to identify embedded schema resources or + locations within them. + +
+ + Consider the following schema document that contains another + schema resource embedded within it: + + + + + + The URI "https://example.com/foo#/items/additionalProperties" + points to the schema of the "additionalProperties" keyword in + the embedded resource. The canonical URI of that schema, however, + is "https://example.com/bar#/additionalProperties". + +
+
+ + Now consider the following two schema resources linked by reference + using a URI value for "$ref": + + + + + + Here we see that the canonical URI for that "additionalProperties" + subschema is still valid, while the non-canonical URI with the fragment + beginning with "#/items/$ref" now resolves to nothing. + +
+ + Note also that "https://example.com/foo#/items" is valid in both + arrangments, but resolves to a different value. This URI ends up + functioning similarly to a retrieval URI for a resource. While valid, + examining the resolved value and either using the "$id" (if the value + is a subschema), or resolving the reference and using the "$id" of the + reference target, is preferable. + + + An implementation MAY choose not to support addressing schemas + by non-canonical URIs. As such, it is RECOMENDED that schema authors only + use canonical URIs, as using non-canonical URIs may reduce + schema interoperability. + + This is to avoid requiring implementations to keep track of a whole + stack of possible base URIs and JSON Pointer fragments for each, + given that all but one will be fragile if the schema resources + are reorganized. Some have argued that this is easy so there is + no point in forbidding it, while others have argued that it complicates + schema identification and should be forbidden. Feedback on this + topic is encouraged. + + + + Further examples of such non-canonical URIs, as well as the appropriate + canonical URIs to use instead, are provided in appendix + . + +
+
+ +
+
+ + A schema MUST NOT be run into an infinite loop against an instance. For + example, if two schemas "#alice" and "#bob" both have an "allOf" property + that refers to the other, a naive validator might get stuck in an infinite + recursive loop trying to validate the instance. Schemas SHOULD NOT make + use of infinite recursive nesting like this; the behavior is undefined. + +
+ +
+ + Subschema objects (or booleans) are recognized by their use with known + applicator keywords or with location-reserving keywords such as + "$defs" that take one or more subschemas + as a value. These keywords may be "$defs" and the standard applicators + from this document, or extension keywords from a known vocabulary, or + implementation-specific custom keywords. + + + Multi-level structures of unknown keywords are capable of introducing + nested subschemas, which would be subject to the processing rules for + "$id". Therefore, having a reference target in such an unrecognized + structure cannot be reliably implemented, and the resulting behavior + is undefined. Similarly, a reference target under a known keyword, + for which the value is known not to be a schema, results in undefined + behavior in order to avoid burdening implementations with the need + to detect such targets. + + These scenarios are analogous to fetching a schema over HTTP + but receiving a response with a Content-Type other than + application/schema+json. An implementation can certainly + try to interpret it as a schema, but the origin server + offered no guarantee that it actually is any such thing. + Therefore, interpreting it as such has security implications + and may produce unpredictable results. + + + + Note that single-level custom keywords with identical syntax and + semantics to "$defs" do not allow for any intervening "$id" keywords, + and therefore will behave correctly under implementations that attempt + to use any reference target as a schema. However, this behavior is + implementation-specific and MUST NOT be relied upon for interoperability. + +
+
+ +
+
This section defines a vocabulary of applicator keywords that From da5a29c351756a26cea1169586701baebf82e1ed Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 15 Feb 2020 23:38:33 -0800 Subject: [PATCH 118/780] Move hypermedia to loading section Left this out of the earlier section rearranging. This is just a move and indent, no change to the text at all. --- jsonschema-core.xml | 356 ++++++++++++++++++++++---------------------- 1 file changed, 180 insertions(+), 176 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e5ddec9d..089085bb 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1619,7 +1619,7 @@
-
+
@@ -1917,6 +1917,185 @@
+
+ +
+ + + JSON has been adopted widely by HTTP servers for automated APIs and robots. This + section describes how to enhance processing of JSON documents in a more RESTful + manner when used with protocols that support media types and + Web linking. + + +
+ + It is RECOMMENDED that instances described by a schema provide a link to + a downloadable JSON Schema using the link relation "describedby", as defined by + Linked Data Protocol 1.0, section 8.1. + + + + In HTTP, such links can be attached to any response using the + Link header. An example of such a header would be: + + +
+ + ; rel="describedby" + ]]> + +
+ +
+ + +
+ + Media types MAY allow for a "schema" media type parameter, which gives + HTTP servers the ability to perform Content-Type Negotiation based on schema. + The media-type parameter MUST be a whitespace-separated list of URIs + (i.e. relative references are invalid). + + + When using the media type application/schema-instance+json, the "schema" + parameter MUST be supplied. + + + When using the media type application/schema+json, the "schema" parameter + MAY be supplied. If supplied, it SHOULD contain the same URI as identified + by the "$schema" keyword, and MAY contain additional URIs. The "$schema" + URI MUST be considered the schema's canonical meta-schema, regardless + of the presence of alternative or additional meta-schemas as a media type + parameter. + + + The schema URI is opaque and SHOULD NOT automatically be dereferenced. + If the implementation does not understand the semantics of the provided schema, + the implementation can instead follow the "describedby" links, if any, which may + provide information on how to handle the schema. + Since "schema" doesn't necessarily point to a network location, the + "describedby" relation is used for linking to a downloadable schema. + However, for simplicity, schema authors should make these URIs point to the same + resource when possible. + + + + In HTTP, the media-type parameter would be sent inside the Content-Type header: + + +
+ + + +
+ + + Multiple schemas are whitespace separated, and indicate that the + instance conforms to all of the listed schemas: + + +
+ + + +
+ + + Media type parameters are also used in HTTP's Accept request header: + + +
+ + + +
+ + + As with Content-Type, multiple schema parameters in the same string + requests an instance that conforms to all of the listed schemas. + + + + Unlike Content-Type, Accept can contain multiple values to + indicate that the client can accept several media types. + In the above example, note that the two media types differ + only by their schema parameter values. This requests an + application/json representation that conforms to at least one + of the identified schemas. + + + + + This paragraph assumes that we can register a "schema" link relation. + Should we instead specify something like "tag:json-schema.org,2017:schema" + for now? + + HTTP can also send the "schema" in a Link, though this may impact media-type + semantics and Content-Type negotiation if this replaces the media-type parameter + entirely: + + +
+ + ;rel="schema", ;rel="schema" + ]]> + +
+ +
+ +
+ + When used for hypermedia systems over a network, + HTTP is frequently the protocol of choice for + distributing schemas. Misbehaving clients can pose problems for server + maintainers if they pull a schema over the network more frequently than + necessary, when it's instead possible to cache a schema for a long period of + time. + + + HTTP servers SHOULD set long-lived caching headers on JSON Schemas. + HTTP clients SHOULD observe caching headers and not re-request documents within + their freshness period. + Distributed systems SHOULD make use of a shared cache and/or caching proxy. + + + Clients SHOULD set or prepend a User-Agent header specific to the JSON Schema + implementation or software product. Since symbols are listed in decreasing order + of significance, the JSON Schema library name/version should precede the more + generic HTTP library name (if any). For example: + +
+ + + +
+ + Clients SHOULD be able to make requests with a "From" header so that server + operators can contact the owner of a potentially misbehaving script. + +
+ +
+ +
+
@@ -2893,181 +3072,6 @@ https://example.com/schemas/common#/$defs/count/minimum
-
- - - JSON has been adopted widely by HTTP servers for automated APIs and robots. This - section describes how to enhance processing of JSON documents in a more RESTful - manner when used with protocols that support media types and - Web linking. - - -
- - It is RECOMMENDED that instances described by a schema provide a link to - a downloadable JSON Schema using the link relation "describedby", as defined by - Linked Data Protocol 1.0, section 8.1. - - - - In HTTP, such links can be attached to any response using the - Link header. An example of such a header would be: - - -
- -; rel="describedby" -]]> - -
- -
- - -
- - Media types MAY allow for a "schema" media type parameter, which gives - HTTP servers the ability to perform Content-Type Negotiation based on schema. - The media-type parameter MUST be a whitespace-separated list of URIs - (i.e. relative references are invalid). - - - When using the media type application/schema-instance+json, the "schema" - parameter MUST be supplied. - - - When using the media type application/schema+json, the "schema" parameter - MAY be supplied. If supplied, it SHOULD contain the same URI as identified - by the "$schema" keyword, and MAY contain additional URIs. The "$schema" - URI MUST be considered the schema's canonical meta-schema, regardless - of the presence of alternative or additional meta-schemas as a media type - parameter. - - - The schema URI is opaque and SHOULD NOT automatically be dereferenced. - If the implementation does not understand the semantics of the provided schema, - the implementation can instead follow the "describedby" links, if any, which may - provide information on how to handle the schema. - Since "schema" doesn't necessarily point to a network location, the - "describedby" relation is used for linking to a downloadable schema. - However, for simplicity, schema authors should make these URIs point to the same - resource when possible. - - - - In HTTP, the media-type parameter would be sent inside the Content-Type header: - - -
- - - -
- - - Multiple schemas are whitespace separated, and indicate that the - instance conforms to all of the listed schemas: - - -
- - - -
- - - Media type parameters are also used in HTTP's Accept request header: - - -
- - - -
- - - As with Content-Type, multiple schema parameters in the same string - requests an instance that conforms to all of the listed schemas. - - - - Unlike Content-Type, Accept can contain multiple values to - indicate that the client can accept several media types. - In the above example, note that the two media types differ - only by their schema parameter values. This requests an - application/json representation that conforms to at least one - of the identified schemas. - - - - - This paragraph assumes that we can register a "schema" link relation. - Should we instead specify something like "tag:json-schema.org,2017:schema" - for now? - - HTTP can also send the "schema" in a Link, though this may impact media-type - semantics and Content-Type negotiation if this replaces the media-type parameter - entirely: - - -
- -;rel="schema", ;rel="schema" -]]> - -
- -
- -
- - When used for hypermedia systems over a network, - HTTP is frequently the protocol of choice for - distributing schemas. Misbehaving clients can pose problems for server - maintainers if they pull a schema over the network more frequently than - necessary, when it's instead possible to cache a schema for a long period of - time. - - - HTTP servers SHOULD set long-lived caching headers on JSON Schemas. - HTTP clients SHOULD observe caching headers and not re-request documents within - their freshness period. - Distributed systems SHOULD make use of a shared cache and/or caching proxy. - - - Clients SHOULD set or prepend a User-Agent header specific to the JSON Schema - implementation or software product. Since symbols are listed in decreasing order - of significance, the JSON Schema library name/version should precede the more - generic HTTP library name (if any). For example: - -
- - - -
- - Clients SHOULD be able to make requests with a "From" header so that server - operators can contact the owner of a potentially misbehaving script. - -
- -
-
Both schemas and instances are JSON values. As such, all security considerations From faa91997d1c214d3a66e83d63ac9602a29f65364 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 20 Feb 2020 16:36:52 -0800 Subject: [PATCH 119/780] Fix email RFC reference We were referring to 5322 when we really wanted 5321. Note that the RFC we cite for idn-email, 6531, explicitly extends the syntax from 5322. This brings them into alignment. --- jsonschema-validation.xml | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 7827c31c..58d334fc 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -12,7 +12,7 @@ - + @@ -54,7 +54,7 @@ - + Internet Engineering Task Force JSON Schema @@ -758,10 +758,12 @@ Internet email address as follows: - As defined by RFC 5322, section 3.4.1. + As defined by the "Mailbox" ABNF rule in + RFC 5321, section 4.1.2. - As defined by RFC 6531 + As defined by the extended "Mailbox" ABNF rule in + RFC 6531, section 3.3. Note that all strings valid against the "email" attribute are also @@ -1302,7 +1304,7 @@ &RFC4122; &RFC4291; &RFC4648; - &RFC5322; + &RFC5321; &RFC5890; &RFC5891; &RFC6570; From af4f0a1d1b1e96037b6ab4e2ce875fbe2df4e423 Mon Sep 17 00:00:00 2001 From: Ethan Date: Sun, 8 Mar 2020 04:01:32 -0700 Subject: [PATCH 120/780] don't link vocabulary URIs; they are not retrievable --- jsonschema-core.xml | 4 ++-- jsonschema-hyperschema.xml | 2 +- jsonschema-validation.xml | 8 ++++---- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 3f99e8e8..fefa2087 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1099,7 +1099,7 @@ The current URI for the Core vocabulary is: - . + <https://json-schema.org/draft/2019-09/vocab/core>. The current URI for the corresponding meta-schema is: @@ -1918,7 +1918,7 @@ The current URI for this vocabulary, known as the Applicator vocabulary, is: - . + <https://json-schema.org/draft/2019-09/vocab/applicator>. The current URI for the corresponding meta-schema is: diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index 29ac22a5..294fc21a 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -286,7 +286,7 @@ The current URI for this vocabulary, known as the Hyper-Schema vocabulary, is: - . + <https://json-schema.org/draft/2019-09/vocab/hyper-schema>. The current URI for the corresponding meta-schema, which differs from the diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 7827c31c..14844bac 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -206,7 +206,7 @@ The current URI for this vocabulary, known as the Validation vocabulary, is: - . + <https://json-schema.org/draft/2019-09/vocab/validation>. The current URI for the corresponding meta-schema is: @@ -548,7 +548,7 @@ The current URI for this vocabulary, known as the Format vocabulary, is: - . + <https://json-schema.org/draft/2019-09/vocab/format>. The current URI for the corresponding meta-schema is: @@ -926,7 +926,7 @@ The current URI for this vocabulary, known as the Content vocabulary, is: - . + <https://json-schema.org/draft/2019-09/vocab/content>. The current URI for the corresponding meta-schema is: @@ -1123,7 +1123,7 @@ The current URI for this vocabulary, known as the Meta-Data vocabulary, is: - . + <https://json-schema.org/draft/2019-09/vocab/meta-data>. The current URI for the corresponding meta-schema is: From 2020f21e03ebf9831fb61a46a8ca005b078d361b Mon Sep 17 00:00:00 2001 From: vanou Date: Wed, 18 Mar 2020 21:41:52 +0900 Subject: [PATCH 121/780] Fixing Wording in Annotation Section --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 089085bb..fbb65fd4 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -859,8 +859,8 @@ on behalf of applications. - Unless otherwise specified, the value of an annotation keyword's - annotation is the keyword's value. However, other behaviors are possible. + Unless otherwise specified, the value of an annotation keyword + is the keyword's value. However, other behaviors are possible. For example, JSON Hyper-Schema's "links" keyword is a complex annotation that produces a value based in part on the instance data. From 3093dd648c5e01abd776289b1f6f7697ea25e2df Mon Sep 17 00:00:00 2001 From: vanou Date: Thu, 19 Mar 2020 00:34:44 +0900 Subject: [PATCH 122/780] Fix Wording in JSON-Schema Core --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index fbb65fd4..8b648666 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1035,7 +1035,7 @@ - And the instance "This is a string", the + Against the instance "This is a string", the title annotation "Integer Value" is discarded because the type assertion in that schema object fails. The title annotation "String Value" is kept, as the instance passes the string type assertions. @@ -1074,7 +1074,7 @@ Keywords declared in this section, which all begin with "$", make up the JSON Schema Core vocabulary. These keywords are either required in - order process any schema or meta-schema, including those split across + order to process any schema or meta-schema, including those split across multiple documents, or exist to reserve keywords for purposes that require guaranteed interoperability. From 05fe4a384958c727790ab373bd86c5e4e11538b1 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 20 Feb 2020 23:11:49 -0800 Subject: [PATCH 123/780] Improve contentEncoding RFC references The reference to RFC 2045 was ambiguous and misleading. Emphasize RFC 4648 more, and clarify what from 2045 is relevant and when. --- jsonschema-validation.xml | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 58d334fc..7c5c3b4b 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -979,19 +979,19 @@ - Possible values for this property are listed in - RFC 2045, Sec 6.1 and - RFC 4648. For "base64", which is defined - in both RFCs, the definition in RFC 4648, which removes line length - limitations, SHOULD be used, as various other specifications have - mandated different lengths. Note that line lengths within a string - can be constrained using the "pattern" keyword. + Possible values indicating base 16, 32, and 64 encodings with several + variations are listed in RFC 4648. Additionally, + sections 6.7 and 6.8 of RFC 2045 provide + encodings used in MIME. As "base64" is defined in both RFCs, the definition + from RFC 4648 SHOULD be assumed unless the string is specifically intended + for use in a MIME context. If this keyword is absent, but "contentMediaType" is present, this - indicates that the media type could be encoded into UTF-8 like any - other JSON string value, and does not require additional decoding. + indicates that the encoding is the identity encoding, meaning that + no transformation was needed in order to represent the content in + a UTF-8 string. From 6fa4289049b90e3c7800917193b70b5bb5344bba Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 19 Mar 2020 16:13:52 -0700 Subject: [PATCH 124/780] Review feedback on contentEncoding, add change log --- jsonschema-validation.xml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 7c5c3b4b..013fd37a 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -984,7 +984,9 @@ sections 6.7 and 6.8 of RFC 2045 provide encodings used in MIME. As "base64" is defined in both RFCs, the definition from RFC 4648 SHOULD be assumed unless the string is specifically intended - for use in a MIME context. + for use in a MIME context. Note that all of these encodings result in + strings consisting only of 7-bit ASCII characters. Therefore, this keyword + has no meaning for strings containing characters outside of that range. @@ -1426,6 +1428,11 @@ + + + Clarified the set and meaning of "contentEncoding" values + + Grouped keywords into formal vocabuarlies From 3948c470cd0457b04b63c8e95a14abc3225565f5 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 19 Mar 2020 16:16:13 -0700 Subject: [PATCH 125/780] Change log entry for email format fix --- jsonschema-validation.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 013fd37a..c1b995e5 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1430,6 +1430,7 @@ + Correct email format RFC reference to 5321 instead of 5322 Clarified the set and meaning of "contentEncoding" values From 842f1146101567c3f874f3da109835ba1158e97f Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Sun, 22 Mar 2020 13:06:33 -0700 Subject: [PATCH 126/780] Fix applicator meta-schema for unevaluatedProperties --- meta/applicator.json | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/meta/applicator.json b/meta/applicator.json index b17d35c5..a7c4a314 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -18,12 +18,7 @@ }, "contains": { "$recursiveRef": "#" }, "additionalProperties": { "$recursiveRef": "#" }, - "unevaluatedProperties": { - "type": "object", - "additionalProperties": { - "$recursiveRef": "#" - } - }, + "unevaluatedProperties": { "$recursiveRef": "#" }, "properties": { "type": "object", "additionalProperties": { "$recursiveRef": "#" }, From 4e8ac5126d0240eefb9e4e4754056bd5d5db43ff Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Fri, 10 Apr 2020 12:50:41 -0700 Subject: [PATCH 127/780] fix spelling --- jsonschema-core.xml | 2 +- jsonschema-validation.xml | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 8b648666..60eda78a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1847,7 +1847,7 @@ An implementation MAY choose not to support addressing schemas - by non-canonical URIs. As such, it is RECOMENDED that schema authors only + by non-canonical URIs. As such, it is RECOMMENDED that schema authors only use canonical URIs, as using non-canonical URIs may reduce schema interoperability. diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index c1b995e5..5af85c47 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1179,7 +1179,7 @@ When the "deprecated" keyword is applied to an item in an array by means of "items", if "items" is a single schema, the deprecation relates to the whole array, while if "items" is an array of schemas, the deprecation relates to - the corrosponding item according to the subschemas position. + the corresponding item according to the subschemas position. Omitting this keyword has the same behavior as a value of false. @@ -1436,7 +1436,7 @@ - Grouped keywords into formal vocabuarlies + Grouped keywords into formal vocabularies Update "format" implementation requirements in terms of vocabularies By default, "format" MUST NOT be validated, although validation can be enabled A vocabulary declaration can be used to require "format" validation From 843f4e381d73817ea228f7bc9002b6b1e517296c Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Thu, 7 May 2020 22:57:00 -0700 Subject: [PATCH 128/780] [912] Fix trailing comma in "Output Structure" example instance --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 60eda78a..d0d264e1 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2809,7 +2809,7 @@ https://example.com/schemas/common#/$defs/count/minimum [ { "x": 2.5, - "y": 1.3, + "y": 1.3 }, { "x": 1, From 499a5bc892feb9e2ba040884fff9bceaac5568ec Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 9 May 2020 12:57:59 -0700 Subject: [PATCH 129/780] Placeholder changelog This will allow submitting multiple PRs that edit the changelog without causing merge conflicts as long as they each add their log entry to different list items. We'll remove any leftover empty items before publication. --- jsonschema-core.xml | 15 +++++++++++++++ jsonschema-validation.xml | 9 +++++++++ 2 files changed, 24 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d0d264e1..1d2824eb 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3765,6 +3765,21 @@ https://example.com/schemas/common#/$defs/count/minimum + + + + + + + + + + + + + + + Update to RFC 8259 for JSON specification diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 5af85c47..b732af56 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1432,6 +1432,15 @@ Correct email format RFC reference to 5321 instead of 5322 Clarified the set and meaning of "contentEncoding" values + + + + + + + + + From f8a6a29c63366b81c90c7d010acc90d9d99e33d1 Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Sat, 9 May 2020 15:05:39 -0700 Subject: [PATCH 130/780] Fix $anchor plain name format to match XML's NCName production This uses the US-ASCII part of the production. See: https://www.w3.org/TR/2006/REC-xml-names11-20060816/#NT-NCName --- jsonschema-core.xml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d0d264e1..700af549 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1391,9 +1391,11 @@ identifier keyword that can only be used to create plain name fragments. - If present, the value of this keyword MUST be a string, which MUST start with - a letter ([A-Za-z]), followed by any number of letters, digits ([0-9]), - hyphens ("-"), underscores ("_"), colons (":"), or periods ("."). + If present, the value of this keyword MUST be a string and MUST start with + a letter ([A-Za-z]) or underscore ("_"), followed by any number of letters, + digits ([0-9]), hyphens ("-"), underscores ("_"), and periods ("."). + This matches the US-ASCII part of XML's NCName production at + . Note that the anchor string does not include the "#" character, as it is not a URI-reference. An "$anchor": "foo" becomes the From fab4f8cefc8f565ebe39b71ad749c4ad7d76f116 Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Tue, 12 May 2020 02:17:38 -0700 Subject: [PATCH 131/780] Update the NCName reference to an xref --- jsonschema-core.xml | 34 ++++++++++++++++++++++++++++++++-- 1 file changed, 32 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 700af549..62629a18 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1394,8 +1394,8 @@ If present, the value of this keyword MUST be a string and MUST start with a letter ([A-Za-z]) or underscore ("_"), followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), and periods ("."). - This matches the US-ASCII part of XML's NCName production at - . + This matches the US-ASCII part of XML's + NCName production. Note that the anchor string does not include the "#" character, as it is not a URI-reference. An "$anchor": "foo" becomes the @@ -3252,6 +3252,36 @@ https://example.com/schemas/common#/$defs/count/minimum + + + Namespaces in XML 1.1 (Second Edition) + + Textuality +
+ tbray@textuality.com +
+ + + Contivo, Inc. +
+ dmh@contivo.com +
+ + + Microsoft +
+ andrewl@microsoft.com +
+ + + University of Edinburgh and Markup Technology Ltd +
+ richard@cogsci.ed.ac.uk +
+ + + +
From 1b485461fd15e4b516baceb6af24b116daecce91 Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Fri, 15 May 2020 03:02:15 -0700 Subject: [PATCH 132/780] Fix patterns and paths in output schema Fix a raw "$" in two patterns and add a missing "$defs" in three paths --- output/schema.json | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/output/schema.json b/output/schema.json index 7cf4c4ac..dce6fc0b 100644 --- a/output/schema.json +++ b/output/schema.json @@ -50,16 +50,16 @@ { "properties": { "keywordLocation": { - "pattern": ".*/$ref/.*" + "pattern": ".*/\\$ref/.*" } - } + } }, { "properties": { "keywordLocation": { - "pattern": ".*/$recursiveRef/.*" + "pattern": ".*/\\$recursiveRef/.*" } - } + } } ] }, @@ -79,8 +79,8 @@ }, "required": [ "valid" ] }, - "basic": { "$ref": "#/outputUnit" }, - "detailed": { "$ref": "#/outputUnit" }, - "verbose": { "$ref": "#/outputUnit" } + "basic": { "$ref": "#/$defs/outputUnit" }, + "detailed": { "$ref": "#/$defs/outputUnit" }, + "verbose": { "$ref": "#/$defs/outputUnit" } } } From a06d8154dab73068f3f161dd92b40b75c8e46241 Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Tue, 19 May 2020 21:30:07 -0700 Subject: [PATCH 133/780] Fix $anchor pattern in core.json This was missed in the $anchor specification update. --- meta/core.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/core.json b/meta/core.json index b28fc990..3d5311bf 100644 --- a/meta/core.json +++ b/meta/core.json @@ -21,7 +21,7 @@ }, "$anchor": { "type": "string", - "pattern": "^[A-Za-z][-A-Za-z0-9.:_]*$" + "pattern": "^[A-Za-z_][-A-Za-z0-9._]*$" }, "$ref": { "type": "string", From 4048253578afe1b9e1cb8523d8fb4f3935d34440 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Wed, 20 May 2020 10:21:10 -0700 Subject: [PATCH 134/780] fix missing link content --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d0d264e1..e986c2e4 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -457,7 +457,7 @@
- In accordance with section 3.1 of , + In accordance with section 3.1 of RFC 6839, the syntax and semantics of fragment identifiers specified for any +json media type SHOULD be as specified for "application/json". (At publication of this document, there is no fragment identification From 21fb535dce21fc55522233195b177150d520a720 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Wed, 20 May 2020 10:21:30 -0700 Subject: [PATCH 135/780] minor grammar fix --- jsonschema-validation.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 5af85c47..3e74b6c3 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -284,7 +284,7 @@
- The value of "exclusiveMaximum" MUST be number, representing an exclusive upper + The value of "exclusiveMaximum" MUST be a number, representing an exclusive upper limit for a numeric instance. @@ -306,7 +306,7 @@
- The value of "exclusiveMinimum" MUST be number, representing an exclusive lower + The value of "exclusiveMinimum" MUST be a number, representing an exclusive lower limit for a numeric instance. From eda8388d71fd8d632a62b9187d2013307a832d1d Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 20 May 2020 16:51:00 -0700 Subject: [PATCH 136/780] Update years on core and hyperschema Validation was updated a while ago, and relative json pointer is being updated in another PR that is currently open. --- jsonschema-core.xml | 2 +- jsonschema-hyperschema.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e1a67a7c..b3ab1da1 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -56,7 +56,7 @@ - + Internet Engineering Task Force JSON Schema diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index 294fc21a..f3daa676 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -42,7 +42,7 @@ - + Internet Engineering Task Force JSON Schema From 1fdfba5cacbcb942a13dd7d4aacd6ab09dd5c8fd Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 20 May 2020 16:55:21 -0700 Subject: [PATCH 137/780] Shorten long section heading. "Boolean Logic" is a better heading than "Logic" but its too long and breaks the table of contents link in the IETF HTML rendering. --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e1a67a7c..86cb6307 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2160,7 +2160,7 @@ or modifying the subschema results in various ways. -
+
These keywords correspond to logical operators for combining or modifying the boolean assertion results of the subschemas. They have no direct From d25ac0e90261b8e09509a7df5539bdca01bc084d Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 8 May 2020 20:47:54 -0700 Subject: [PATCH 138/780] Embedded vs referenced resources behave the same --- jsonschema-core.xml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b3ab1da1..f1cf898c 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -450,6 +450,10 @@ is its top-level schema object, which would also be a document root schema if the resource were to be extracted to a standalone JSON Schema document. + + Whether multiple schema resources are embedded or linked with a reference, + they are processed in the same way, with the same available behaviors. +
From f1a9a63481b9a291bf304389b2559ab75d5acf4f Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 8 May 2020 19:58:04 -0700 Subject: [PATCH 139/780] Different $schema values in embedded resources $schema is now definitively resource-scoped rather than document-scoped, as crossing a resource boundary is the same as following a $ref to an external resource. --- jsonschema-core.xml | 44 +++++++++++++------------------------------- 1 file changed, 13 insertions(+), 31 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f1cf898c..686d9bfd 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -635,7 +635,7 @@ Note that some keywords, such as "$schema", apply to the lexical - scope of the entire schema document, and therefore MUST only + scope of the entire schema resource, and therefore MUST only appear in a schema resource's root schema. @@ -1167,37 +1167,19 @@ media type "application/schema+json". - The "$schema" keyword SHOULD be used in a resource root schema. - It MUST NOT appear in resource subschemas. If absent from the root schema, the - resulting behavior is implementation-defined. + The "$schema" keyword SHOULD be used in the document root schema object, + and MAY be used in the root schema objects of embedded schema resources. + It MUST NOT appear in subschemas. If absent from the document root schema, + the resulting behavior is implementation-defined. - If multiple schema resources are present in a single document, then all - schema resources SHOULD Have the same value for "$schema". The result of - differing values for "$schema" within the same schema document is - implementation-defined. - - Using multiple "$schema" keywords in the same document would imply that the - feature set and therefore behavior can change within a document. This would - necessitate resolving a number of implementation concerns that have not yet - been clearly defined. So, while the pattern of using "$schema" only in root - schemas is likely to remain the best practice for schema authoring, - implementation behavior is subject to be revised or liberalized in - future drafts. - - - The exception made for embedded schema resources is to - allow bundling multiple schema resources into a single schema document - without needing to change their contents, as described later in this - specification. - - + If multiple schema resources are present in a single document, then + schema resources which do not have a "$schema" keyword in their root + schema object inherit the meta-schema from the enclosing resource. + + + Embedded schema resources MAY specify different "$schema" values from their + enclosing resource, as any schema that can be referenced can also be embedded. Values for this property are defined elsewhere in this and other documents, @@ -3803,7 +3785,7 @@ https://example.com/schemas/common#/$defs/count/minimum - + "$schema" MAY change for embedded resources From cafdf71d53dc5fe8e445cadd5e88090f0fcd270a Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 20 May 2020 16:49:23 -0700 Subject: [PATCH 140/780] Formalize $schema inheritance/cascade/whatever --- jsonschema-core.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 686d9bfd..3cd6c968 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1175,7 +1175,8 @@ If multiple schema resources are present in a single document, then schema resources which do not have a "$schema" keyword in their root - schema object inherit the meta-schema from the enclosing resource. + schema object MUST be processed as if "$schema" were present with the + same value as for the immediately enclosing resource. Embedded schema resources MAY specify different "$schema" values from their From 56288b401596c273f77e089957161f07369e9ae9 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 21 May 2020 23:45:27 -0700 Subject: [PATCH 141/780] Clarify subschema language re: $schema --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 3cd6c968..85ad83c8 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1169,8 +1169,8 @@ The "$schema" keyword SHOULD be used in the document root schema object, and MAY be used in the root schema objects of embedded schema resources. - It MUST NOT appear in subschemas. If absent from the document root schema, - the resulting behavior is implementation-defined. + It MUST NOT appear in non-resource root schema objects. If absent from + the document root schema, the resulting behavior is implementation-defined. If multiple schema resources are present in a single document, then From 93dfd6e5d3c87853ed0c3a1963a816ce651b763e Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 19 Mar 2020 16:08:40 -0700 Subject: [PATCH 142/780] "items"/"contains"/"unevaluatedItems"/"+prefixItems/-additionalItems" This reworks the array applicators in several ways: * "prefixItems" takes on the former role of the array form of "items" * "items" keeps its single-schema role, and takes on the role of "additionalItems" when "prefixItems" is present * "contains" now produces an annotation indicating what it evaluated * "unevaluatedItems" now respects "contains", and the language around interpreting the relevant annotation is (hopefully) less convoluted Note that this does not address the change to put unevaluatedItems into a separate vocabulary with unevaluatedProperties, which will be done as a separate PR. --- jsonschema-core.xml | 108 +++++++++++++++++++------------------------ meta/applicator.json | 9 +--- 2 files changed, 49 insertions(+), 68 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b3ab1da1..1c36d1a4 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -703,7 +703,7 @@ an alternate implementation producing the same behavior is available. Keywords of this sort SHOULD describe reasonable alternate approaches when appropriate. This approach is demonstrated by the - "" and + "" and "" keywords in this document. @@ -931,7 +931,7 @@ { "title": "Feature list", "type": "array", - "items": [ + "prefixItems": [ { "title": "Feature A", "properties": { @@ -2143,11 +2143,11 @@ "additionalProperties" and itself - "additionalItems", whose behavior is defined in terms of "items" + "items", whose behavior is defined in terms of "prefixItems" "unevaluatedItems", whose behavior is defined in terms of annotations - from "items", "additionalItems" and itself + from "prefixItems", "items", "contains", and itself @@ -2326,61 +2326,49 @@ properties and array items, and combining their results.
-
+
- The value of "items" MUST be either a valid JSON Schema or - an array of valid JSON Schemas. + The value of "prefixItems" MUST be an array of valid JSON Schemas. - If "items" is a schema, validation succeeds if all elements - in the array successfully validate against that schema. - - - If "items" is an array of schemas, validation succeeds if - each element of the instance validates against the schema at the - same position, if any. + Validation succeeds if each element of the instance validates + against the schema at the same position, if any. This keyword produces an annotation value which is the largest index to which this keyword applied a subschema. The value MAY be a boolean true if a subschema was applied to every - index of the instance, such as when "items" is a schema. - - - Annotation results for "items" keywords from multiple - schemas applied to the same instance location are combined - by setting the combined result to true if any of the values - are true, and otherwise retaining the largest numerical value. + index of the instance, such as is produced by the "items" keyword. Omitting this keyword has the same assertion behavior as - an empty schema. + an empty array.
-
- - The value of "additionalItems" MUST be a valid JSON Schema. - +
- The behavior of this keyword depends on the presence and - annotation result of "items" within the same schema object. - If "items" is present, and its annotation result is a number, - validation succeeds if every instance element at an index - greater than that number validates against "additionalItems". + The value of "items" MUST be a valid JSON Schema. - Otherwise, if "items" is absent or its annotation result - is the boolean true, "additionalItems" MUST be ignored. + This keyword applies its subschema to all instance elements + at indexes greater than the length of the "prefixItems" array + in the same schema object, as reported by the annotation result + of that "prefixItems" keyword. If no such annotation + result exists, "items" applies its subschema to all instance + array elements. + + Note that the behavior of "items" without "prefixItems" is + identical to that of the schema form of "items" in prior drafts. + When "prefixItems" is present, the behavior of "items" is + identical to the former "additionalItems" keyword. + - If the "additionalItems" subschema is applied to any + If the "items" subschema is applied to any positions within the instance array, it produces an - annotation result of boolean true, analogous to the - single schema behavior of "items". If any "additionalItems" - keyword from any subschema applied to the same instance - location produces an annotation value of true, then - the combined result from these keywords is also true. + annotation result of boolean true, indicating that all remaining array + elements have been evaluated against this keyword's subschema. Omitting this keyword has the same assertion behavior as @@ -2389,7 +2377,7 @@ Implementations MAY choose to implement or optimize this keyword in another way that produces the same effect, such as by directly - checking for the presence and size of an "items" array. + checking for the presence and size of a "prefixItems" array. Implementations that do not support annotation collection MUST do so.
@@ -2401,7 +2389,7 @@ The behavior of this keyword depends on the annotation results of adjacent keywords that apply to the instance location being validated. - Specifically, the annotations from "items" and "additionalItems", + Specifically, the annotations from "prefixItems", "items", and "contains", which can come from those keywords when they are adjacent to the "unevaluatedItems" keyword. Those two annotations, as well as "unevaluatedItems", can also result from any and all adjacent @@ -2410,33 +2398,25 @@ defined in this document. - If an "items" annotation is present, and its annotation result - is a number, and no "additionalItems" or "unevaluatedItems" - annotation is present, then validation succeeds if every instance - element at an index greater than the "items" annotation validates - against "unevaluatedItems". + If no relevant annotations are present, the "unevaluatedItems" + subschema MUST be applied to all locations in the array. + If a boolean true value is present from any of the relevant annotations, + "unevaluatedItems" MUST be ignored. Otherwise, the subschema + MUST be applied to any index greater than the largest annotation + value for "prefixItems", which does not appear in any annotation + value for "contains". - Otherwise, if any "items", "additionalItems", or "unevaluatedItems" - annotations are present with a value of boolean true, then - "unevaluatedItems" MUST be ignored. However, if none of these - annotations are present, "unevaluatedItems" MUST be applied to - all locations in the array. - - - This means that "items", "additionalItems", and all in-place applicators - MUST be evaluated before this keyword can be evaluated. Authors of - extension keywords MUST NOT define an in-place applicator that would need - to be evaluated before this keyword. + This means that "prefixItems", "items", "contains", and all in-place + applicators MUST be evaluated before this keyword can be evaluated. + Authors of extension keywords MUST NOT define an in-place applicator + that would need to be evaluated before this keyword. If the "unevaluatedItems" subschema is applied to any positions within the instance array, it produces an annotation result of boolean true, analogous to the - single schema behavior of "items". If any "unevaluatedItems" - keyword from any subschema applied to the same instance - location produces an annotation value of true, then - the combined result from these keywords is also true. + behavior of "items". Omitting this keyword has the same assertion behavior as @@ -2459,6 +2439,12 @@ array element even after the first match has been found. This is to ensure that all possible annotations are collected. + + This keyword produces an annotation value which is an array of + the indexes to which this keyword successfully applied its subschema, + in ascending order. The value MAY be a boolean true if the subschema + was successfully applied to every index of the instance. +
diff --git a/meta/applicator.json b/meta/applicator.json index a7c4a314..50052914 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -8,14 +8,9 @@ "title": "Applicator vocabulary meta-schema", "properties": { - "additionalItems": { "$recursiveRef": "#" }, + "prefixItems": { "$ref": "#/$defs/schemaArray" }, + "items": { "$recursiveRef": "#" }, "unevaluatedItems": { "$recursiveRef": "#" }, - "items": { - "anyOf": [ - { "$recursiveRef": "#" }, - { "$ref": "#/$defs/schemaArray" } - ] - }, "contains": { "$recursiveRef": "#" }, "additionalProperties": { "$recursiveRef": "#" }, "unevaluatedProperties": { "$recursiveRef": "#" }, From bce742bb10110d6b29b37d435ab114323bd843e7 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 15 May 2020 11:58:11 -0700 Subject: [PATCH 143/780] Changelog for the prior commit (array applicators) This starts from the 2nd entry because a pending PR is using the first entry. --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 1c36d1a4..7cd299a4 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3786,9 +3786,9 @@ https://example.com/schemas/common#/$defs/count/minimum - - - + Array-value "items" functionality is now "prefixItems" + "items" subsumes the old function of "additionalItems" + "contains" and "unevaluatedItems" interactions now specified From 5cc5d1caec02d787a211f4960279415d38f09d01 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 19 May 2020 16:15:49 -0700 Subject: [PATCH 144/780] Clarify the name "prefixItems" and its interactions --- jsonschema-core.xml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 7cd299a4..2739db7b 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2332,13 +2332,17 @@ Validation succeeds if each element of the instance validates - against the schema at the same position, if any. + against the schema at the same position, if any. This keyword + does not constrain the length of the array. If the array is longer + than this keyword's value, this keyword validates only the + prefix of matching length. This keyword produces an annotation value which is the largest index to which this keyword applied a subschema. The value MAY be a boolean true if a subschema was applied to every index of the instance, such as is produced by the "items" keyword. + This annotation affects the behavior of "items" and "unevaluatedItems". Omitting this keyword has the same assertion behavior as From 79fe5d21920f784edd663dbf71d0272bc0eb3cd1 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 15 May 2020 12:27:10 -0700 Subject: [PATCH 145/780] Rel JSON Ptr forward/backward index manipulation This allows using a relative pointer to look ahead or behind in arrays when calculating the initial point at which to apply the JSON Pointer that is the suffix of the Relative JSON Pointer. --- relative-json-pointer.xml | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index b39faa0a..06af623c 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -33,7 +33,7 @@ - + Internet Engineering Task Force JSON JavaScript @@ -134,6 +134,24 @@ + + If the next character is a plus ("+") or minus ("-"), followed by another + continuous sequence of decimal digits, the following steps + are taken using the decimal numeric value of that plus or minus sign + and decimal sequence: + + + If the current referenced value is not an item of an array, + then evaluation fails (see below). + + + If the referenced value is an item of an array, then the + new referenced value is the item of the array indexed by + adding the decimal value (which may be negative), to the + index of the current referenced value. + + + If the remainder of the Relative JSON Pointer is a JSON Pointer, then evaluation proceeds as per @@ -300,6 +318,11 @@ + + + Add array forward and backward index manipulation + + Update to the latest JSON RFC From c14754ef96709eceb7d8fa276b0c99644baa71f2 Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Sun, 10 May 2020 00:40:39 -0700 Subject: [PATCH 146/780] contentSchema: type MUST be a schema --- jsonschema-validation.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 20a6b799..06966a8d 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1023,7 +1023,8 @@ JSON Schema's data model. - The value of this property SHOULD be ignored if "contentMediaType" is not present. + The value of this property MUST be a valid JSON schema. It SHOULD be ignored if + "contentMediaType" is not present.
From 325e3c47c6db77c1affef4b9f15540f16d59cc7f Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Wed, 27 May 2020 16:01:10 -0700 Subject: [PATCH 147/780] remove unneeded .* from unanchored patterns --- output/schema.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/output/schema.json b/output/schema.json index dce6fc0b..8b887117 100644 --- a/output/schema.json +++ b/output/schema.json @@ -50,14 +50,14 @@ { "properties": { "keywordLocation": { - "pattern": ".*/\\$ref/.*" + "pattern": "/\\$ref/" } } }, { "properties": { "keywordLocation": { - "pattern": ".*/\\$recursiveRef/.*" + "pattern": "/\\$recursiveRef/" } } } From 36d9fe5063cf6e1389a72cae10c53d0e92564a20 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Wed, 27 May 2020 16:02:52 -0700 Subject: [PATCH 148/780] fix output schema check for absoluteKeywordLocation property it is possible to have both $ref and $recursiveRef in the traversed schema path --- output/schema.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/output/schema.json b/output/schema.json index 8b887117..bef85935 100644 --- a/output/schema.json +++ b/output/schema.json @@ -46,7 +46,7 @@ }, { "if": { - "oneOf": [ + "anyOf": [ { "properties": { "keywordLocation": { From cfa0b72bd01bf6b1c63a12689fc6203b4caa3848 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 28 May 2020 14:40:02 -0700 Subject: [PATCH 149/780] Update jsonschema-core.xml Co-authored-by: Ben Hutton --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 2739db7b..d25b23ee 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2445,9 +2445,9 @@ This keyword produces an annotation value which is an array of - the indexes to which this keyword successfully applied its subschema, - in ascending order. The value MAY be a boolean true if the subschema - was successfully applied to every index of the instance. + the indexes to which this keyword validates successfully when applying + its subschema, in ascending order. The value MAY be a boolean true if the + subschema validated successfully when applied to every index of the instance.
From c86157ccfb7b3e995632acf5bdbc77b788cd05ca Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 14 May 2020 23:51:04 -0700 Subject: [PATCH 150/780] Rename "$recursive*" to "$dynamic*" Preliminary work for revamping these keywords. --- jsonschema-core.xml | 96 ++++++++++++++++++++++----------------------- 1 file changed, 48 insertions(+), 48 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d25b23ee..b767736f 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -625,7 +625,7 @@ URI-reference or a full URI, which is found through the lexical structure of the JSON document. The "$id" core keyword and the "base" JSON Hyper-Schema keyword are examples of this sort - of behavior. Additionally, "$ref" and "$recursiveRef" from + of behavior. Additionally, "$ref" and "$dyanmicRef" from this specification resolve their values in this way, although they do not change how further values are resolved. @@ -640,12 +640,12 @@ with an instance document. The outermost dynamic scope is the root schema of the schema document in which processing begins. The path from this root schema to any particular keyword (that - includes any "$ref" and "$recursiveRef" keywords that may have + includes any "$ref" and "$dyanmicRef" keywords that may have been resolved) is considered the keyword's "validation path." Or should this be the schema object at which processing begins, even if it is not a root? This has some implications - for the case where "$recursiveAnchor" is only allowed in the + for the case where "$dyanmicAnchor" is only allowed in the root schema but processing begins in a subschema. @@ -660,8 +660,8 @@ dynamic parent, rather than examining the local lexically enclosing parent. - The concept of dynamic scope is primarily used with "$recursiveRef" and - "$recursiveAnchor", and should be considered an advanced feature + The concept of dynamic scope is primarily used with "$dyanmicRef" and + "$dyanmicAnchor", and should be considered an advanced feature and used with caution when defining additional keywords. It also appears when reporting errors and collected annotations, as it may be possible to revisit the same lexical scope repeatedly with different dynamic @@ -723,8 +723,8 @@ While custom identifier keywords are possible, vocabulary designers should take care not to disrupt the functioning of core keywords. For example, - the "$recursiveAnchor" keyword in this specification limits its URI resolution - effects to the matching "$recursiveRef" keyword, leaving "$ref" undisturbed. + the "$dyanmicAnchor" keyword in this specification limits its URI resolution + effects to the matching "$dyanmicRef" keyword, leaving "$ref" undisturbed.
@@ -775,7 +775,7 @@ For some by-reference applicators, such as "$ref", the referenced schema can be determined by static analysis of the schema document's lexical scope. Others, - such as "$recursiveRef" and "$recursiveAnchor", may make use of dynamic + such as "$dyanmicRef" and "$dyanmicAnchor", may make use of dynamic scoping, and therefore only be resolvable in the process of evaluating the schema with an instance. @@ -1416,13 +1416,13 @@
Several keywords can be used to reference a schema which is to be applied to the - current instance location. "$ref" and "$recursiveRef" are applicator - keywords, applying the referenced schema to the instance. "$recursiveAnchor" + current instance location. "$ref" and "$dyanmicRef" are applicator + keywords, applying the referenced schema to the instance. "$dyanmicAnchor" is an identifier keyword that controls how the base URI for resolving - the URI-reference value of "$recursiveRef is determined. + the URI-reference value of "$dyanmicRef is determined. - As the values of "$ref" and "$recursiveRef" are URI References, this allows + As the values of "$ref" and "$dynamicRef" are URI References, this allows the possibility to externalise or divide a schema across multiple files, and provides the ability to validate recursive structures through self-reference. @@ -1451,21 +1451,21 @@
-
+
- The "$recursiveRef" and "$recursiveAnchor" keywords are used to construct + The "$dyanmicRef" and "$dyanmicAnchor" keywords are used to construct extensible recursive schemas. A recursive schema is one that has a reference to its own root, identified by the empty fragment URI reference ("#"). - Simply stated, a "$recursiveRef" behaves identically to "$ref", except - when its target schema contains "$recursiveAnchor" with a value of true. + Simply stated, a "$dynamicRef" behaves identically to "$ref", except + when its target schema contains "$dynamicAnchor" with a value of true. In that case, the dynamic scope is examined to determine a new base URI, - and the URI-reference in "$recursiveRef" is re-evaluated against that + and the URI-reference in "$dynamicRef" is re-evaluated against that base URI. Unlike base URI changes with "$id", changes with - "$recursiveAnchor" are calculated each time a "$recursiveRef" is + "$dynamicAnchor" are calculated each time a "$dynamicRef" is resolved, and do not impact any other keywords. @@ -1477,9 +1477,9 @@ of these keywords. -
+
- The value of the "$recursiveRef" property MUST be a string which is + The value of the "$dynamicRef" property MUST be a string which is a URI-reference. It is a by-reference applicator that uses a dynamically calculated base URI to resolve its value. @@ -1492,22 +1492,22 @@ - The value of "$recursiveRef" is initially resolved against the + The value of "$dynamicRef" is initially resolved against the current base URI, in the same manner as for "$ref". The schema identified by the resulting URI is examined for the - presence of "$recursiveAnchor", and a new base URI is calculated + presence of "$dynamicAnchor", and a new base URI is calculated as described for that keyword in the following section. - Finally, the value of "$recursiveRef" is resolved against the - new base URI determined according to "$recursiveAnchor" producing + Finally, the value of "$dynamicRef" is resolved against the + new base URI determined according to "$dynamicAnchor" producing the final resolved reference URI. - Note that in the absence of "$recursiveAnchor" (and in some cases - when it is present), "$recursiveRef"'s behavior is identical to + Note that in the absence of "$dynamicAnchor" (and in some cases + when it is present), "$dynamicRef"'s behavior is identical to that of "$ref". @@ -1515,22 +1515,22 @@ referenced schema.
-
+
- The value of the "$recursiveAnchor" property MUST be a boolean. + The value of the "$dynamicAnchor" property MUST be a boolean. - "$recursiveAnchor" is used to dynamically identify a base URI - at runtime for "$recursiveRef" by marking where such a calculation + "$dynamicAnchor" is used to dynamically identify a base URI + at runtime for "$dynamicRef" by marking where such a calculation can start, and where it stops. This keyword MUST NOT affect the base URI of other keywords, unless they are explicitly defined to rely on it. If set to true, then when the containing schema object is used - as a target of "$recursiveRef", a new base URI is determined + as a target of "$dynamicRef", a new base URI is determined by examining the dynamic scope for - the outermost schema that also contains "$recursiveAnchor" + the outermost schema that also contains "$dynamicAnchor" with a value of true. The base URI of that schema is then used as the dynamic base URI. @@ -2670,7 +2670,7 @@ The relative location of the validating keyword that follows the validation path. The value MUST be expressed as a JSON Pointer, and it MUST include - any by-reference applicators such as "$ref" or "$recursiveRef". + any by-reference applicators such as "$ref" or "$dynamicRef".
@@ -2693,7 +2693,7 @@ The absolute, dereferenced location of the validating keyword. The value MUST be expressed as an absolute URI using the canonical URI of the relevant schema object, and it MUST NOT include by-reference applicators - such as "$ref" or "$recursiveRef" as non-terminal path components. + such as "$ref" or "$dynamicRef" as non-terminal path components. It MAY end in such keywords if the error or annotation is for that keyword, such as an unresolvable reference. @@ -3461,7 +3461,7 @@ https://example.com/schemas/common#/$defs/count/minimum { "$schema": "https://json-schema.org/draft/2019-09/schema", "$id": "https://example.com/tree", - "$recursiveAnchor": true, + "$dynamicAnchor": true, "type": "object", "properties": { @@ -3469,7 +3469,7 @@ https://example.com/schemas/common#/$defs/count/minimum "children": { "type": "array", "items": { - "$recursiveRef": "#" + "$dynamicRef": "#" } } } @@ -3479,7 +3479,7 @@ https://example.com/schemas/common#/$defs/count/minimum { "$schema": "https://json-schema.org/draft/2019-09/schema", "$id": "https://example.com/strict-tree", - "$recursiveAnchor": true, + "$dynamicAnchor": true, "$ref": "tree", "unevaluatedProperties": false @@ -3495,23 +3495,23 @@ https://example.com/schemas/common#/$defs/count/minimum If we apply the "strict-tree" schema to the instance, we will follow the "$ref" to the "tree" schema, examine its "children" subschema, - and find the "$recursiveAnchor" in its "items" subschema. + and find the "$dynamicAnchor" in its "items" subschema. At this point, the dynamic path is - "#/$ref/properties/children/items/$recursiveRef". + "#/$ref/properties/children/items/$dynamicRef". The base URI at this point is "https://example.com/tree", so the - "$recursiveRef" initially resolves to "https://example.com/tree#". - Since "$recursiveAnchor" is true, we examine the dynamic path to + "$dynamicRef" initially resolves to "https://example.com/tree#". + Since "$dynamicAnchor" is true, we examine the dynamic path to see if there is a different base URI to use. We find - "$recursiveAnchor" with a true value at the dynamic paths of + "$dynamicAnchor" with a true value at the dynamic paths of "#" and "#/$ref". The outermost is "#", which is the root schema of the "strict-tree" schema, so we use its base URI of "https://example.com/strict-tree", which produces a final resolved URI of - "https://example.com/strict-tree#" for the "$recursiveRef". + "https://example.com/strict-tree#" for the "$dynamicRef". This way, the recursion in the "tree" schema recurses to the root @@ -3560,8 +3560,8 @@ https://example.com/schemas/common#/$defs/count/minimum appropriate for certain use cases. - The recursive nature of meta-schemas makes the "$recursiveAnchor" - and "$recursiveRef" keywords particularly useful for extending + The recursive nature of meta-schemas makes the "$dynamicAnchor" + and "$dynamicRef" keywords particularly useful for extending existing meta-schemas, as can be seen in the JSON Hyper-Schema meta-schema which extends the Validation meta-schema. @@ -3617,7 +3617,7 @@ https://example.com/schemas/common#/$defs/count/minimum { "$schema": "https://json-schema.org/draft/2019-09/schema", "$id": "https://example.com/meta/general-use-example", - "$recursiveAnchor": true, + "$dynamicAnchor": true, "$vocabulary": { "https://json-schema.org/draft/2019-09/vocab/core": true, "https://json-schema.org/draft/2019-09/vocab/applicator": true, @@ -3652,7 +3652,7 @@ https://example.com/schemas/common#/$defs/count/minimum { "$schema": "https://json-schema.org/draft/2019-09/schema", "$id": "https://example.com/meta/example-vocab", - "$recursiveAnchor": true, + "$dynamicAnchor": true, "$vocabulary": { "https://example.com/vocab/example-vocab": true, }, From 940586a1cb790dd56faaea1521f632d3d124685a Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Mon, 11 May 2020 15:45:11 -0700 Subject: [PATCH 151/780] $dynamicAnchor creates fragment, no base URI stuff Instead of using a boolean (which never really fit with how the similarly named "$anchor" worked, and meant only one dynamic resolution was possible at a time) and messing with base URIs and re-resolving URI-references (a topic that creates plenty of confusion even on its own), use a fragment name the same as "$anchor" and make "$dynamicRef" work by just looking for the outermost resource with a matching "$dynamicAnchor" fragment name. This stil requires that the initial "$dynamicRef" target URI be a valid URI, with a fragment created by "$dynamicAnchor", in order to produce the dynamic behavior. This ensures that it is always clear which schemas are dynamic extension points and which are not. --- jsonschema-core.xml | 179 +++++++++++++++++++------------------------- 1 file changed, 76 insertions(+), 103 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b767736f..63f56be8 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -623,11 +623,9 @@ Keywords MAY be defined with a partial value, such as a URI-reference, which must be resolved against another value, such as another URI-reference or a full URI, which is found through the lexical - structure of the JSON document. The "$id" core keyword and - the "base" JSON Hyper-Schema keyword are examples of this sort - of behavior. Additionally, "$ref" and "$dyanmicRef" from - this specification resolve their values in this way, although - they do not change how further values are resolved. + structure of the JSON document. The "$id", "$ref", and + "$dyanmicRef" core keywords, and the "base" JSON Hyper-Schema + keyword, are examples of this sort of behavior. Note that some keywords, such as "$schema", apply to the lexical @@ -724,7 +722,8 @@ While custom identifier keywords are possible, vocabulary designers should take care not to disrupt the functioning of core keywords. For example, the "$dyanmicAnchor" keyword in this specification limits its URI resolution - effects to the matching "$dyanmicRef" keyword, leaving "$ref" undisturbed. + effects to the matching "$dyanmicRef" keyword, leaving the behavior + of "$ref" undisturbed.
@@ -775,7 +774,7 @@ For some by-reference applicators, such as "$ref", the referenced schema can be determined by static analysis of the schema document's lexical scope. Others, - such as "$dyanmicRef" and "$dyanmicAnchor", may make use of dynamic + such as "$dyanmicRef" (with "$dyanmicAnchor"), may make use of dynamic scoping, and therefore only be resolvable in the process of evaluating the schema with an instance. @@ -1377,8 +1376,7 @@
-
+
Using JSON Pointer fragments requires knowledge of the structure of the schema. When writing schema documents with the intention to provide re-usable @@ -1387,8 +1385,32 @@ without requiring JSON Pointer references to be updated. - The "$anchor" keyword is used to specify such a fragment. It is an - identifier keyword that can only be used to create plain name fragments. + The "$anchor" and "$dynamicAnchor" keywords are used to specify such + a fragments. They are identifier keywords that can only be used to create + plain name fragments, rather than absolute URIs as seen with "$id". + The behavior of the created fragment is identical for both keywords. + + + The base URI to which the resulting fragment is appended is the canonical + URI of the schema resource containing the "$anchor" or "$dynamicAnchor" + in question. As discussed in the previous section, this is either the + nearest "$id" in the same or parent schema object, or the base URI + for the document as determined according to RFC 3986. + + + Separately from the usual usage of URIs, "$dynamicAnchor" + indicates that the fragment is an extension point when used with + the "$dynamicRef" keyword. This low-level, advanced feature + makes it easier to extend recursive schemas such as the meta-schemas, + without imposing any particular semantics on that extension. + See the section on "$dynamicRef" + for details. + + + In most cases, the normal fragment behavior both sufficies and + is more intuitive. Therefore it is RECOMMENDED that "$anchor" + be used to create plain name fragments unless there is a clear + need for "$dynamicAnchor". If present, the value of this keyword MUST be a string and MUST start with @@ -1403,12 +1425,9 @@ - The base URI to which the resulting fragment is appended is determined - by the "$id" keyword as explained in the previous section. - Two "$anchor" keywords in the same schema document MAY have the same - value if they apply to different base URIs, as the resulting full URIs - will be distinct. However, the effect of two "$anchor" keywords with the - same value and the same base URI is undefined. Implementations MAY + The effect of specifying the same fragment name multiple times within + the same resource, using any combination of "$anchor" and/or + "$dynamicAnchor", is undefined. Implementations MAY raise an error if such usage is detected.
@@ -1417,9 +1436,7 @@ Several keywords can be used to reference a schema which is to be applied to the current instance location. "$ref" and "$dyanmicRef" are applicator - keywords, applying the referenced schema to the instance. "$dyanmicAnchor" - is an identifier keyword that controls how the base URI for resolving - the URI-reference value of "$dyanmicRef is determined. + keywords, applying the referenced schema to the instance. As the values of "$ref" and "$dynamicRef" are URI References, this allows @@ -1447,103 +1464,59 @@ The value of the "$ref" property MUST be a string which is a URI-Reference. Resolved against the current URI base, it produces the URI of the schema - to apply. + to apply. This resolution is safe to perform on schema load, as the + process of evaluating an instance cannot change how the reference resolves.
-
+
+ + The "$dynamicRef" keyword is an applicator that allows for deferring the + full resolution until runtime, at which point it is resolved each time it is + encountered while evaluating an instance. + + + Together with "$dynamicAnchor", "$dynamicRef" implements a cooperative + extension mechanism that is primarily useful with recursive schemas + (schemas that reference themselves). Both the extension point and the + runtime-determined extension target are defined with "$dynamicAnchor", + and only exhibit runtime dynamic behavior when referenced with + "$dynamicRef". + - The "$dyanmicRef" and "$dyanmicAnchor" keywords are used to construct - extensible recursive schemas. A recursive schema is one that has - a reference to its own root, identified by the empty fragment - URI reference ("#"). + The value of the "$dynamicRef" property MUST be a string which is + a URI-Reference. Resolved against the current URI base, it produces + the URI used as the starting point for runtime resolution. This initial + resolution is safe to perform on schema load. - Simply stated, a "$dynamicRef" behaves identically to "$ref", except - when its target schema contains "$dynamicAnchor" with a value of true. - In that case, the dynamic scope is examined to determine a new base URI, - and the URI-reference in "$dynamicRef" is re-evaluated against that - base URI. Unlike base URI changes with "$id", changes with - "$dynamicAnchor" are calculated each time a "$dynamicRef" is - resolved, and do not impact any other keywords. + If the initially resolved starting point URI includes a fragment that + was created by the "$dynamicAnchor" keyword, the initial URI MUST be + replaced by the URI (including the fragment) for the outermost schema + resource in the dynamic scope that defines + an identically named fragment with "$dynamicAnchor". + + Requiring both the initial and final URI fragment to be defined + by "$dynamicAnchor" ensures that the more common "$anchor" + never unexpectedly changes the dynamic resolution process + due to a naming conflict across resources. Users of + "$dynamicAnchor" are expected to be aware of the possibility + of such name collisions, while users of "$anchor" are not. + - For an example using these keyword, see appendix + Otherwise, its behavior is identical to "$ref", and no runtime + resolution is needed. + + + For a full example using theses keyword, see appendix . - The difference between the hyper-schema meta-schema in previous + The difference between the hyper-schema meta-schema in pre-2019 drafts and an this draft dramatically demonstrates the utility of these keywords. -
- - The value of the "$dynamicRef" property MUST be a string which is - a URI-reference. It is a by-reference applicator that uses - a dynamically calculated base URI to resolve its value. - - - The behavior of this keyword is defined only for the value "#". - Implementations MAY choose to consider other values to be errors. - - This restriction may be relaxed in the future, but to date only - the value "#" has a clear use case. - - - - The value of "$dynamicRef" is initially resolved against the - current base URI, in the same manner as for "$ref". - - - The schema identified by the resulting URI is examined for the - presence of "$dynamicAnchor", and a new base URI is calculated - as described for that keyword in the following section. - - - Finally, the value of "$dynamicRef" is resolved against the - new base URI determined according to "$dynamicAnchor" producing - the final resolved reference URI. - - - Note that in the absence of "$dynamicAnchor" (and in some cases - when it is present), "$dynamicRef"'s behavior is identical to - that of "$ref". - - - As with "$ref", the results of this keyword are the results of the - referenced schema. - -
-
- - The value of the "$dynamicAnchor" property MUST be a boolean. - - - "$dynamicAnchor" is used to dynamically identify a base URI - at runtime for "$dynamicRef" by marking where such a calculation - can start, and where it stops. This keyword MUST NOT affect the - base URI of other keywords, unless they are explicitly defined - to rely on it. - - - If set to true, then when the containing schema object is used - as a target of "$dynamicRef", a new base URI is determined - by examining the dynamic scope for - the outermost schema that also contains "$dynamicAnchor" - with a value of true. The base URI of that schema is then used - as the dynamic base URI. - - - If no such schema exists, then the base URI is unchanged. - - - If this keyword is set to false, the base URI is unchanged. - - - Omitting this keyword has the same behavior as a value of false. - -
From d8d7ec0623d628558780d291fd04e020c2200004 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 19 May 2020 23:29:02 -0700 Subject: [PATCH 152/780] Update recursive schema example for $dynamicAnchor This updates for the change of $recursiveRef (with a boolean) to $dynamicAnchor (with a plain name fragment), and provides a more detailed example of how the dynamic scope is used. --- jsonschema-core.xml | 69 ++++++++++++++++++++++++++++++++++----------- 1 file changed, 52 insertions(+), 17 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 63f56be8..41d925d4 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3434,7 +3434,7 @@ https://example.com/schemas/common#/$defs/count/minimum { "$schema": "https://json-schema.org/draft/2019-09/schema", "$id": "https://example.com/tree", - "$dynamicAnchor": true, + "$dynamicAnchor": "node", "type": "object", "properties": { @@ -3442,7 +3442,7 @@ https://example.com/schemas/common#/$defs/count/minimum "children": { "type": "array", "items": { - "$dynamicRef": "#" + "$dynamicRef": "#node" } } } @@ -3452,7 +3452,7 @@ https://example.com/schemas/common#/$defs/count/minimum { "$schema": "https://json-schema.org/draft/2019-09/schema", "$id": "https://example.com/strict-tree", - "$dynamicAnchor": true, + "$dynamicAnchor": node, "$ref": "tree", "unevaluatedProperties": false @@ -3465,32 +3465,67 @@ https://example.com/schemas/common#/$defs/count/minimum ]]> + + When we load these two schemas, we will notice the "$dynamicAnchor" + named "node" (note the lack of "#" as this is just the name) + present in each, resulting in the following full schema URIs: + + "https://example.com/tree#node" + "https://example.com/strict-tree#node" + + In addition, JSON Schema implementations keep track of the fact + that these fragments were created with "$dynamicAnchor". + If we apply the "strict-tree" schema to the instance, we will follow the "$ref" to the "tree" schema, examine its "children" subschema, - and find the "$dynamicAnchor" in its "items" subschema. + and find the "$dynamicRef": to "#node" (note the "#" for URI fragment syntax) + in its "items" subschema. That reference resolves to + "https://example.com/tree#node", which is a URI with a fragment + created by "$dynamicAnchor". Therefore we must examine the dynamic + scope before following the reference. + + At this point, the dynamic path is - "#/$ref/properties/children/items/$dynamicRef". + "#/$ref/properties/children/items/$dynamicRef", with a dynamic scope + containing (from the outermost scope to the innermost): + + "https://example.com/strict-tree#" + "https://example.com/tree#" + "https://example.com/tree#/properties/children" + "https://example.com/tree#/properties/children/items" + - The base URI at this point is "https://example.com/tree", so the - "$dynamicRef" initially resolves to "https://example.com/tree#". - Since "$dynamicAnchor" is true, we examine the dynamic path to - see if there is a different base URI to use. We find - "$dynamicAnchor" with a true value at the dynamic paths of - "#" and "#/$ref". + Since we are looking for a plain name fragment, which can be + defined anywhere within a schema resource, the JSON Pointer fragments + are irrelevant to this check. That means that we can remove those + fragments and eliminate consecutive duplicates, producing: + + "https://example.com/strict-tree" + "https://example.com/tree" + - The outermost is "#", which is the root schema of the "strict-tree" - schema, so we use its base URI of "https://example.com/strict-tree", - which produces a final resolved URI of - "https://example.com/strict-tree#" for the "$dynamicRef". + In this case, the outermost resource also has a "node" fragment + defined by "$dynamicAnchor". Therefore instead of resolving the + "$dynamicRef" to "https://example.com/tree#node", we resolve it to + "https://example.com/strict-tree#node". This way, the recursion in the "tree" schema recurses to the root of "strict-tree", instead of only applying "strict-tree" to the instance root, but applying "tree" to instance children. + + This example shows both "$dynamicAnchor"s in the same place + in each schema, specifically the resource root schema. + Since plain-name fragments are independent of the JSON structure, + this would work just as well if one or both of the node schema objects + were moved under "$defs". It is the matching "$dynamicAnchor" values + which tell us how to resolve the dynamic reference, not any sort of + correlation in JSON structure. +
@@ -3590,7 +3625,7 @@ https://example.com/schemas/common#/$defs/count/minimum { "$schema": "https://json-schema.org/draft/2019-09/schema", "$id": "https://example.com/meta/general-use-example", - "$dynamicAnchor": true, + "$dynamicAnchor": "meta", "$vocabulary": { "https://json-schema.org/draft/2019-09/vocab/core": true, "https://json-schema.org/draft/2019-09/vocab/applicator": true, @@ -3625,7 +3660,7 @@ https://example.com/schemas/common#/$defs/count/minimum { "$schema": "https://json-schema.org/draft/2019-09/schema", "$id": "https://example.com/meta/example-vocab", - "$dynamicAnchor": true, + "$dynamicAnchor": "meta", "$vocabulary": { "https://example.com/vocab/example-vocab": true, }, From 1875b36a7c8c8b67379d3581729f8cbc1ad27b16 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 20 May 2020 14:00:45 -0700 Subject: [PATCH 153/780] Changelog for $recursive* => $dynamic* --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 41d925d4..00f8b964 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3801,9 +3801,9 @@ https://example.com/schemas/common#/$defs/count/minimum Array-value "items" functionality is now "prefixItems" "items" subsumes the old function of "additionalItems" "contains" and "unevaluatedItems" interactions now specified - - - + Rename $recursive* to $dynamic* + $dynamicAnchor defines a fragment like $anchor + $dynamic* no longer use runtime base URI determination From 46ae0148cde41888626c0858b9761cba51a1fbf6 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 20 May 2020 16:25:23 -0700 Subject: [PATCH 154/780] Update meta-schemas for $dynamic* Replace $recursiveAnchor: true with $dynamicAnchor: "meta" and update $recursiveRef to $dynamicRef accordingly. --- hyper-schema.json | 2 +- links.json | 9 +++++---- meta/applicator.json | 30 +++++++++++++++--------------- meta/content.json | 4 ++-- meta/core.json | 4 ++-- meta/format.json | 2 +- meta/hyper-schema.json | 2 +- meta/meta-data.json | 2 +- meta/validation.json | 2 +- schema.json | 6 +++--- 10 files changed, 32 insertions(+), 31 deletions(-) diff --git a/hyper-schema.json b/hyper-schema.json index 28f9ad4f..484af6c5 100644 --- a/hyper-schema.json +++ b/hyper-schema.json @@ -10,7 +10,7 @@ "https://json-schema.org/draft/2019-09/vocab/content": true, "https://json-schema.org/draft/2019-09/vocab/hyper-schema": true }, - "$recursiveAnchor": true, + "$dynamicAnchor": "meta", "title": "JSON Hyper-Schema", "allOf": [ diff --git a/links.json b/links.json index 7b1a578f..07ad7a42 100644 --- a/links.json +++ b/links.json @@ -2,6 +2,7 @@ "$schema": "https://json-schema.org/draft/2019-09/hyper-schema", "$id": "https://json-schema.org/draft/2019-09/links", "title": "Link Description Object", + "allOf": [ { "required": [ "rel", "href" ] }, { "$ref": "#/$defs/noRequiredFields" } @@ -36,7 +37,7 @@ "format": "uri-template" }, "hrefSchema": { - "$recursiveRef": "https://json-schema.org/draft/2019-09/hyper-schema", + "$dynamicRef": "https://json-schema.org/draft/2019-09/hyper-schema#meta", "default": false }, "templatePointers": { @@ -63,7 +64,7 @@ "type": "string" }, "targetSchema": { - "$recursiveRef": "https://json-schema.org/draft/2019-09/hyper-schema", + "$dynamicRef": "https://json-schema.org/draft/2019-09/hyper-schema#meta", "default": true }, "targetMediaType": { @@ -71,7 +72,7 @@ }, "targetHints": { }, "headerSchema": { - "$recursiveRef": "https://json-schema.org/draft/2019-09/hyper-schema", + "$dynamicRef": "https://json-schema.org/draft/2019-09/hyper-schema#meta", "default": true }, "submissionMediaType": { @@ -79,7 +80,7 @@ "default": "application/json" }, "submissionSchema": { - "$recursiveRef": "https://json-schema.org/draft/2019-09/hyper-schema", + "$dynamicRef": "https://json-schema.org/draft/2019-09/hyper-schema#meta", "default": true }, "$comment": { diff --git a/meta/applicator.json b/meta/applicator.json index 50052914..6b4ac989 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -4,47 +4,47 @@ "$vocabulary": { "https://json-schema.org/draft/2019-09/vocab/applicator": true }, - "$recursiveAnchor": true, + "$dynamicAnchor": "meta", "title": "Applicator vocabulary meta-schema", "properties": { "prefixItems": { "$ref": "#/$defs/schemaArray" }, - "items": { "$recursiveRef": "#" }, - "unevaluatedItems": { "$recursiveRef": "#" }, - "contains": { "$recursiveRef": "#" }, - "additionalProperties": { "$recursiveRef": "#" }, - "unevaluatedProperties": { "$recursiveRef": "#" }, + "items": { "$dynamicRef": "#meta" }, + "unevaluatedItems": { "$dynamicRef": "#meta" }, + "contains": { "$dynamicRef": "#meta" }, + "additionalProperties": { "$dynamicRef": "#meta" }, + "unevaluatedProperties": { "$dynamicRef": "#meta" }, "properties": { "type": "object", - "additionalProperties": { "$recursiveRef": "#" }, + "additionalProperties": { "$dynamicRef": "#meta" }, "default": {} }, "patternProperties": { "type": "object", - "additionalProperties": { "$recursiveRef": "#" }, + "additionalProperties": { "$dynamicRef": "#meta" }, "propertyNames": { "format": "regex" }, "default": {} }, "dependentSchemas": { "type": "object", "additionalProperties": { - "$recursiveRef": "#" + "$dynamicRef": "#meta" } }, - "propertyNames": { "$recursiveRef": "#" }, - "if": { "$recursiveRef": "#" }, - "then": { "$recursiveRef": "#" }, - "else": { "$recursiveRef": "#" }, + "propertyNames": { "$dynamicRef": "#meta" }, + "if": { "$dynamicRef": "#meta" }, + "then": { "$dynamicRef": "#meta" }, + "else": { "$dynamicRef": "#meta" }, "allOf": { "$ref": "#/$defs/schemaArray" }, "anyOf": { "$ref": "#/$defs/schemaArray" }, "oneOf": { "$ref": "#/$defs/schemaArray" }, - "not": { "$recursiveRef": "#" } + "not": { "$dynamicRef": "#meta" } }, "$defs": { "schemaArray": { "type": "array", "minItems": 1, - "items": { "$recursiveRef": "#" } + "items": { "$dynamicRef": "#meta" } } } } diff --git a/meta/content.json b/meta/content.json index f6752a8e..e69ccdfa 100644 --- a/meta/content.json +++ b/meta/content.json @@ -4,7 +4,7 @@ "$vocabulary": { "https://json-schema.org/draft/2019-09/vocab/content": true }, - "$recursiveAnchor": true, + "$dynamicAnchor": "meta", "title": "Content vocabulary meta-schema", @@ -12,6 +12,6 @@ "properties": { "contentMediaType": { "type": "string" }, "contentEncoding": { "type": "string" }, - "contentSchema": { "$recursiveRef": "#" } + "contentSchema": { "$dynamicRef": "#meta" } } } diff --git a/meta/core.json b/meta/core.json index 3d5311bf..3a84feb1 100644 --- a/meta/core.json +++ b/meta/core.json @@ -4,7 +4,7 @@ "$vocabulary": { "https://json-schema.org/draft/2019-09/vocab/core": true }, - "$recursiveAnchor": true, + "$dynamicAnchor": "meta", "title": "Core vocabulary meta-schema", "type": ["object", "boolean"], @@ -51,7 +51,7 @@ }, "$defs": { "type": "object", - "additionalProperties": { "$recursiveRef": "#" }, + "additionalProperties": { "$dynamicRef": "#meta" }, "default": {} } } diff --git a/meta/format.json b/meta/format.json index 09bbfdda..68ad5b0d 100644 --- a/meta/format.json +++ b/meta/format.json @@ -4,7 +4,7 @@ "$vocabulary": { "https://json-schema.org/draft/2019-09/vocab/format": true }, - "$recursiveAnchor": true, + "$dynamicAnchor": "meta", "title": "Format vocabulary meta-schema", "type": ["object", "boolean"], diff --git a/meta/hyper-schema.json b/meta/hyper-schema.json index 3d230589..f36d3477 100644 --- a/meta/hyper-schema.json +++ b/meta/hyper-schema.json @@ -4,7 +4,7 @@ "$vocabulary": { "https://json-schema.org/draft/2019-09/vocab/hyper-schema": true }, - "$recursiveAnchor": true, + "$dynamicAnchor": "meta", "title": "JSON Hyper-Schema Vocabulary Schema", "type": ["object", "boolean"], diff --git a/meta/meta-data.json b/meta/meta-data.json index da04cff6..bbb171e9 100644 --- a/meta/meta-data.json +++ b/meta/meta-data.json @@ -4,7 +4,7 @@ "$vocabulary": { "https://json-schema.org/draft/2019-09/vocab/meta-data": true }, - "$recursiveAnchor": true, + "$dynamicAnchor": "meta", "title": "Meta-data vocabulary meta-schema", diff --git a/meta/validation.json b/meta/validation.json index 9f59677b..75ba4522 100644 --- a/meta/validation.json +++ b/meta/validation.json @@ -4,7 +4,7 @@ "$vocabulary": { "https://json-schema.org/draft/2019-09/vocab/validation": true }, - "$recursiveAnchor": true, + "$dynamicAnchor": "meta", "title": "Validation vocabulary meta-schema", "type": ["object", "boolean"], diff --git a/schema.json b/schema.json index 2248a0c8..4d4e8782 100644 --- a/schema.json +++ b/schema.json @@ -9,7 +9,7 @@ "https://json-schema.org/draft/2019-09/vocab/format": false, "https://json-schema.org/draft/2019-09/vocab/content": true }, - "$recursiveAnchor": true, + "$dynamicAnchor": "meta", "title": "Core and Validation specifications meta-schema", "allOf": [ @@ -25,7 +25,7 @@ "definitions": { "$comment": "While no longer an official keyword as it is replaced by $defs, this keyword is retained in the meta-schema to prevent incompatible extensions as it remains in common use.", "type": "object", - "additionalProperties": { "$recursiveRef": "#" }, + "additionalProperties": { "$dynamicRef": "#meta" }, "default": {} }, "dependencies": { @@ -33,7 +33,7 @@ "type": "object", "additionalProperties": { "anyOf": [ - { "$recursiveRef": "#" }, + { "$dynamicRef": "#meta" }, { "$ref": "meta/validation#/$defs/stringArray" } ] } From 30f97c815ad8c697546da3273cde9dcab3ea2e65 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 27 May 2020 23:53:21 -0700 Subject: [PATCH 155/780] Fix typo --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 00f8b964..abf0d6c0 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1386,7 +1386,7 @@ The "$anchor" and "$dynamicAnchor" keywords are used to specify such - a fragments. They are identifier keywords that can only be used to create + fragments. They are identifier keywords that can only be used to create plain name fragments, rather than absolute URIs as seen with "$id". The behavior of the created fragment is identical for both keywords. From 3ffae946d78fc2f4d09f3550586da1d82897f4c1 Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Sat, 23 May 2020 03:06:05 -0700 Subject: [PATCH 156/780] Fix output instance relative location to be of non-URI fragment-encoded form --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d25b23ee..18fbaf17 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2716,7 +2716,7 @@ https://example.com/schemas/common#/$defs/count/minimum
The location of the JSON value within the instance being validated. The - value MUST be expressed as a URI fragment-encoded JSON Pointer. + value MUST be expressed as a JSON Pointer. The JSON key for this information is "instanceLocation". From f1f5f63bb1c9bad9542b03e64a788ca18f2177b0 Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Sat, 23 May 2020 18:57:58 -0700 Subject: [PATCH 157/780] Update output examples to use non-URI JSON pointers for non-absolute locations --- jsonschema-core.xml | 60 ++++++++++++++++++++++----------------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 18fbaf17..adc29562 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2869,34 +2869,34 @@ https://example.com/schemas/common#/$defs/count/minimum "valid": false, "errors": [ { - "keywordLocation": "#", - "instanceLocation": "#", + "keywordLocation": "", + "instanceLocation": "", "error": "A subschema had errors." }, { - "keywordLocation": "#/items/$ref", + "keywordLocation": "/items/$ref", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point", - "instanceLocation": "#/1", + "instanceLocation": "/1", "error": "A subschema had errors." }, { - "keywordLocation": "#/items/$ref/required", + "keywordLocation": "/items/$ref/required", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point/required", - "instanceLocation": "#/1", + "instanceLocation": "/1", "error": "Required property 'y' not found." }, { - "keywordLocation": "#/items/$ref/additionalProperties", + "keywordLocation": "/items/$ref/additionalProperties", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point/additionalProperties", - "instanceLocation": "#/1/z", + "instanceLocation": "/1/z", "error": "Additional property 'z' found but was invalid." }, { - "keywordLocation": "#/minItems", - "instanceLocation": "#", + "keywordLocation": "/minItems", + "instanceLocation": "", "error": "Expected at least 3 items but found 2" } ] @@ -2936,38 +2936,38 @@ https://example.com/schemas/common#/$defs/count/minimum Date: Sun, 24 May 2020 17:19:29 -0700 Subject: [PATCH 158/780] Update the output schema with json-pointer replacing uri-reference --- output/schema.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/output/schema.json b/output/schema.json index dce6fc0b..a6c27161 100644 --- a/output/schema.json +++ b/output/schema.json @@ -15,7 +15,7 @@ "valid": { "type": "boolean" }, "keywordLocation": { "type": "string", - "format": "uri-reference" + "format": "json-pointer" }, "absoluteKeywordLocation": { "type": "string", @@ -23,7 +23,7 @@ }, "instanceLocation": { "type": "string", - "format": "uri-reference" + "format": "json-pointer" }, "errors": { "$ref": "#/$defs/outputUnitArray" From d5e34a0cf8cdaa833d69697edee04dbe188578cc Mon Sep 17 00:00:00 2001 From: stan-sb <67116470+stan-sb@users.noreply.github.com> Date: Fri, 19 Jun 2020 09:16:43 -0400 Subject: [PATCH 159/780] Issue-949: Fixing inconsistencies in output schema 1. Changing "oneOf" to "anyOf", because basic, detailed and verbose have the same definition, oneOf would fail validation. 2. Adding "error" keyword and making either "error" or "errors" required in case "valid" is false. --- output/schema.json | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/output/schema.json b/output/schema.json index dce6fc0b..e3824ffc 100644 --- a/output/schema.json +++ b/output/schema.json @@ -3,7 +3,7 @@ "$id": "https://json-schema.org/draft/2019-09/output/schema", "description": "A schema that validates the minimum requirements for validation output", - "oneOf": [ + "anyOf": [ { "$ref": "#/$defs/flag" }, { "$ref": "#/$defs/basic" }, { "$ref": "#/$defs/detailed" }, @@ -25,6 +25,9 @@ "type": "string", "format": "uri-reference" }, + "error": { + "type": "string" + }, "errors": { "$ref": "#/$defs/outputUnitArray" }, @@ -41,7 +44,14 @@ } }, "then": { - "required": [ "errors" ] + "oneOf": [ + { + "required": [ "error" ] + }, + { + "required": [ "errors" ] + } + ] } }, { From 219cbc34e8126e7d396658788697a7ee24f6c412 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 25 Jun 2020 20:54:17 +0100 Subject: [PATCH 160/780] Fix typo /dyanmic/dynamic/ --- jsonschema-core.xml | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index abf0d6c0..3df35f9a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -624,7 +624,7 @@ which must be resolved against another value, such as another URI-reference or a full URI, which is found through the lexical structure of the JSON document. The "$id", "$ref", and - "$dyanmicRef" core keywords, and the "base" JSON Hyper-Schema + "$dynamicRef" core keywords, and the "base" JSON Hyper-Schema keyword, are examples of this sort of behavior. @@ -638,12 +638,12 @@ with an instance document. The outermost dynamic scope is the root schema of the schema document in which processing begins. The path from this root schema to any particular keyword (that - includes any "$ref" and "$dyanmicRef" keywords that may have + includes any "$ref" and "$dynamicRef" keywords that may have been resolved) is considered the keyword's "validation path." Or should this be the schema object at which processing begins, even if it is not a root? This has some implications - for the case where "$dyanmicAnchor" is only allowed in the + for the case where "$dynamicAnchor" is only allowed in the root schema but processing begins in a subschema. @@ -658,8 +658,8 @@ dynamic parent, rather than examining the local lexically enclosing parent. - The concept of dynamic scope is primarily used with "$dyanmicRef" and - "$dyanmicAnchor", and should be considered an advanced feature + The concept of dynamic scope is primarily used with "$dynamicRef" and + "$dynamicAnchor", and should be considered an advanced feature and used with caution when defining additional keywords. It also appears when reporting errors and collected annotations, as it may be possible to revisit the same lexical scope repeatedly with different dynamic @@ -721,8 +721,8 @@ While custom identifier keywords are possible, vocabulary designers should take care not to disrupt the functioning of core keywords. For example, - the "$dyanmicAnchor" keyword in this specification limits its URI resolution - effects to the matching "$dyanmicRef" keyword, leaving the behavior + the "$dynamicAnchor" keyword in this specification limits its URI resolution + effects to the matching "$dynamicRef" keyword, leaving the behavior of "$ref" undisturbed.
@@ -774,7 +774,7 @@ For some by-reference applicators, such as "$ref", the referenced schema can be determined by static analysis of the schema document's lexical scope. Others, - such as "$dyanmicRef" (with "$dyanmicAnchor"), may make use of dynamic + such as "$dynamicRef" (with "$dynamicAnchor"), may make use of dynamic scoping, and therefore only be resolvable in the process of evaluating the schema with an instance. @@ -1435,7 +1435,7 @@
Several keywords can be used to reference a schema which is to be applied to the - current instance location. "$ref" and "$dyanmicRef" are applicator + current instance location. "$ref" and "$dynamicRef" are applicator keywords, applying the referenced schema to the instance. From 2dcb418738b741bab8fd81c561d7aa16d37231e3 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 25 Jun 2020 21:09:44 +0100 Subject: [PATCH 161/780] Fixed typo /theses/these/ --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 3df35f9a..effc6f83 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1509,7 +1509,7 @@ resolution is needed. - For a full example using theses keyword, see appendix + For a full example using these keyword, see appendix . The difference between the hyper-schema meta-schema in pre-2019 From 8e5f8e17f76835f5dde331478450ce6fdcbceef9 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 3 Jul 2020 20:49:37 +0100 Subject: [PATCH 162/780] Fix typo --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index effc6f83..6cc96c22 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1407,7 +1407,7 @@ for details. - In most cases, the normal fragment behavior both sufficies and + In most cases, the normal fragment behavior both suffices and is more intuitive. Therefore it is RECOMMENDED that "$anchor" be used to create plain name fragments unless there is a clear need for "$dynamicAnchor". From 98210634a57f1d0c22b79a316878ecbcb06c63af Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 3 Jul 2020 21:00:58 +0100 Subject: [PATCH 163/780] Clarify changelog item regarding $dynamic* --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 6cc96c22..6471c543 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3803,7 +3803,7 @@ https://example.com/schemas/common#/$defs/count/minimum "contains" and "unevaluatedItems" interactions now specified Rename $recursive* to $dynamic* $dynamicAnchor defines a fragment like $anchor - $dynamic* no longer use runtime base URI determination + $dynamic* (previously $recursive) no longer use runtime base URI determination From e0c1bbba2017dc6e430aca517e420094181e6d06 Mon Sep 17 00:00:00 2001 From: Helen Kosova Date: Thu, 16 Jul 2020 23:01:03 +0300 Subject: [PATCH 164/780] Fix a missing quote in the "readOnly and writeOnly" section --- jsonschema-validation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 06966a8d..4f329b42 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1201,7 +1201,7 @@ expected to be ignored or rejected by that owning authority. - An instance document that is marked as "readOnly for the entire document + An instance document that is marked as "readOnly" for the entire document MAY be ignored if sent to the owning authority, or MAY result in an error, at the authority's discretion. From 387f6db1591b7f07f4c78fda40a2903758ad26be Mon Sep 17 00:00:00 2001 From: Helen Kosova Date: Thu, 16 Jul 2020 23:56:57 +0300 Subject: [PATCH 165/780] Fix a typo: arrangments -> arrangements --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 32a02e2e..d964c0ac 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1828,7 +1828,7 @@ Note also that "https://example.com/foo#/items" is valid in both - arrangments, but resolves to a different value. This URI ends up + arrangements, but resolves to a different value. This URI ends up functioning similarly to a retrieval URI for a resource. While valid, examining the resolved value and either using the "$id" (if the value is a subschema), or resolving the reference and using the "$id" of the From 964c2f86c116d34076c2ab72af548aab85b8b7bf Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Sat, 25 Jul 2020 16:39:21 +0100 Subject: [PATCH 166/780] Create config.yaml --- .github/config.yaml | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 .github/config.yaml diff --git a/.github/config.yaml b/.github/config.yaml new file mode 100644 index 00000000..8d492766 --- /dev/null +++ b/.github/config.yaml @@ -0,0 +1,4 @@ +helpr: + opened: 'Status: RP Review Required' + merged: 'Status: PR Merged' + rejected: 'Status: PR Revision Required' From 4af51fc99152a88e726f0cf0b292b5a05612cdae Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Sat, 1 Aug 2020 09:30:20 -0700 Subject: [PATCH 167/780] [900] Add missing "type" to applicator meta-schema --- meta/applicator.json | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/applicator.json b/meta/applicator.json index 6b4ac989..64af5792 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -7,6 +7,7 @@ "$dynamicAnchor": "meta", "title": "Applicator vocabulary meta-schema", + "type": ["object", "boolean"], "properties": { "prefixItems": { "$ref": "#/$defs/schemaArray" }, "items": { "$dynamicRef": "#meta" }, From 568e20f14ef562a56cb29eebff3c8180914680de Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Thu, 11 Jun 2020 07:56:55 -0700 Subject: [PATCH 168/780] [954] Fix $recursiveAnchor in schema to match spec The spec allows values of false. This fixes the schema to match the spec. --- meta/core.json | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/core.json b/meta/core.json index 3a84feb1..c7b6c218 100644 --- a/meta/core.json +++ b/meta/core.json @@ -33,7 +33,6 @@ }, "$recursiveAnchor": { "type": "boolean", - "const": true, "default": false }, "$vocabulary": { From 5341d1f5d33a6756b9f484a95ecf5130f3dee38a Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Tue, 18 Aug 2020 20:42:14 -0700 Subject: [PATCH 169/780] fix media type in examples As amply explained by this very document, the "schema" media type parameter is not legal with the "application/json" media type. --- jsonschema-core.xml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index bbdb3e46..664bd074 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1950,7 +1950,7 @@
@@ -1964,7 +1964,7 @@
@@ -1977,9 +1977,9 @@
@@ -1995,7 +1995,7 @@ indicate that the client can accept several media types. In the above example, note that the two media types differ only by their schema parameter values. This requests an - application/json representation that conforms to at least one + application/schema-instance+json representation that conforms to at least one of the identified schemas. From 8afae0499951ce55266b7e7fee57e859410ec362 Mon Sep 17 00:00:00 2001 From: Austin Wright Date: Sun, 16 Aug 2020 22:37:58 -0700 Subject: [PATCH 170/780] Clarify how JSON Schema works with a superset of the defined data model --- jsonschema-core.xml | 44 +++++++++++++++++++++++++------------------- 1 file changed, 25 insertions(+), 19 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index bbdb3e46..7917f02b 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -200,6 +200,15 @@ A JSON document to which a schema is applied is known as an "instance". + + JSON Schema is defined over "application/json" or compatible documents, + including media types with the "+json" structured syntax suffix. + + + Among these, this specification defines the "application/schema-instance+json" + media type which defines handling for fragments in the URI, + and the "schema" media type parameter. +
@@ -243,25 +252,6 @@
-
- - JSON Schema is designed to fully work with "application/json" documents, - as well as media types using the "+json" structured syntax suffix. - - - Some functionality that is useful for working with schemas is - defined by each media type, namely media type parameters and - URI fragment identifier syntax and semantics. These features are - useful in content negotiation and in calculating URIs for specific - locations within an instance, respectively. - - - This specification defines the "application/schema-instance+json" - media type in order to allow instance authors to take full advantage - of parameters and fragment identifiers for these purposes. - -
-
Two JSON instances are said to be equal if and only if they are of the same type @@ -288,6 +278,22 @@ zeros) are insignificant.
+ +
+ + It is possible to use JSON Schema with a superset of the JSON Schema data model, + where an instance may be outside any of the six JSON data types. + + + In this case, annotations still apply; but validation keywords will not be useful, + as they will always pass or always fail. + + + A custom vocabulary may define support for a superset of the core data model. + The schema itself may only be expressible in this superset; + for example, to make use of the "const" keyword. + +
From b749600bf129206a6ab8d0e23f0630a625d082b3 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Wed, 26 Aug 2020 14:14:38 -0700 Subject: [PATCH 171/780] fix verbose output example with json-pointer replacing uri-reference this corrects an oversight from the changes made in #938. --- output/verbose-example.json | 72 ++++++++++++++++++------------------- 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/output/verbose-example.json b/output/verbose-example.json index 37acb2d5..5e6fbb4a 100644 --- a/output/verbose-example.json +++ b/output/verbose-example.json @@ -1,64 +1,64 @@ { "valid": false, - "keywordLocation": "#", - "instanceLocation": "#", + "keywordLocation": "", + "instanceLocation": "", "errors": [ { "valid": true, - "keywordLocation": "#/$defs", - "instanceLocation": "#" + "keywordLocation": "/$defs", + "instanceLocation": "" }, { "valid": true, - "keywordLocation": "#/type", - "instanceLocation": "#" + "keywordLocation": "/type", + "instanceLocation": "" }, { "valid": false, - "keywordLocation": "#/items", - "instanceLocation": "#", + "keywordLocation": "/items", + "instanceLocation": "", "errors": [ { "valid": true, - "keywordLocation": "#/items/$ref", + "keywordLocation": "/items/$ref", "absoluteKeywordLocation": "https://example.com/polygon#/items/$ref", - "instanceLocation": "#/0", + "instanceLocation": "/0", "annotations": [ { "valid": true, - "keywordLocation": "#/items/$ref", + "keywordLocation": "/items/$ref", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point", - "instanceLocation": "#/0", + "instanceLocation": "/0", "annotations": [ { "valid": true, - "keywordLocation": "#/items/$ref/type", + "keywordLocation": "/items/$ref/type", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point/type", - "instanceLocation": "#/0" + "instanceLocation": "/0" }, { "valid": true, - "keywordLocation": "#/items/$ref/properties", + "keywordLocation": "/items/$ref/properties", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point/properties", - "instanceLocation": "#/0" + "instanceLocation": "/0" }, { "valid": true, - "keywordLocation": "#/items/$ref/required", + "keywordLocation": "/items/$ref/required", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point/required", - "instanceLocation": "#/0" + "instanceLocation": "/0" }, { "valid": true, - "keywordLocation": "#/items/$ref/additionalProperties", + "keywordLocation": "/items/$ref/additionalProperties", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point/additionalProperties", - "instanceLocation": "#/0" + "instanceLocation": "/0" } ] } @@ -66,52 +66,52 @@ }, { "valid": false, - "keywordLocation": "#/items/$ref", + "keywordLocation": "/items/$ref", "absoluteKeywordLocation": "https://example.com/polygon#/items/$ref", - "instanceLocation": "#/1", + "instanceLocation": "/1", "errors": [ { "valid": false, - "keywordLocation": "#/items/$ref", + "keywordLocation": "/items/$ref", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point", - "instanceLocation": "#/1", + "instanceLocation": "/1", "errors": [ { "valid": true, - "keywordLocation": "#/items/$ref/type", + "keywordLocation": "/items/$ref/type", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point/type", - "instanceLocation": "#/1" + "instanceLocation": "/1" }, { "valid": true, - "keywordLocation": "#/items/$ref/properties", + "keywordLocation": "/items/$ref/properties", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point/properties", - "instanceLocation": "#/1" + "instanceLocation": "/1" }, { "valid": false, - "keywordLocation": "#/items/$ref/required", + "keywordLocation": "/items/$ref/required", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point/required", - "instanceLocation": "#/1" + "instanceLocation": "/1" }, { "valid": false, - "keywordLocation": "#/items/$ref/additionalProperties", + "keywordLocation": "/items/$ref/additionalProperties", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point/additionalProperties", - "instanceLocation": "#/1", + "instanceLocation": "/1", "errors": [ { "valid": false, - "keywordLocation": "#/items/$ref/additionalProperties", + "keywordLocation": "/items/$ref/additionalProperties", "absoluteKeywordLocation": "https://example.com/polygon#/$defs/point/additionalProperties", - "instanceLocation": "#/1/z" + "instanceLocation": "/1/z" } ] } @@ -123,8 +123,8 @@ }, { "valid": false, - "keywordLocation": "#/minItems", - "instanceLocation": "#" + "keywordLocation": "/minItems", + "instanceLocation": "" } ] } From 8c6ab0ecee8dc799e90350be9f5a2c932f85956a Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Fri, 4 Sep 2020 21:12:16 -0700 Subject: [PATCH 172/780] Add clarification about "adjacent keywords" --- jsonschema-core.xml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 1c2ac6c4..97fcc087 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -304,6 +304,9 @@ A JSON Schema MUST be an object or a boolean. + + Keywords within the same schema object are referred to as adjacent keywords. +
Object properties that are applied to the instance are called keywords, @@ -674,7 +677,8 @@
Keyword behavior MAY be defined in terms of the annotation results - of subschemas and/or adjacent keywords. + of subschemas and/or adjacent keywords + (keywords within the same schema object) and their subschemas. Such keywords MUST NOT result in a circular dependency. Keywords MAY modify their behavior based on the presence or absence of another keyword in the same From 96ff071ecf43feae9ddcc952a7e1a58778634c44 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 5 Sep 2020 11:31:01 -0700 Subject: [PATCH 173/780] Move "unevaluated*" into a separate vocabulary This change just moves things to the right new section, which includes some vocabulary section boilerplate. Further changes will modify the contents of the moved sections appropriately. --- jsonschema-core.xml | 214 ++++++++++++++++++++++++-------------------- 1 file changed, 118 insertions(+), 96 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 97fcc087..5d60669d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2350,52 +2350,6 @@
-
- - The value of "unevaluatedItems" MUST be a valid JSON Schema. - - - The behavior of this keyword depends on the annotation results of - adjacent keywords that apply to the instance location being validated. - Specifically, the annotations from "prefixItems", "items", and "contains", - which can come from those keywords when they are adjacent to the - "unevaluatedItems" keyword. Those two annotations, as well as - "unevaluatedItems", can also result from any and all adjacent - in-place applicator keywords. - This includes but is not limited to the in-place applicators - defined in this document. - - - If no relevant annotations are present, the "unevaluatedItems" - subschema MUST be applied to all locations in the array. - If a boolean true value is present from any of the relevant annotations, - "unevaluatedItems" MUST be ignored. Otherwise, the subschema - MUST be applied to any index greater than the largest annotation - value for "prefixItems", which does not appear in any annotation - value for "contains". - - - This means that "prefixItems", "items", "contains", and all in-place - applicators MUST be evaluated before this keyword can be evaluated. - Authors of extension keywords MUST NOT define an in-place applicator - that would need to be evaluated before this keyword. - - - If the "unevaluatedItems" subschema is applied to any - positions within the instance array, it produces an - annotation result of boolean true, analogous to the - behavior of "items". - - - Omitting this keyword has the same assertion behavior as - an empty schema. - - - Implementations that do not collect annotations MUST raise an error - upon encountering this keyword. - -
-
The value of this keyword MUST be a valid JSON Schema. @@ -2503,56 +2457,6 @@
-
- - The value of "unevaluatedProperties" MUST be a valid JSON Schema. - - - The behavior of this keyword depends on the annotation results of - adjacent keywords that apply to the instance location being validated. - Specifically, the annotations from "properties", "patternProperties", - and "additionalProperties", which can come from those keywords when - they are adjacent to the "unevaluatedProperties" keyword. Those - three annotations, as well as "unevaluatedProperties", can also - result from any and all adjacent - in-place applicator keywords. - This includes but is not limited to the in-place applicators - defined in this document. - - - Validation with "unevaluatedProperties" applies only to the child - values of instance names that do not appear in the "properties", - "patternProperties", "additionalProperties", or - "unevaluatedProperties" annotation results that apply to the - instance location being validated. - - - For all such properties, validation succeeds if the child instance - validates against the "unevaluatedProperties" schema. - - - This means that "properties", "patternProperties", "additionalProperties", - and all in-place applicators MUST be evaluated before this keyword can - be evaluated. Authors of extension keywords MUST NOT define an in-place - applicator that would need to be evaluated before this keyword. - - - The annotation result of this keyword is the set of instance - property names validated by this keyword's subschema. - Annotation results for "unevaluatedProperties" keywords from - multiple schemas applied to the same instance location are combined - by taking the union of the sets. - - - Omitting this keyword has the same assertion behavior as - an empty schema. - - - Implementations that do not collect annotations MUST raise an error - upon encountering this keyword. - -
-
The value of "propertyNames" MUST be a valid JSON Schema. @@ -2570,6 +2474,124 @@
+
+ + Meta-schemas that do not use "$vocabulary" SHOULD be considered to + require this vocabulary as if its URI were present with a value of true. + + + The current URI for this vocabulary, known as the Unevaluated Applicator + vocabulary, is: + <https://json-schema.org/draft/2019-09/vocab/unevaluated>. + + + The current URI for the corresponding meta-schema is: + . + + + Updated vocabulary and meta-schema URIs MAY be published between + specification drafts in order to correct errors. Implementations + SHOULD consider URIs dated after this specification draft and + before the next to indicate the same syntax and semantics + as those listed here. + +
+ + The value of "unevaluatedItems" MUST be a valid JSON Schema. + + + The behavior of this keyword depends on the annotation results of + adjacent keywords that apply to the instance location being validated. + Specifically, the annotations from "prefixItems", "items", and "contains", + which can come from those keywords when they are adjacent to the + "unevaluatedItems" keyword. Those two annotations, as well as + "unevaluatedItems", can also result from any and all adjacent + in-place applicator keywords. + This includes but is not limited to the in-place applicators + defined in this document. + + + If no relevant annotations are present, the "unevaluatedItems" + subschema MUST be applied to all locations in the array. + If a boolean true value is present from any of the relevant annotations, + "unevaluatedItems" MUST be ignored. Otherwise, the subschema + MUST be applied to any index greater than the largest annotation + value for "prefixItems", which does not appear in any annotation + value for "contains". + + + This means that "prefixItems", "items", "contains", and all in-place + applicators MUST be evaluated before this keyword can be evaluated. + Authors of extension keywords MUST NOT define an in-place applicator + that would need to be evaluated before this keyword. + + + If the "unevaluatedItems" subschema is applied to any + positions within the instance array, it produces an + annotation result of boolean true, analogous to the + behavior of "items". + + + Omitting this keyword has the same assertion behavior as + an empty schema. + + + Implementations that do not collect annotations MUST raise an error + upon encountering this keyword. + +
+ +
+ + The value of "unevaluatedProperties" MUST be a valid JSON Schema. + + + The behavior of this keyword depends on the annotation results of + adjacent keywords that apply to the instance location being validated. + Specifically, the annotations from "properties", "patternProperties", + and "additionalProperties", which can come from those keywords when + they are adjacent to the "unevaluatedProperties" keyword. Those + three annotations, as well as "unevaluatedProperties", can also + result from any and all adjacent + in-place applicator keywords. + This includes but is not limited to the in-place applicators + defined in this document. + + + Validation with "unevaluatedProperties" applies only to the child + values of instance names that do not appear in the "properties", + "patternProperties", "additionalProperties", or + "unevaluatedProperties" annotation results that apply to the + instance location being validated. + + + For all such properties, validation succeeds if the child instance + validates against the "unevaluatedProperties" schema. + + + This means that "properties", "patternProperties", "additionalProperties", + and all in-place applicators MUST be evaluated before this keyword can + be evaluated. Authors of extension keywords MUST NOT define an in-place + applicator that would need to be evaluated before this keyword. + + + The annotation result of this keyword is the set of instance + property names validated by this keyword's subschema. + Annotation results for "unevaluatedProperties" keywords from + multiple schemas applied to the same instance location are combined + by taking the union of the sets. + + + Omitting this keyword has the same assertion behavior as + an empty schema. + + + Implementations that do not collect annotations MUST raise an error + upon encountering this keyword. + +
+
+
JSON Schema is defined to be platform-independent. As such, to increase compatibility From 917f22cc2072ac5d2db31895c7cc7799dc2e76c8 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 5 Sep 2020 15:34:26 -0700 Subject: [PATCH 174/780] Keyword support now strictly by vocabulary No longer need exceptional case for individual keywords that require annotation collection. --- jsonschema-core.xml | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 5d60669d..738e65f2 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -704,15 +704,18 @@ Because annotation collection can add significant cost in terms of both computation and memory, implementations MAY opt out of this feature. - Keywords known to an implementation to have assertion or applicator behavior - that depend on annotation results MUST then be treated as errors, unless - an alternate implementation producing the same behavior is available. - Keywords of this sort SHOULD describe reasonable alternate approaches - when appropriate. This approach is demonstrated by the + Keywords that are specified in terms of collected annotations SHOULD + describe reasonable alternate approaches when appropriate. + This approach is demonstrated by the "" and "" keywords in this document. + + Note that when no such alternate approach is possible for a keyword, + implementations that do not support annotation collections will not + be able to support those keywords or vocabularies that contain them. +
@@ -2535,10 +2538,6 @@ Omitting this keyword has the same assertion behavior as an empty schema. - - Implementations that do not collect annotations MUST raise an error - upon encountering this keyword. -
@@ -2585,10 +2584,6 @@ Omitting this keyword has the same assertion behavior as an empty schema. - - Implementations that do not collect annotations MUST raise an error - upon encountering this keyword. -
From ef9279d761132264b7a86e05c513ca659391b32b Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 5 Sep 2020 17:04:12 -0700 Subject: [PATCH 175/780] Add intro material to unevaluated applicator vocab This attempts to address various points of confusion noted in feedback on the most recent draft. --- jsonschema-core.xml | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 738e65f2..06155653 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2478,6 +2478,28 @@
+ + The purpose of these keywords is to enable schema authors to apply + subschemas to array items or object properties that have not been + successfully evaluated against any dynamic-scope subschema of any + adjacent keywords. + + + These instance items or properties may have been unsuccessfully evaluated + against one or more adjacent keyword subschemas, such as when an assertion + in a branch of an "anyOf" fails. Such failed evaluations are not considered + to contribute to whether or not the item or property has been evaluated. + Only successful evaluations are considered. + + + Recall that adjacent keywords are keywords within the same schema object, + and that the dynamic-scope subschemas include reference targets as well as + lexical subschemas. + + + The behavior of these keywords depend on the annotation results of + adjacent keywords that apply to the instance location being validated. + Meta-schemas that do not use "$vocabulary" SHOULD be considered to require this vocabulary as if its URI were present with a value of true. From dc2352bc99169aabbf6fa5e655eb569dc088003b Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 5 Sep 2020 18:35:40 -0700 Subject: [PATCH 176/780] Update meta-schemas for unevaluated vocab Leaving them as 2019-09 for now as we'll update that all at once. --- hyper-schema.json | 1 + meta/applicator.json | 2 -- meta/unevaluated.json | 15 +++++++++++++++ schema.json | 1 + 4 files changed, 17 insertions(+), 2 deletions(-) create mode 100644 meta/unevaluated.json diff --git a/hyper-schema.json b/hyper-schema.json index 484af6c5..74c6bec7 100644 --- a/hyper-schema.json +++ b/hyper-schema.json @@ -4,6 +4,7 @@ "$vocabulary": { "https://json-schema.org/draft/2019-09/vocab/core": true, "https://json-schema.org/draft/2019-09/vocab/applicator": true, + "https://json-schema.org/draft/2019-09/vocab/unevaluated": true, "https://json-schema.org/draft/2019-09/vocab/validation": true, "https://json-schema.org/draft/2019-09/vocab/meta-data": true, "https://json-schema.org/draft/2019-09/vocab/format": false, diff --git a/meta/applicator.json b/meta/applicator.json index 64af5792..019fb3a1 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -11,10 +11,8 @@ "properties": { "prefixItems": { "$ref": "#/$defs/schemaArray" }, "items": { "$dynamicRef": "#meta" }, - "unevaluatedItems": { "$dynamicRef": "#meta" }, "contains": { "$dynamicRef": "#meta" }, "additionalProperties": { "$dynamicRef": "#meta" }, - "unevaluatedProperties": { "$dynamicRef": "#meta" }, "properties": { "type": "object", "additionalProperties": { "$dynamicRef": "#meta" }, diff --git a/meta/unevaluated.json b/meta/unevaluated.json new file mode 100644 index 00000000..e973bd29 --- /dev/null +++ b/meta/unevaluated.json @@ -0,0 +1,15 @@ +{ + "$schema": "https://json-schema.org/draft/2019-09/schema", + "$id": "https://json-schema.org/draft/2019-09/meta/unevaluated", + "$vocabulary": { + "https://json-schema.org/draft/2019-09/vocab/unevaluated": true + }, + "$dynamicAnchor": "meta", + + "title": "Unevaluated applicator vocabulary meta-schema", + "type": ["object", "boolean"], + "properties": { + "unevaluatedItems": { "$dynamicRef": "#meta" }, + "unevaluatedProperties": { "$dynamicRef": "#meta" } + } +} diff --git a/schema.json b/schema.json index 4d4e8782..0544997c 100644 --- a/schema.json +++ b/schema.json @@ -4,6 +4,7 @@ "$vocabulary": { "https://json-schema.org/draft/2019-09/vocab/core": true, "https://json-schema.org/draft/2019-09/vocab/applicator": true, + "https://json-schema.org/draft/2019-09/vocab/unevaluated": true, "https://json-schema.org/draft/2019-09/vocab/validation": true, "https://json-schema.org/draft/2019-09/vocab/meta-data": true, "https://json-schema.org/draft/2019-09/vocab/format": false, From 64ca2b9b3af8478546563e8c69433b6edb11e0af Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 5 Sep 2020 20:07:32 -0700 Subject: [PATCH 177/780] Clarify how "deprecated" works w/arrays & objects --- jsonschema-validation.xml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 4f329b42..58165006 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1083,7 +1083,7 @@ "contentSchema": { "type": "array", "minItems": 2, - "items": [ + "prefixItems": [ { "const": { "typ": "JWT", @@ -1177,10 +1177,10 @@ the entire resource being described MAY be removed in the future. - When the "deprecated" keyword is applied to an item in an array by means of - "items", if "items" is a single schema, the deprecation relates to the whole - array, while if "items" is an array of schemas, the deprecation relates to - the corresponding item according to the subschemas position. + The "deprecated" keyword applies to each instance location to which the + schema object containing the keyword successfully applies. This can + result in scenarios where every array item or object property + is deprecated even though the containing array or object is not. Omitting this keyword has the same behavior as a value of false. From fcda424e62dab821aee27bbe3190e84504f43f42 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 5 Sep 2020 20:16:59 -0700 Subject: [PATCH 178/780] Initial base URI for embedded objects. This is to handle the case of schema objects embedded in documents such as OAS documents, particularly when the object is not an embedded schema resource. This holds when the object is a schema resource as well, but in that case the base URI is immediately overridden by "$id". --- jsonschema-core.xml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 1c2ac6c4..a15a1d5d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1606,6 +1606,11 @@ RFC 3986 Section 5.1.4. It is RECOMMENDED that implementations document any default base URI that they assume. + + If a schema object is embedded in a document of another media type, then + the initial base URI is determined according to the rules of that + media type. + Unless the "$id" keyword described in the next section is present in the root schema, this base URI SHOULD be considered the canonical URI of the From 3d7454a909580c60df2c574a49920d149ee11fb6 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 5 Sep 2020 20:32:14 -0700 Subject: [PATCH 179/780] Fix ambuguity in RFC 3339 reference. Don't say "that section" when we referenced two sections. --- jsonschema-validation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 4f329b42..1cfe6e2e 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -732,7 +732,7 @@ Implementations MAY support additional attributes using the other - production names defined in that section. If "full-date" or "full-time" + production names defined anywhere in that RFC. If "full-date" or "full-time" are implemented, the corresponding short form ("date" or "time" respectively) MUST be implemented, and MUST behave identically. Implementations SHOULD NOT define extension attributes From 8a0f3f328c992f072ac0c135b1494a644b52e81a Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sun, 6 Sep 2020 21:48:51 -0700 Subject: [PATCH 180/780] Fix CDATA indentation. --- jsonschema-core.xml | 46 ++++++++++++++++++++++----------------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 62c0c84b..47522d58 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1692,18 +1692,18 @@ @@ -1764,11 +1764,11 @@ @@ -1787,15 +1787,15 @@ From f2c130c9d12101e90cbb2a163910ad3649c6a587 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sun, 6 Sep 2020 21:49:36 -0700 Subject: [PATCH 181/780] Fix category number --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 47522d58..0fd9b2af 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -314,7 +314,7 @@ Object properties that are applied to the instance are called keywords, or schema keywords. Broadly speaking, keywords fall into one - of four categories: + of five categories: control schema identification through setting the schema's From 799ecc673c87808f321905e31bf09b2644eafa26 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 16 Sep 2020 10:26:27 -0700 Subject: [PATCH 182/780] Fix "$id" that should have been "$anchor" Looks like we missed one, h/t jimblackler. Also fix wording as the value of "$anchor" is not a URI reference. --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0fd9b2af..71ee47d8 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1710,8 +1710,8 @@ When an implementation encounters the <#/$defs/single> schema, - it resolves the "$id" URI reference against the current base URI to form - <https://example.net/root.json#item>. + it resolves the "$anchor" value as a fragment name against the current + base URI to form <https://example.net/root.json#item>. When an implementation then looks inside the <#/items> schema, it From 336789f17bff2b45a071fe58b7e51a0ab263854e Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 16 Sep 2020 10:47:57 -0700 Subject: [PATCH 183/780] Move def of "adjacent keywords" to correct section Not sure why I put this before the section defining the concept of "keywords", clearly it belongs in that section. --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 06155653..3dbc7ea5 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -304,9 +304,6 @@ A JSON Schema MUST be an object or a boolean. - - Keywords within the same schema object are referred to as adjacent keywords. -
Object properties that are applied to the instance are called keywords, @@ -339,6 +336,9 @@ results. They should not define additional constraints independent of their subschemas. + + Keywords within the same schema object are referred to as adjacent keywords. + Extension keywords, meaning those defined outside of this document and its companions, are free to define other behaviors as well. From 4fb2af1d50c2d8fe8b1278ef38d2dbf9a7946fe6 Mon Sep 17 00:00:00 2001 From: about-code <6525873+about-code@users.noreply.github.com> Date: Sat, 26 Sep 2020 13:00:32 +0200 Subject: [PATCH 184/780] Fix 988 (What is the tag for the new 2019-09 draft?) --- jsonschema-validation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 0b28869e..722c502c 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -178,7 +178,7 @@
The current URI for the default JSON Schema meta-schema is - . + . For schema author convenience, this meta-schema describes all vocabularies defined in this specification and the JSON Schema Core specification, as well as two former keywords which are reserved for a transitional period. From b08f1fcefd0ce92da84188aae1e350bbb1b15192 Mon Sep 17 00:00:00 2001 From: about-code <6525873+about-code@users.noreply.github.com> Date: Sat, 26 Sep 2020 13:09:09 +0200 Subject: [PATCH 185/780] Fix inconsistencies with use of empty URI fragment --- jsonschema-core.xml | 4 ++-- jsonschema-hyperschema.xml | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index de3cda14..91c1f228 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1916,7 +1916,7 @@
; rel="describedby" + Link: ; rel="describedby" ]]>
@@ -1962,7 +1962,7 @@ diff --git a/jsonschema-hyperschema.xml b/jsonschema-hyperschema.xml index f3daa676..78997685 100644 --- a/jsonschema-hyperschema.xml +++ b/jsonschema-hyperschema.xml @@ -282,7 +282,7 @@
The current URI for the JSON Hyper-Schema meta-schema is - . + . The current URI for this vocabulary, known as the Hyper-Schema vocabulary, is: @@ -299,7 +299,7 @@ Schema, and use of this format can be declared by referencing the normative link description schema as the schema for the data structure that uses the links. The URI of the normative link description schema is: - . + . JSON Hyper-Schema implementations are free to provide output in any format. @@ -310,7 +310,7 @@ It is RECOMMENDED that implementations be capable of producing output in this format to facilitated testing. The URI of the JSON Schema describing the recommended output format is - . + . Updated vocabulary and meta-schema URIs MAY be published between From 6e12ea846b2367bce2412fe7dff198f1ff25c3fb Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 5 Sep 2020 20:37:37 -0700 Subject: [PATCH 186/780] Put "dialect" in the spec. This gets the term introduced. I am leaving out hyper-schema for now as we don't plan to update it soon. --- jsonschema-core.xml | 5 ++++- jsonschema-validation.xml | 5 +++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 6288e746..df45d05e 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -146,6 +146,7 @@ To facilitate re-use, keywords can be organized into vocabularies. A vocabulary consists of a list of keywords, together with their syntax and semantics. + A set of vocabularies identified by a meta-schema is known as a dialect. JSON Schema can be extended either by defining additional vocabularies, @@ -173,7 +174,9 @@ Further vocabularies for purposes such as structural validation or - hypermedia annotation are defined in other documents. + hypermedia annotation are defined in other documents. These other + documents each define a dialect collecting the standard sets of + vocabularies needed to write schemas for that document's purpose.
diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 722c502c..a8026d89 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -177,9 +177,10 @@
- The current URI for the default JSON Schema meta-schema is + The current URI for the default JSON Schema dialect meta-schema is . - For schema author convenience, this meta-schema describes all vocabularies + For schema author convenience, this meta-schema describes a dialect + consisting of all vocabularies defined in this specification and the JSON Schema Core specification, as well as two former keywords which are reserved for a transitional period. Individual vocabulary and vocabulary meta-schema URIs are given for From efe6664f9cdf9a1105eda798bebab9bbac935d78 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 5 Sep 2020 21:07:52 -0700 Subject: [PATCH 187/780] Remove special case handling of annotation values The approach of annotation keywords specifying combination rules is not really compatible with the output format approach. It is also a source of uncertainty in how to use and specify annotations. This removes the concept. Note that "readOnly", "writeOnly", and "deprecated" still advise applications on how to handle multiple values. However, the wording is purely in terms of application handling and not in terms of aggregating the values, so no change to the validation spec is necessary. --- jsonschema-core.xml | 25 ++++++++----------------- 1 file changed, 8 insertions(+), 17 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 6288e746..3a10d124 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -770,7 +770,9 @@ Annotation results are - combined according to the rules specified by each annotation keyword. + preserved along with the instance location and the location of + the schema keyword, so that applications can decide how to + interpret multiple values.
@@ -865,8 +867,9 @@ Annotations are attached to specific locations in an instance. Since many subschemas can be applied to any single - location, annotation keywords need to specify any unusual handling of - multiple applicable occurrences of the keyword with different values. + location, applications may need to decide how to handle differing + annotation values being attached to the same instance location by + the same schema keyword in different schema objects. Unlike assertion results, annotation data can take a wide variety of forms, @@ -919,14 +922,6 @@ - - If the same keyword attaches values from multiple schema locations - to the same instance location, and the annotation defines a process - for combining such values, then the combined value MUST also be associated - with the instance location. The output formats - described in this specification that include annotation information - meet this requirement. -
Applications MAY make decisions on which of multiple annotation values @@ -986,8 +981,7 @@ In this example, both Feature A and Feature B make use of the re-usable "enabledToggle" schema. That schema uses the "title", "description", - and "default" annotations, none of which define special behavior for - handling multiple values. Therefore the application has to decide how + and "default" annotations. Therefore the application has to decide how to handle the additional "default" value for Feature A, and the additional "description" value for Feature B. @@ -1061,10 +1055,7 @@ In addition to possibly defining annotation results of their own, applicator keywords aggregate the annotations collected in their - subschema(s) or referenced schema(s). The rules for aggregating - annotation values are defined by each annotation keyword, and are - not directly affected by the logic used for combining assertion - results. + subschema(s) or referenced schema(s).
From 4a1035137f90ffff425bea257f48858dcd0d301c Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 26 Sep 2020 13:25:23 -0700 Subject: [PATCH 188/780] Clarify what "absolute" means for kwd loc It is like absolute filesystem paths, not like absolute-URI from RFC 3986. In fact, an absolute keyword location can never be an RFC 3986 absolute-URI because a fragment must always be present to identify the keyword. --- jsonschema-core.xml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 6288e746..999009e8 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2705,11 +2705,18 @@
The absolute, dereferenced location of the validating keyword. The value MUST - be expressed as an absolute URI using the canonical URI of the relevant + be expressed as a full URI using the canonical URI of the relevant schema object, and it MUST NOT include by-reference applicators such as "$ref" or "$dynamicRef" as non-terminal path components. It MAY end in such keywords if the error or annotation is for that keyword, such as an unresolvable reference. + + Note that "absolute" here is in the sense of "absolute filesystem path" + (meaning the complete location) rather than the "absolute-URI" + terminology from RFC 3986 (meaning with scheme but without fragment). + Keyword absolute locations will always have a fragment in order to + identify the keyword. +
From 630d7a8438691352a1d24c644d8c68932d263e98 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 26 Sep 2020 13:39:49 -0700 Subject: [PATCH 189/780] Remove trailing whitespace --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 6288e746..09e15d04 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2377,8 +2377,8 @@ This keyword produces an annotation value which is an array of - the indexes to which this keyword validates successfully when applying - its subschema, in ascending order. The value MAY be a boolean true if the + the indexes to which this keyword validates successfully when applying + its subschema, in ascending order. The value MAY be a boolean true if the subschema validated successfully when applied to every index of the instance.
From cad29ac533d73d92fa0a2bd28809faafc6b57c9a Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 5 Sep 2020 21:22:23 -0700 Subject: [PATCH 190/780] Collect unknown keywords as annotations And try to avoid memory exhaustion attacks, which were possible even with out this change but potentially more likely to happen by accident with it (e.g. unrecognized applicator with a very large subschema). --- jsonschema-core.xml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 6288e746..946991a7 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -351,7 +351,7 @@ A JSON Schema MAY contain properties which are not schema keywords. - Unknown keywords SHOULD be ignored. + Unknown keywords SHOULD be treated as annotations. An empty schema is a JSON Schema with no properties, or only unknown @@ -3090,6 +3090,11 @@ https://example.com/schemas/common#/$defs/count/minimum system resources. Validators MUST NOT fall into an infinite loop. + + A malicious party could cause an implementation to repeatedly collect a copy + of a very large value as an annotation. Implementations SHOULD guard against + excessive consumption of system resources in such a scenario. + Servers MUST ensure that malicious parties can't change the functionality of existing schemas by uploading a schema with a pre-existing or very similar "$id". From b8dc7831c07500de45b719f90c14660b70dbaf56 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sat, 26 Sep 2020 14:34:29 -0700 Subject: [PATCH 191/780] More collect unknown keywords as annotations I seem to have missed the majority of references in the previous commit. --- jsonschema-core.xml | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 946991a7..2565169a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -150,9 +150,9 @@ JSON Schema can be extended either by defining additional vocabularies, or less formally by defining additional keywords outside of any vocabulary. - Unrecognized individual keywords are ignored, while the behavior with respect - to an unrecognized vocabulary can be controlled when declaring which - vocabularies are in use. + Unrecognized individual keywords simply have their values collected as annotations, + while the behavior with respect to an unrecognized vocabulary can be controlled + when declaring which vocabularies are in use. This document defines a core vocabulary that MUST be supported by any @@ -351,7 +351,8 @@ A JSON Schema MAY contain properties which are not schema keywords. - Unknown keywords SHOULD be treated as annotations. + Unknown keywords SHOULD be treated as annotations, where the value + of the keyword is the value of the annotation. An empty schema is a JSON Schema with no properties, or only unknown @@ -575,7 +576,8 @@ by any entity. Save for explicit agreement, schema authors SHALL NOT expect these additional keywords and vocabularies to be supported by implementations that do not explicitly document such support. - Implementations SHOULD ignore keywords they do not support. + Implementations SHOULD treat keywords they do not support as annotations, + where the value of the keyword is the value of the annotation. Implementations MAY provide the ability to register or load handlers @@ -1237,7 +1239,8 @@ Per , unrecognized - keywords SHOULD be ignored. This remains the case for keywords defined + keywords SHOULD be treated as annotations. + This remains the case for keywords defined by unrecognized vocabularies. It is not currently possible to distinguish between unrecognized keywords that are defined in vocabularies from those that are not part of any vocabulary. From 8fc196c8b587a163115a793482c8b37bfb4288d2 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Sun, 27 Sep 2020 18:53:07 -0700 Subject: [PATCH 192/780] The value of prefixItems MUST be non-empty A prefix of zero length makes no sense. --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index c52d4b75..93638219 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2303,7 +2303,7 @@
- The value of "prefixItems" MUST be an array of valid JSON Schemas. + The value of "prefixItems" MUST be a non-empty array of valid JSON Schemas. Validation succeeds if each element of the instance validates From fd25a79d93d6c718437eaa0eb9e7f7f6aab5c382 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 1 Oct 2020 14:41:53 -0700 Subject: [PATCH 193/780] Update output/schema.json Make anyOf (instead of oneOf) consistent. --- output/schema.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/output/schema.json b/output/schema.json index e3824ffc..97beaeee 100644 --- a/output/schema.json +++ b/output/schema.json @@ -44,7 +44,7 @@ } }, "then": { - "oneOf": [ + "anyOf": [ { "required": [ "error" ] }, From 2a788d869bbe0c0c72b1a222f87a0c03145eb677 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Sat, 29 Aug 2020 17:02:26 +0100 Subject: [PATCH 194/780] First attempt to resolve #936 Define Compound Schema Document and associated concerns --- jsonschema-core.xml | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 18ced482..c0c8f86b 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1845,6 +1845,48 @@
+
+ + A Compound Schema Document is defined as JSON document (sometimes called a "dereferenced" or + "bundled" schema) which has multiple embedded JSON Schema Resources bundled into the same + document to ease transportation. + + + Each embedded Schema Resource MUST be treated as an individual Schema Resource, following standard + schema loading and processing requirements, including determining voacbulary support. + +
+ + A Compound Schema Document is created by replacing references (such as "$ref") with an + embedded version of the referenced Schema Resource. + + + Each embedded JSON Schema Resource (and the document's root) MUST identify itself + with an absolute URI using the "$id" keyword, and SHOULD make use of the "$schema" + keyword to identify the dialect it is using, in the root of the schema resource. + + + When a reference applicator is dereferenced as part of the bundling process, the Schema Resource + MUST NOT be embedded by replacing the schema object from which it was referenced, or by wrapping + in other applicator keywords. In stead, a bundled Schema Resource MUST be located in `$defs`, + where the key is the `$id` of the Schema Resource, which MUST then be referenced using `$ref`. + +
+
+ + Given a Compound Schema Document may have embedded resources which idenfiy as using different + dialects, it is NOT RECOMMENDED that these documents are validated by applying a meta-schema + to the Compound Schema Document as an instance. It is RECOMMENDED that an alternate + validation process be provided in order to validate Compound Schema Documents + (such as a differnet function). + + + A Compound Schema Document in which all embedded resources idenfity as using the same + dialect MAY be validated by applying the appropriate meta-schema. + +
+
+
From 67c00d2e838407df8eb6757773aa496a4898b443 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Sun, 27 Sep 2020 16:09:28 +0100 Subject: [PATCH 195/780] Update jsonschema-core.xml Fix typo Co-authored-by: Karen Etheridge --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index c0c8f86b..4d63e2a3 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1868,7 +1868,7 @@ When a reference applicator is dereferenced as part of the bundling process, the Schema Resource MUST NOT be embedded by replacing the schema object from which it was referenced, or by wrapping - in other applicator keywords. In stead, a bundled Schema Resource MUST be located in `$defs`, + in other applicator keywords. Instead, a bundled Schema Resource MUST be located in `$defs`, where the key is the `$id` of the Schema Resource, which MUST then be referenced using `$ref`.
From 2dc975a94d8480a1e2f7a55448dbe035fde8fa33 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Sun, 27 Sep 2020 16:12:57 +0100 Subject: [PATCH 196/780] Update jsonschema-core.xml Fix typo Co-authored-by: Karen Etheridge --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 4d63e2a3..e363b187 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1878,7 +1878,7 @@ dialects, it is NOT RECOMMENDED that these documents are validated by applying a meta-schema to the Compound Schema Document as an instance. It is RECOMMENDED that an alternate validation process be provided in order to validate Compound Schema Documents - (such as a differnet function). + (such as a different function). A Compound Schema Document in which all embedded resources idenfity as using the same From d3f6274b0a20c3c05e1b333a4cda6406d9797645 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Sun, 27 Sep 2020 22:55:27 +0100 Subject: [PATCH 197/780] Use correct termonology 'by-reference applicator' --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e363b187..97f4a1b8 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1866,7 +1866,7 @@ keyword to identify the dialect it is using, in the root of the schema resource. - When a reference applicator is dereferenced as part of the bundling process, the Schema Resource + When a by-reference applicator is dereferenced as part of the bundling process, the Schema Resource MUST NOT be embedded by replacing the schema object from which it was referenced, or by wrapping in other applicator keywords. Instead, a bundled Schema Resource MUST be located in `$defs`, where the key is the `$id` of the Schema Resource, which MUST then be referenced using `$ref`. From ac9ec4fa096a40c4dd31d953e310d04a84c91d9e Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Sun, 27 Sep 2020 22:59:37 +0100 Subject: [PATCH 198/780] Don't mention 'derferenced' schemas in the section related to compound document. The phrase has a specific meaning --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 97f4a1b8..437734e4 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1847,9 +1847,9 @@
- A Compound Schema Document is defined as JSON document (sometimes called a "dereferenced" or - "bundled" schema) which has multiple embedded JSON Schema Resources bundled into the same - document to ease transportation. + A Compound Schema Document is defined as JSON document (sometimes called a "bundled" schema) + which has multiple embedded JSON Schema Resources bundled into the same document to + ease transportation. Each embedded Schema Resource MUST be treated as an individual Schema Resource, following standard From 3c99506743f36d929de219119cdb1b6bff4e70ba Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 28 Sep 2020 23:20:56 +0100 Subject: [PATCH 199/780] Rephrase definition of Compound Schema Document to only be about transcluding external Schema Resources --- jsonschema-core.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 437734e4..01bbe3c8 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1857,8 +1857,9 @@
- A Compound Schema Document is created by replacing references (such as "$ref") with an - embedded version of the referenced Schema Resource. + A Compound Schema Document is created by taking references (such as "$ref") + to an external Schema Resource and embedding the referenced Schema Resources + within the referreing document. Each embedded JSON Schema Resource (and the document's root) MUST identify itself From 7beb355aa95e0cd0a976c84cda7db7af44644e9d Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 28 Sep 2020 23:39:46 +0100 Subject: [PATCH 200/780] Move some content of use of schema within Compound Document resources, to said section --- jsonschema-core.xml | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 01bbe3c8..fe942a42 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1180,16 +1180,6 @@ It MUST NOT appear in non-resource root schema objects. If absent from the document root schema, the resulting behavior is implementation-defined. - - If multiple schema resources are present in a single document, then - schema resources which do not have a "$schema" keyword in their root - schema object MUST be processed as if "$schema" were present with the - same value as for the immediately enclosing resource. - - - Embedded schema resources MAY specify different "$schema" values from their - enclosing resource, as any schema that can be referenced can also be embedded. - Values for this property are defined elsewhere in this and other documents, and by other parties. @@ -1873,6 +1863,19 @@ where the key is the `$id` of the Schema Resource, which MUST then be referenced using `$ref`.
+
+ + In addition to the rules defining the use of the "$schema" keyword , + if multiple schema resources are present in a single document, then + schema resources which do not have a "$schema" keyword in their root + schema object MUST be processed as if "$schema" were present with the + same value as for the immediately enclosing resource. + + + Embedded schema resources MAY specify different "$schema" values from their + enclosing resource, as any schema that can be referenced can also be embedded. + +
Given a Compound Schema Document may have embedded resources which idenfiy as using different From c44829d911e9543f2b415cd95d79a092e59f27be Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 28 Sep 2020 23:49:27 +0100 Subject: [PATCH 201/780] Rephrase recomended validation process for processing a schema document, as it is possible to identify embedded schema resources if you know it's a schema as opposed to just an instance. --- jsonschema-core.xml | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index fe942a42..0430bbc1 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1865,7 +1865,8 @@
- In addition to the rules defining the use of the "$schema" keyword , + In addition to the rules defining the use of the "$schema" keyword + , if multiple schema resources are present in a single document, then schema resources which do not have a "$schema" keyword in their root schema object MUST be processed as if "$schema" were present with the @@ -1881,8 +1882,12 @@ Given a Compound Schema Document may have embedded resources which idenfiy as using different dialects, it is NOT RECOMMENDED that these documents are validated by applying a meta-schema to the Compound Schema Document as an instance. It is RECOMMENDED that an alternate - validation process be provided in order to validate Compound Schema Documents - (such as a different function). + validation process be provided in order to validate Schema Documents. + + If you know a schema is what's being validated, you can identify if the schemas + is a Compound Schema Document or not, by way of use of "$id", which identifies an + embedded resource when used not at the document's root. + A Compound Schema Document in which all embedded resources idenfity as using the same From 959fb2bd2882518f26f83e5379e1631724d2c240 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 29 Sep 2020 00:05:40 +0100 Subject: [PATCH 202/780] Fix invalid XML --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0430bbc1..fe24061a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1866,7 +1866,7 @@
In addition to the rules defining the use of the "$schema" keyword - , + , if multiple schema resources are present in a single document, then schema resources which do not have a "$schema" keyword in their root schema object MUST be processed as if "$schema" were present with the From 375cb26107e6f9d219ee0f6686615d95c18126e2 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 29 Sep 2020 22:32:05 +0100 Subject: [PATCH 203/780] Fix bad reference --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index fe24061a..a60f27ad 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1159,7 +1159,7 @@ Meta-schema authoring is an advanced usage of JSON Schema, so the design of meta-schema features emphasizes flexibility over simplicity. -
+
The "$schema" keyword is both used as a JSON Schema feature set identifier and as the identifier of a resource which is itself a JSON Schema, which describes the @@ -1865,8 +1865,8 @@
- In addition to the rules defining the use of the "$schema" keyword - , + In addition to the rules defining the use of + the "$schema" keyword, if multiple schema resources are present in a single document, then schema resources which do not have a "$schema" keyword in their root schema object MUST be processed as if "$schema" were present with the From 08e9e60fcb0640e159b4c2dec418dc6445bf0e69 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 29 Sep 2020 22:47:47 +0100 Subject: [PATCH 204/780] Rephrase process of schema bundling to make clear that existing referenes need to change, and the of an embedded shema resource is still used as the referene string for by-reference applicator keywords. --- jsonschema-core.xml | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index a60f27ad..609644aa 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1859,8 +1859,15 @@ When a by-reference applicator is dereferenced as part of the bundling process, the Schema Resource MUST NOT be embedded by replacing the schema object from which it was referenced, or by wrapping - in other applicator keywords. Instead, a bundled Schema Resource MUST be located in `$defs`, - where the key is the `$id` of the Schema Resource, which MUST then be referenced using `$ref`. + in other applicator keywords. Instead, a bundled Schema Resource MUST be located as a value of + a "$defs" object at the containing schemas root. The key of the "$defs" for the now embedded + Schema Resource MAY be the "$id" of the bundled schema or some other form of application defined + unique identifer (such as a UUID). This key is not intended to be referenced in JSON Schema, but may + be used by an application to aid the bundling process. + + + References in the containing schema document to the previously external Schema Resources + MUST NOT be changed, and now resolve to a schema using the "$id" of an embedded Schema Resource.
From f82ee5510e3d9a41dc53d6cce0871144d2473bfe Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 6 Oct 2020 21:43:19 +0100 Subject: [PATCH 205/780] Clarify that the bundling process is not the only way to create a Compound Schema Document --- jsonschema-core.xml | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 609644aa..7def9c35 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1847,9 +1847,9 @@
- A Compound Schema Document is created by taking references (such as "$ref") - to an external Schema Resource and embedding the referenced Schema Resources - within the referreing document. + The bundling process for creating a Compound Schema Document is done by taking + references (such as "$ref") to an external Schema Resource and embedding the referenced + Schema Resources within the referreing document. Each embedded JSON Schema Resource (and the document's root) MUST identify itself @@ -1869,6 +1869,11 @@ References in the containing schema document to the previously external Schema Resources MUST NOT be changed, and now resolve to a schema using the "$id" of an embedded Schema Resource. + + While the bundling process will often be the main method for creating a Compound Schema Document, + it is also possible and expected that some will be created by hand, potentially without individual + Schema Resources existing on their own previously. +
From 6cf7022989614ac85879fa76e272bcf39b20af25 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 6 Oct 2020 21:46:36 +0100 Subject: [PATCH 206/780] Document root is only SHOULD for $id. $id requirements for document root are already covered, and shouldn't be overriden. --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 7def9c35..d2122ef9 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1852,9 +1852,9 @@ Schema Resources within the referreing document. - Each embedded JSON Schema Resource (and the document's root) MUST identify itself - with an absolute URI using the "$id" keyword, and SHOULD make use of the "$schema" - keyword to identify the dialect it is using, in the root of the schema resource. + Each embedded JSON Schema Resource MUST identify itself with an absolute URI using the "$id" keyword, + and SHOULD make use of the "$schema" keyword to identify the dialect it is using, in the root of the + schema resource. When a by-reference applicator is dereferenced as part of the bundling process, the Schema Resource From 976a6fb2e85bcacb83cb38ccf88bed63e4a8ec3a Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 6 Oct 2020 22:09:30 +0100 Subject: [PATCH 207/780] Use correct terms for bundling process of Compound Schema Documents Previously 'dereferenced' was used incorrectly. Now "bundling" is clearly defined, and MUST and MUST NOT are split for clairty. --- jsonschema-core.xml | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d2122ef9..75130b06 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1847,7 +1847,7 @@
- The bundling process for creating a Compound Schema Document is done by taking + The bundling process for creating a Compound Schema Document is defined as taking references (such as "$ref") to an external Schema Resource and embedding the referenced Schema Resources within the referreing document. @@ -1857,13 +1857,16 @@ schema resource. - When a by-reference applicator is dereferenced as part of the bundling process, the Schema Resource - MUST NOT be embedded by replacing the schema object from which it was referenced, or by wrapping - in other applicator keywords. Instead, a bundled Schema Resource MUST be located as a value of - a "$defs" object at the containing schemas root. The key of the "$defs" for the now embedded - Schema Resource MAY be the "$id" of the bundled schema or some other form of application defined - unique identifer (such as a UUID). This key is not intended to be referenced in JSON Schema, but may - be used by an application to aid the bundling process. + When the Schema Resource referenced by a by-reference applicator is bundled, the Schema Resource + MUST be located as a value of a "$defs" object at the containing schemas root. + The key of the "$defs" for the now embedded Schema Resource MAY be the "$id" of the bundled schema + or some other form of application defined unique identifer (such as a UUID). This key is not + intended to be referenced in JSON Schema, but may be used by an application to aid the + bundling process. + + + Bundled Schema Resource MUST NOT be bundled by replacing the schema object from which it was + referenced, or by wrapping the Schema Resource in other applicator keywords. References in the containing schema document to the previously external Schema Resources From 49d77b2c13d4191f012f9ae739ba51232241bb99 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 6 Oct 2020 22:10:54 +0100 Subject: [PATCH 208/780] Fix grammar --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 75130b06..36af20c0 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1858,7 +1858,7 @@ When the Schema Resource referenced by a by-reference applicator is bundled, the Schema Resource - MUST be located as a value of a "$defs" object at the containing schemas root. + MUST be located as a value of a "$defs" object at the containing schema's root. The key of the "$defs" for the now embedded Schema Resource MAY be the "$id" of the bundled schema or some other form of application defined unique identifer (such as a UUID). This key is not intended to be referenced in JSON Schema, but may be used by an application to aid the From 5d36e175ddb6f2dac5704074c222ebb15c3c6f29 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 6 Oct 2020 22:33:53 +0100 Subject: [PATCH 209/780] Small gramatical changes --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 36af20c0..25042a2c 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1888,13 +1888,13 @@ same value as for the immediately enclosing resource. - Embedded schema resources MAY specify different "$schema" values from their - enclosing resource, as any schema that can be referenced can also be embedded. + Since any schema that can be referenced can also be embedded, embedded schema resources MAY + specify different "$schema" values from their enclosing resource.
- Given a Compound Schema Document may have embedded resources which idenfiy as using different + Given that a Compound Schema Document may have embedded resources which idenfiy as using different dialects, it is NOT RECOMMENDED that these documents are validated by applying a meta-schema to the Compound Schema Document as an instance. It is RECOMMENDED that an alternate validation process be provided in order to validate Schema Documents. From 4eacfe3d03a9b7ef946d4a42269bad734ce6c62a Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 6 Oct 2020 22:52:01 +0100 Subject: [PATCH 210/780] Better specify the process of validating a Compound Schema Document --- jsonschema-core.xml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 25042a2c..99d25cdb 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1895,9 +1895,10 @@
Given that a Compound Schema Document may have embedded resources which idenfiy as using different - dialects, it is NOT RECOMMENDED that these documents are validated by applying a meta-schema + dialects, these documents SHOULD NOT be validated by applying a meta-schema to the Compound Schema Document as an instance. It is RECOMMENDED that an alternate - validation process be provided in order to validate Schema Documents. + validation process be provided in order to validate Schema Documents. Each Schema Resource + SHOULD be separately validated against its associated meta-schema. If you know a schema is what's being validated, you can identify if the schemas is a Compound Schema Document or not, by way of use of "$id", which identifies an @@ -1906,7 +1907,8 @@ A Compound Schema Document in which all embedded resources idenfity as using the same - dialect MAY be validated by applying the appropriate meta-schema. + dialec, or in which "$schema" is omitted and therefore defaults to that of the enclosing resource, + MAY be validated by applying the appropriate meta-schema.
From b27a703bf8ff2e36262f1277333e2c1dc11d7e8d Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 7 Oct 2020 13:06:13 +0100 Subject: [PATCH 211/780] Remove non-required phrasing --- jsonschema-core.xml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 99d25cdb..7e8361f1 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1880,9 +1880,7 @@
- In addition to the rules defining the use of - the "$schema" keyword, - if multiple schema resources are present in a single document, then + If multiple schema resources are present in a single document, then schema resources which do not have a "$schema" keyword in their root schema object MUST be processed as if "$schema" were present with the same value as for the immediately enclosing resource. From 1e7cd49d0112859f73e0dc5d7ff1eb5abfa03132 Mon Sep 17 00:00:00 2001 From: Relequestual Date: Mon, 10 Aug 2020 23:37:12 +0100 Subject: [PATCH 212/780] Fixes 821 Reference specific version of emca262. --- jsonschema-core.xml | 6 +++--- jsonschema-validation.xml | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 18ced482..b08cb2a6 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3221,11 +3221,11 @@ https://example.com/schemas/common#/$defs/count/minimum &RFC8259; &ldp; + target="https://www.ecma-international.org/ecma-262/5.1"> - ECMA 262 specification + ECMA-262 5.1 edition specification - + diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index a8026d89..5eb20257 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1316,11 +1316,11 @@ &RFC6901; &RFC8259; + target="https://www.ecma-international.org/ecma-262/5.1"> - ECMA 262 specification + ECMA-262 5.1 edition specification - + From 7e31d170059c1784113d4e72cc8b7f7b397eaa24 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 30 Sep 2020 23:15:37 +0100 Subject: [PATCH 213/780] Reference ECMAScript 10.0 specifically for the purposes of optional regex support --- jsonschema-core.xml | 8 ++++---- jsonschema-validation.xml | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b08cb2a6..04868e5f 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3221,11 +3221,11 @@ https://example.com/schemas/common#/$defs/count/minimum &RFC8259; &ldp; + target="https://www.ecma-international.org/ecma-262/11.0"> - ECMA-262 5.1 edition specification + ECMA-262 11.0 edition specification - + @@ -3854,7 +3854,7 @@ https://example.com/schemas/common#/$defs/count/minimum Rename $recursive* to $dynamic* $dynamicAnchor defines a fragment like $anchor $dynamic* (previously $recursive) no longer use runtime base URI determination - + Reference ecma262 11th edition for regular expression support diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 5eb20257..c3b396bc 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1316,11 +1316,11 @@ &RFC6901; &RFC8259; + target="https://www.ecma-international.org/ecma-262/11.0"> - ECMA-262 5.1 edition specification + ECMA-262 11.0 edition specification - + @@ -1434,7 +1434,7 @@ Correct email format RFC reference to 5321 instead of 5322 Clarified the set and meaning of "contentEncoding" values - + Reference ecma262 11th edition for regular expression support From d74ddb49e4177f6221f2275a0871bf415fc78b38 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 30 Sep 2020 23:22:59 +0100 Subject: [PATCH 214/780] Update ecma262 section numbers --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 04868e5f..d1a4bde6 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -545,7 +545,7 @@ Keywords MAY use regular expressions to express constraints, or constrain the instance value to be a regular expression. These regular expressions SHOULD be valid according to the regular expression - dialect described in ECMA 262, section 15.10.1. + dialect described in ECMA 262, section 21.2.1. Furthermore, given the high disparity in regular expression constructs support, From 9b96d6aa3abcbd7425b42e7440a5e8e0c8adf659 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 14 Oct 2020 11:32:51 +0100 Subject: [PATCH 215/780] Add note regarding regular expression unicode flag requirement --- jsonschema-core.xml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d1a4bde6..0370e5dc 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -547,6 +547,11 @@ These regular expressions SHOULD be valid according to the regular expression dialect described in ECMA 262, section 21.2.1. + + Regular expressions SHOULD be built with the "u" flag (or equivilent) to provide + Unicode support, or processed in such a way which provides which provides Unicode + as defined by ECMA 262. + Furthermore, given the high disparity in regular expression constructs support, schema authors SHOULD limit themselves to the following regular expression From 9f51c1996df62fe3696e9fddd95ff3ef02a64ec4 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 20 Oct 2020 21:36:05 +0100 Subject: [PATCH 216/780] Fix typos Co-authored-by: Karen Etheridge --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 7e8361f1..e82a6de5 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1843,13 +1843,13 @@ Each embedded Schema Resource MUST be treated as an individual Schema Resource, following standard - schema loading and processing requirements, including determining voacbulary support. + schema loading and processing requirements, including determining vocabulary support.
The bundling process for creating a Compound Schema Document is defined as taking references (such as "$ref") to an external Schema Resource and embedding the referenced - Schema Resources within the referreing document. + Schema Resources within the referring document. Each embedded JSON Schema Resource MUST identify itself with an absolute URI using the "$id" keyword, @@ -1892,7 +1892,7 @@
- Given that a Compound Schema Document may have embedded resources which idenfiy as using different + Given that a Compound Schema Document may have embedded resources which identify as using different dialects, these documents SHOULD NOT be validated by applying a meta-schema to the Compound Schema Document as an instance. It is RECOMMENDED that an alternate validation process be provided in order to validate Schema Documents. Each Schema Resource From 0409c724a88c07fb1abac4dbe6ced529e7eb9704 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 20 Oct 2020 22:15:03 +0100 Subject: [PATCH 217/780] Specifically mention that bundling is done in such a way so as to avoid the need to alter URIs used for referencing --- jsonschema-core.xml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e82a6de5..f5ea1388 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1849,7 +1849,9 @@ The bundling process for creating a Compound Schema Document is defined as taking references (such as "$ref") to an external Schema Resource and embedding the referenced - Schema Resources within the referring document. + Schema Resources within the referring document. Bundling is done in such a way that + all URIs (used for referencing) in the base document and any referenced/embedded + documents do not require altering. Each embedded JSON Schema Resource MUST identify itself with an absolute URI using the "$id" keyword, From 13867cdddffe5b9dfd86611bfccf70ecc6827077 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 20 Oct 2020 22:22:58 +0100 Subject: [PATCH 218/780] Specifically mention why referenes MUST NOT be changed when creating a Compound Schema Document --- jsonschema-core.xml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f5ea1388..e972f699 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1871,8 +1871,10 @@ referenced, or by wrapping the Schema Resource in other applicator keywords. - References in the containing schema document to the previously external Schema Resources - MUST NOT be changed, and now resolve to a schema using the "$id" of an embedded Schema Resource. + In order to produce identical output, references in the containing schema document to the + previously external Schema Resources MUST NOT be changed, and now resolve to a schema using the + "$id" of an embedded Schema Resource. Such identical output includes validation evaluation and URIs + or paths used in resulting annotations or errors. While the bundling process will often be the main method for creating a Compound Schema Document, From 20e1910f2306764ac009965094d9f4d6ba06c554 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Sun, 25 Oct 2020 14:28:54 +0000 Subject: [PATCH 219/780] Add Compound Schema Document to changelog --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e972f699..4cc95a71 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3924,7 +3924,7 @@ https://example.com/schemas/common#/$defs/count/minimum Rename $recursive* to $dynamic* $dynamicAnchor defines a fragment like $anchor $dynamic* (previously $recursive) no longer use runtime base URI determination - + Define Compound Schema Documents (bundle) and processing From bb9cba645c49c043da7a7e245382d7078d40d304 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 26 Oct 2020 21:18:10 +0000 Subject: [PATCH 220/780] Fix duplicated phrase --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0370e5dc..c1aa5a20 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -549,7 +549,7 @@ Regular expressions SHOULD be built with the "u" flag (or equivilent) to provide - Unicode support, or processed in such a way which provides which provides Unicode + Unicode support, or processed in such a way which provides Unicode support, as defined by ECMA 262. From 4bd029220ea4bf0282c48a79cc3fd5aad2fcca7d Mon Sep 17 00:00:00 2001 From: Mike Ralphson Date: Thu, 29 Oct 2020 17:06:04 +0000 Subject: [PATCH 221/780] Typo in jsonschema-core.xml dialec for dialect --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 4cc95a71..992ce13e 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1909,7 +1909,7 @@ A Compound Schema Document in which all embedded resources idenfity as using the same - dialec, or in which "$schema" is omitted and therefore defaults to that of the enclosing resource, + dialect, or in which "$schema" is omitted and therefore defaults to that of the enclosing resource, MAY be validated by applying the appropriate meta-schema.
From 75085c2bb89d95f51558375fbcbabc3cab58c726 Mon Sep 17 00:00:00 2001 From: Mike Ralphson Date: Fri, 30 Oct 2020 10:51:53 +0000 Subject: [PATCH 222/780] Two typos in jsonschema-core.xml "idenfity" for "identify", "unevaluted" for "unevaluated" --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 992ce13e..eb392d84 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1908,7 +1908,7 @@ - A Compound Schema Document in which all embedded resources idenfity as using the same + A Compound Schema Document in which all embedded resources identify as using the same dialect, or in which "$schema" is omitted and therefore defaults to that of the enclosing resource, MAY be validated by applying the appropriate meta-schema. @@ -3726,7 +3726,7 @@ https://example.com/schemas/common#/$defs/count/minimum are particularly complex to implement. This does not change the semantics or set of keywords defined by the Applicator vocabulary. It just ensures that schemas using this meta-schema that attempt to use the keywords - prefixed with "unevaluted" will fail validation against this meta-schema. + prefixed with "unevaluated" will fail validation against this meta-schema. Finally, this meta-schema describes the syntax of a keyword, "localKeyword", From 0143f212a96d33007f65b5e46796c38f11f21ff8 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 30 Sep 2020 23:15:37 +0100 Subject: [PATCH 223/780] Reference ECMAScript 11th Edition specifically for the purposes of optional regex support --- jsonschema-core.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 63212fce..d6735a64 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3931,6 +3931,7 @@ https://example.com/schemas/common#/$defs/count/minimum $dynamic* (previously $recursive) no longer use runtime base URI determination Reference ecma262 11th edition for regular expression support Define Compound Schema Documents (bundle) and processing + Reference ecma262 11th edition for regular expression support From 918631544ae34593ab0d6c76886adbee343114e1 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 3 Nov 2020 22:15:21 +0000 Subject: [PATCH 224/780] Fix how ECMA-262 is used and referenced --- jsonschema-core.xml | 14 +++++++------- jsonschema-validation.xml | 14 +++++++------- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d6735a64..3d7c6e31 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -545,12 +545,12 @@ Keywords MAY use regular expressions to express constraints, or constrain the instance value to be a regular expression. These regular expressions SHOULD be valid according to the regular expression - dialect described in ECMA 262, section 21.2.1. + dialect described in ECMA-262, section 21.2.1. Regular expressions SHOULD be built with the "u" flag (or equivilent) to provide - Unicode support, or processed in such a way which provides Unicode support, - as defined by ECMA 262. + Unicode support, or processed in such a way which provides which provides Unicode + as defined by ECMA-262. Furthermore, given the high disparity in regular expression constructs support, @@ -2485,7 +2485,7 @@ The value of "patternProperties" MUST be an object. Each property name of this object SHOULD be a valid regular expression, according to the - ECMA 262 regular expression dialect. Each property value of this object + ECMA-262 regular expression dialect. Each property value of this object MUST be a valid JSON Schema. @@ -3298,9 +3298,9 @@ https://example.com/schemas/common#/$defs/count/minimum - ECMA-262 11.0 edition specification + ECMA-262, 11th edition specification - + @@ -3931,7 +3931,7 @@ https://example.com/schemas/common#/$defs/count/minimum $dynamic* (previously $recursive) no longer use runtime base URI determination Reference ecma262 11th edition for regular expression support Define Compound Schema Documents (bundle) and processing - Reference ecma262 11th edition for regular expression support + Reference ECMA-262, 11th edition for regular expression support diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index c3b396bc..3f33f376 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -352,7 +352,7 @@
The value of this keyword MUST be a string. This string SHOULD be a - valid regular expression, according to the ECMA 262 regular expression + valid regular expression, according to the ECMA-262 regular expression dialect. @@ -898,12 +898,12 @@ A regular expression, which SHOULD be valid according to the - ECMA 262 regular expression dialect. + ECMA-262 regular expression dialect. Implementations that validate formats MUST accept at least the subset of - ECMA 262 defined in the Regular Expressions - section of this specification, and SHOULD accept all valid ECMA 262 expressions. + ECMA-262 defined in the Regular Expressions + section of this specification, and SHOULD accept all valid ECMA-262 expressions.
@@ -1318,9 +1318,9 @@ - ECMA-262 11.0 edition specification + ECMA-262, 11th edition specification - + @@ -1434,7 +1434,7 @@ Correct email format RFC reference to 5321 instead of 5322 Clarified the set and meaning of "contentEncoding" values - Reference ecma262 11th edition for regular expression support + Reference ECMA-262, 11th edition for regular expression support From 99130210a420d08a1c603f227135e230a3f0d2ca Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Wed, 4 Nov 2020 10:30:45 -0800 Subject: [PATCH 225/780] [1010] Remove duplicate words --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 473ed5d0..006b9967 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -549,8 +549,8 @@ Regular expressions SHOULD be built with the "u" flag (or equivilent) to provide - Unicode support, or processed in such a way which provides which provides Unicode - as defined by ECMA-262. + Unicode support, or processed in such a way which provides Unicode as defined + by ECMA-262. Furthermore, given the high disparity in regular expression constructs support, From 3ca2d9768b5176184bdca6476b21102e624fee49 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 6 Nov 2020 15:30:00 +0000 Subject: [PATCH 226/780] Update FUNDING.yml --- .github/FUNDING.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml index 9285b3c1..93f90d33 100644 --- a/.github/FUNDING.yml +++ b/.github/FUNDING.yml @@ -6,4 +6,4 @@ open_collective: json-schema ko_fi: relequestual tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry -custom: # Replace with a single custom sponsorship URL +custom: https://buymeacoffee.com/relequestual From 07e970f0bbc7f9eff1a8372f2d86fa509bb167a1 Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Mon, 9 Nov 2020 13:03:58 -0800 Subject: [PATCH 227/780] Fix ECMA-262 link According to the main ECMA-262 page, the link needs an "index.html" suffix. There's no guarantee that linking to the raw "11.0/" directory will lead to the correct place, even if it does. This updates to the correct rell-known link. Not all sites necessarily support a default page for an empty path suffix; it is not correct to remove the last part. Ref: https://www.ecma-international.org/publications/standards/Ecma-262.htm --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 006b9967..a6a4e3be 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3296,7 +3296,7 @@ https://example.com/schemas/common#/$defs/count/minimum &RFC8259; &ldp; + target="https://www.ecma-international.org/ecma-262/11.0/index.html"> ECMA-262, 11th edition specification From 2625e06b4ac7b57b67d016730f10aa61f3c21840 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 10 Nov 2020 13:20:24 +0000 Subject: [PATCH 228/780] Update editor contact information and thanks --- jsonschema-core.xml | 9 +++++---- jsonschema-validation.xml | 8 ++++---- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index a6a4e3be..614b2e6e 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -37,9 +37,8 @@ - Wellcome Sanger Institute
- bh7@sanger.ac.uk + ben@jsonschema.dev https://jsonschema.dev
@@ -3904,12 +3903,14 @@ https://example.com/schemas/common#/$defs/count/minimum Jason Desrosiers, Daniel Perrett, Erik Wilde, - Ben Hutton, Evgeny Poberezkin, Brad Bowman, Gowry Sankar, Donald Pipowitch, - and Dave Finlay + Dave Finlay, + Phil Sturgeon, + Shawn Silverman, + and Karen Etheridge for their submissions and patches to the document.
diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 3f33f376..4d31bc8a 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -47,9 +47,8 @@ - Wellcome Sanger Institute
- bh7@sanger.ac.uk + ben@jsonschema.dev https://jsonschema.dev
@@ -1413,13 +1412,14 @@ Jason Desrosiers, Daniel Perrett, Erik Wilde, - Ben Hutton, Evgeny Poberezkin, Brad Bowman, Gowry Sankar, Donald Pipowitch, Dave Finlay, - and Denis Laxalde + Phil Sturgeon, + Shawn Silverman, + and Karen Etheridge for their submissions and patches to the document.
From 5b252bf32e61fc1b110ec6a65dd0147863efa0e2 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 10 Nov 2020 13:29:33 +0000 Subject: [PATCH 229/780] Update series info and reference names for next draft --- jsonschema-core.xml | 10 +++++----- jsonschema-validation.xml | 11 +++++++---- 2 files changed, 12 insertions(+), 9 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 614b2e6e..20423638 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -20,7 +20,7 @@ - + JSON Schema: A Media Type for Describing JSON Documents @@ -3319,12 +3319,12 @@ https://example.com/schemas/common#/$defs/count/minimum - + - + - + @@ -3921,7 +3921,7 @@ https://example.com/schemas/common#/$defs/count/minimum - + "$schema" MAY change for embedded resources Array-value "items" functionality is now "prefixItems" diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 4d31bc8a..9b4a0c81 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -28,7 +28,7 @@ - + JSON Schema Validation: A Vocabulary for Structural Validation of JSON @@ -1344,9 +1344,12 @@ <author initials="H." surname="Andrews"> <organization/> </author> - <date year="2017" month="November"/> + <author initials="B." surname="Hutton"> + <organization/> + </author> + <date year="2020" month="November"/> </front> - <seriesInfo name="Internet-Draft" value="draft-handrews-json-schema-02" /> + <seriesInfo name="Internet-Draft" value="draft-bhutton-json-schema-00" /> </reference> </references> @@ -1430,7 +1433,7 @@ </t> <t> <list style="hanging"> - <t hangText="draft-handrews-json-schema-validation-03"> + <t hangText="draft-bhutton-json-schema-validation-00"> <list style="symbols"> <t>Correct email format RFC reference to 5321 instead of 5322</t> <t>Clarified the set and meaning of "contentEncoding" values</t> From 6b5208fab98d85590ff5d42abf8484f79b8a16d0 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Tue, 10 Nov 2020 16:21:52 +0000 Subject: [PATCH 230/780] Add back Denis Laxalde... oops --- jsonschema-core.xml | 1 + jsonschema-validation.xml | 1 + 2 files changed, 2 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 20423638..1c01efd5 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3908,6 +3908,7 @@ https://example.com/schemas/common#/$defs/count/minimum Gowry Sankar, Donald Pipowitch, Dave Finlay, + Denis Laxalde, Phil Sturgeon, Shawn Silverman, and Karen Etheridge diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 9b4a0c81..18266925 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1420,6 +1420,7 @@ Gowry Sankar, Donald Pipowitch, Dave Finlay, + Denis Laxalde, Phil Sturgeon, Shawn Silverman, and Karen Etheridge From e53d7ccaa72eb85b47b6ea305e57db677e6a9a5e Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Thu, 12 Nov 2020 13:22:28 +0000 Subject: [PATCH 231/780] remove duplicate entry in the changelog --- jsonschema-core.xml | 1 - 1 file changed, 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 1c01efd5..c5cab2a4 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3931,7 +3931,6 @@ https://example.com/schemas/common#/$defs/count/minimum <t>Rename $recursive* to $dynamic*</t> <t>$dynamicAnchor defines a fragment like $anchor</t> <t>$dynamic* (previously $recursive) no longer use runtime base URI determination</t> - <t>Reference ecma262 11th edition for regular expression support</t> <t>Define Compound Schema Documents (bundle) and processing</t> <t>Reference ECMA-262, 11th edition for regular expression support</t> <t></t> From cf80c1541aa78d545345759c36c02cee77943783 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Thu, 12 Nov 2020 13:23:10 +0000 Subject: [PATCH 232/780] Update all references to 2019-09 to 2020-11 --- jsonschema-core.xml | 40 +++++++++++++++++++-------------------- jsonschema-validation.xml | 18 +++++++++--------- 2 files changed, 29 insertions(+), 29 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index c5cab2a4..e8e2febe 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1115,11 +1115,11 @@ </t> <t> The current URI for the Core vocabulary is: - <https://json-schema.org/draft/2019-09/vocab/core>. + <https://json-schema.org/draft/2020-11/vocab/core>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2019-09/meta/core"/>. + <eref target="https://json-schema.org/draft/2020-11/meta/core"/>. </t> <t> While the "$" prefix is not formally reserved for the Core vocabulary, @@ -2160,11 +2160,11 @@ </t> <t> The current URI for this vocabulary, known as the Applicator vocabulary, is: - <https://json-schema.org/draft/2019-09/vocab/applicator>. + <https://json-schema.org/draft/2020-11/vocab/applicator>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2019-09/meta/applicator"/>. + <eref target="https://json-schema.org/draft/2020-11/meta/applicator"/>. </t> <t> Updated vocabulary and meta-schema URIs MAY be published between @@ -2589,11 +2589,11 @@ <t> The current URI for this vocabulary, known as the Unevaluated Applicator vocabulary, is: - <https://json-schema.org/draft/2019-09/vocab/unevaluated>. + <https://json-schema.org/draft/2020-11/vocab/unevaluated>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2019-09/meta/unevaluated"/>. + <eref target="https://json-schema.org/draft/2020-11/meta/unevaluated"/>. </t> <t> Updated vocabulary and meta-schema URIs MAY be published between @@ -2873,7 +2873,7 @@ https://example.com/schemas/common#/$defs/count/minimum <![CDATA[ { "$id": "https://example.com/polygon", - "$schema": "https://json-schema.org/draft/2019-09/schema", + "$schema": "https://json-schema.org/draft/2020-11/schema", "$defs": { "point": { "type": "object", @@ -3086,7 +3086,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t> Because this output structure can be quite large, a smaller example is given here for brevity. The URI of the full output structure of the example above is: - <eref target="https://json-schema.org/draft/2019-09/output/verbose-example"/>. + <eref target="https://json-schema.org/draft/2020-11/output/verbose-example"/>. </t> <figure> <artwork> @@ -3094,7 +3094,7 @@ https://example.com/schemas/common#/$defs/count/minimum // schema { "$id": "https://example.com/polygon", - "$schema": "https://json-schema.org/draft/2019-09/schema", + "$schema": "https://json-schema.org/draft/2020-11/schema", "type": "object", "properties": { "validProp": true, @@ -3148,7 +3148,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t> For convenience, JSON Schema has been provided to validate output generated by implementations. Its URI is: - <eref target="https://json-schema.org/draft/2019-09/output/schema"/>. + <eref target="https://json-schema.org/draft/2020-11/output/schema"/>. </t> </section> @@ -3556,7 +3556,7 @@ https://example.com/schemas/common#/$defs/count/minimum <![CDATA[ // tree schema, extensible { - "$schema": "https://json-schema.org/draft/2019-09/schema", + "$schema": "https://json-schema.org/draft/2020-11/schema", "$id": "https://example.com/tree", "$dynamicAnchor": "node", @@ -3574,7 +3574,7 @@ https://example.com/schemas/common#/$defs/count/minimum // strict-tree schema, guards against misspelled properties { - "$schema": "https://json-schema.org/draft/2019-09/schema", + "$schema": "https://json-schema.org/draft/2020-11/schema", "$id": "https://example.com/strict-tree", "$dynamicAnchor": node, @@ -3747,19 +3747,19 @@ https://example.com/schemas/common#/$defs/count/minimum <artwork> <![CDATA[ { - "$schema": "https://json-schema.org/draft/2019-09/schema", + "$schema": "https://json-schema.org/draft/2020-11/schema", "$id": "https://example.com/meta/general-use-example", "$dynamicAnchor": "meta", "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/core": true, - "https://json-schema.org/draft/2019-09/vocab/applicator": true, - "https://json-schema.org/draft/2019-09/vocab/validation": true, + "https://json-schema.org/draft/2020-11/vocab/core": true, + "https://json-schema.org/draft/2020-11/vocab/applicator": true, + "https://json-schema.org/draft/2020-11/vocab/validation": true, "https://example.com/vocab/example-vocab": true }, "allOf": [ - {"$ref": "https://json-schema.org/draft/2019-09/meta/core"}, - {"$ref": "https://json-schema.org/draft/2019-09/meta/applicator"}, - {"$ref": "https://json-schema.org/draft/2019-09/meta/validation"}, + {"$ref": "https://json-schema.org/draft/2020-11/meta/core"}, + {"$ref": "https://json-schema.org/draft/2020-11/meta/applicator"}, + {"$ref": "https://json-schema.org/draft/2020-11/meta/validation"}, {"$ref": "https://example.com/meta/example-vocab", ], "patternProperties": { @@ -3782,7 +3782,7 @@ https://example.com/schemas/common#/$defs/count/minimum <artwork> <![CDATA[ { - "$schema": "https://json-schema.org/draft/2019-09/schema", + "$schema": "https://json-schema.org/draft/2020-11/schema", "$id": "https://example.com/meta/example-vocab", "$dynamicAnchor": "meta", "$vocabulary": { diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 18266925..f04f05b3 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -177,7 +177,7 @@ <section title="Meta-Schema" anchor="meta-schema"> <t> The current URI for the default JSON Schema dialect meta-schema is - <eref target="https://json-schema.org/draft/2019-09/schema"/>. + <eref target="https://json-schema.org/draft/2020-11/schema"/>. For schema author convenience, this meta-schema describes a dialect consisting of all vocabularies defined in this specification and the JSON Schema Core specification, @@ -206,11 +206,11 @@ </t> <t> The current URI for this vocabulary, known as the Validation vocabulary, is: - <https://json-schema.org/draft/2019-09/vocab/validation>. + <https://json-schema.org/draft/2020-11/vocab/validation>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2019-09/meta/validation"/>. + <eref target="https://json-schema.org/draft/2020-11/meta/validation"/>. </t> <section title="Validation Keywords for Any Instance Type" anchor="general"> @@ -548,11 +548,11 @@ </t> <t> The current URI for this vocabulary, known as the Format vocabulary, is: - <https://json-schema.org/draft/2019-09/vocab/format>. + <https://json-schema.org/draft/2020-11/vocab/format>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2019-09/meta/format"/>. + <eref target="https://json-schema.org/draft/2020-11/meta/format"/>. </t> </section> @@ -928,11 +928,11 @@ </t> <t> The current URI for this vocabulary, known as the Content vocabulary, is: - <https://json-schema.org/draft/2019-09/vocab/content>. + <https://json-schema.org/draft/2020-11/vocab/content>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2019-09/meta/content"/>. + <eref target="https://json-schema.org/draft/2020-11/meta/content"/>. </t> </section> @@ -1128,11 +1128,11 @@ </t> <t> The current URI for this vocabulary, known as the Meta-Data vocabulary, is: - <https://json-schema.org/draft/2019-09/vocab/meta-data>. + <https://json-schema.org/draft/2020-11/vocab/meta-data>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2019-09/meta/meta-data"/>. + <eref target="https://json-schema.org/draft/2020-11/meta/meta-data"/>. </t> <section title='"title" and "description"'> From 4e6cd1f1b7a4059f8e2c19a4a4dc58cfe9a0a9f1 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Thu, 12 Nov 2020 13:32:04 +0000 Subject: [PATCH 233/780] Mark the documents as pre-release 2020-11-rc-0 --- jsonschema-core.xml | 3 +++ jsonschema-validation.xml | 3 +++ 2 files changed, 6 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e8e2febe..058f954e 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -75,6 +75,9 @@ </t> </abstract> <note title="Note to Readers"> + <t> + This document a pre-release identified as JSON Schema draft 2020-11-rc-0. + </t> <t> The issues list for this draft can be found at <eref target="https://github.com/json-schema-org/json-schema-spec/issues"/>. diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index f04f05b3..40e4e256 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -70,6 +70,9 @@ </abstract> <note title="Note to Readers"> + <t> + This document a pre-release identified as JSON Schema draft 2020-11-rc-0. + </t> <t> The issues list for this draft can be found at <eref target="https://github.com/json-schema-org/json-schema-spec/issues"/>. From 1aa5195fbf42f1508753390e2a96461f4e01f04b Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Fri, 13 Nov 2020 19:04:39 +1300 Subject: [PATCH 234/780] resolves #1014 - update output schema for draft 2020-xx --- output/schema.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/output/schema.json b/output/schema.json index ff523eea..0a65f20f 100644 --- a/output/schema.json +++ b/output/schema.json @@ -67,7 +67,7 @@ { "properties": { "keywordLocation": { - "pattern": "/\\$recursiveRef/" + "pattern": "/\\$dynamicRef/" } } } From c4e2b9911e2144e09af97b19f9aa93565073e321 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Fri, 13 Nov 2020 22:55:41 +0000 Subject: [PATCH 235/780] Replace the phrase "feature set" with dialect --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 058f954e..95fe91c4 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1168,9 +1168,9 @@ </t> <section title='The "$schema" Keyword' anchor="keyword-schema"> <t> - The "$schema" keyword is both used as a JSON Schema feature set identifier and + The "$schema" keyword is both used as a JSON Schema dialect identifier and as the identifier of a resource which is itself a JSON Schema, which describes the - set of valid schemas written for this particular feature set. + set of valid schemas written for this particular dialect. </t> <t> The value of this keyword MUST be a <xref target="RFC3986">URI</xref> From 159169fde1ab3aad56d4238960facfb828c9cc40 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Sat, 14 Nov 2020 22:23:45 +1300 Subject: [PATCH 236/780] resolves #910 - add paragraph describing independence of sibling subschemas --- jsonschema-core.xml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 058f954e..d7b42a77 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2212,6 +2212,13 @@ or modifying the subschema results in various ways. </t> + <t> + Subschemas of these keywords evaluate the instance completely independently + such that the results of one subschema MUST NOT impact the results of sibling + subschemas. The consequence of this is that the subschemas may be applied in + any order. + </t> + <section title="Keywords for Applying Subschemas With Logic" anchor="logic"> <t> These keywords correspond to logical operators for combining or modifying From 2655ac55a6fffb5c738959827d31fda707cf39cd Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Thu, 19 Nov 2020 17:49:02 +1300 Subject: [PATCH 237/780] resolves #1019 - added language to explicitly specify behavior when a vocab is known --- jsonschema-core.xml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 95fe91c4..c0cb8621 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1198,7 +1198,9 @@ vocabularies available for use in schemas described by that meta-schema. It is also used to indicate whether each vocabulary is required or optional, in the sense that an implementation MUST understand the required vocabularies - in order to successfully process the schema. + in order to successfully process the schema. Any vocabulary that is + understood by the implementation MUST be processed in a manner consistent + with the semantic definitions contained within the vocabulary. </t> <t> The value of this keyword MUST be an object. The property names in the @@ -1226,7 +1228,8 @@ 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. + such schemas. The value has no impact if the implementation + recognizes the vocabulary. </t> <t> Per <xref target="extending" format="counter"></xref>, unrecognized From 80cd553b77166e8433877413df68ab7cde2ca4a5 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Thu, 19 Nov 2020 15:35:14 +0000 Subject: [PATCH 238/780] Clearly define a dialect Fixes #1015 --- jsonschema-core.xml | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 95fe91c4..b8b9aca7 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -103,7 +103,8 @@ This specification defines JSON Schema core terminology and mechanisms, including pointing to another JSON Schema by reference, dereferencing a JSON Schema reference, - specifying the vocabulary being used, + specifying the dialect being used, + specifying a dialect's vocabulary requirements, and defining the expected output. </t> <t> @@ -146,9 +147,10 @@ some sort of condition. </t> <t> - To facilitate re-use, keywords can be organized into vocabularies. A vocabulary + To facilitate re-use, keywords can be organized into vocabularies. A vocabulary consists of a list of keywords, together with their syntax and semantics. - A set of vocabularies identified by a meta-schema is known as a dialect. + A dialect is defined as a set of vocabularies and their required support + identified in a meta-schema. </t> <t> JSON Schema can be extended either by defining additional vocabularies, @@ -1198,7 +1200,8 @@ vocabularies available for use in schemas described by that meta-schema. It is also used to indicate whether each vocabulary is required or optional, in the sense that an implementation MUST understand the required vocabularies - in order to successfully process the schema. + in order to successfully process the schema. Together, this information forms + a dialect. </t> <t> The value of this keyword MUST be an object. The property names in the From 6ca91fa8e32db075c65a1c2bd8a45c92c7cd7cca Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Thu, 19 Nov 2020 17:20:29 +0000 Subject: [PATCH 239/780] Attempt to justify and explain unevaluated keyword phrasing Fixes #998 --- jsonschema-core.xml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 95fe91c4..0f8bb73f 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2576,6 +2576,14 @@ to contribute to whether or not the item or property has been evaluated. Only successful evaluations are considered. </t> + <t> + If an item in an array or an object property is "successfully evaluated", it + is logically considered to be valid in terms of the representation of the + object or array that's expected. For example if a subschema represents a car, + which requires between 2-4 wheeles, and the value of "wheeles" is 6, the instance + object is not "evaluated" to be a car, and the "wheeles" property is considerd + "unevaluated (successfully as a known thing)", and does not retain any annotations. + </t> <t> Recall that adjacent keywords are keywords within the same schema object, and that the dynamic-scope subschemas include reference targets as well as From 13be1b21b70137ed6f9e884fa15bb6ff491f717d Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Fri, 20 Nov 2020 07:23:10 +1300 Subject: [PATCH 240/780] Update jsonschema-core.xml Co-authored-by: Ben Hutton <relequestual@gmail.com> --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d7b42a77..1a30c714 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2214,7 +2214,7 @@ <t> Subschemas of these keywords evaluate the instance completely independently - such that the results of one subschema MUST NOT impact the results of sibling + such that the results of one such subschema MUST NOT impact the results of sibling subschemas. The consequence of this is that the subschemas may be applied in any order. </t> From c260f98d09ad9bef3ba6fcf7156a15b8327d42c7 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Fri, 20 Nov 2020 07:23:19 +1300 Subject: [PATCH 241/780] Update jsonschema-core.xml Co-authored-by: Ben Hutton <relequestual@gmail.com> --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 1a30c714..0279a7da 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2215,7 +2215,7 @@ <t> Subschemas of these keywords evaluate the instance completely independently such that the results of one such subschema MUST NOT impact the results of sibling - subschemas. The consequence of this is that the subschemas may be applied in + subschemas. Therefore subschemas may be applied in any order. </t> From fd40243f6dae1a6aef32c6ebae9e271dffb2bf00 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Fri, 20 Nov 2020 07:23:41 +1300 Subject: [PATCH 242/780] Update jsonschema-core.xml Co-authored-by: Ben Hutton <relequestual@gmail.com> --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index c0cb8621..67e05d77 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1229,7 +1229,7 @@ this meta-schema with "$schema". If the value is false, implementations that do not recognize the vocabulary SHOULD proceed with processing such schemas. The value has no impact if the implementation - recognizes the vocabulary. + understands the vocabulary. </t> <t> Per <xref target="extending" format="counter"></xref>, unrecognized From 62b9c212a4b7b8e16534925b83ebc6aa7f302ed6 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Sun, 22 Nov 2020 09:48:38 +1300 Subject: [PATCH 243/780] issue-1020-separate-format-vocabularies --- jsonschema-validation.xml | 109 ++++++++++++++++---------------------- 1 file changed, 46 insertions(+), 63 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 40e4e256..9d5608c6 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -514,18 +514,12 @@ <section title="Foreword"> <t> Structural validation alone may be insufficient to allow an application to correctly - utilize certain values. The "format" annotation keyword is defined to allow schema + utilize certain values. The "format" annotation keyword is defined to allow schema authors to convey semantic information for a fixed subset of values which are accurately described by authoritative resources, be they RFCs or other external specifications. </t> - <t> - Implementations MAY treat "format" as an assertion in addition to an annotation, - and attempt to validate the value's conformance to the specified semantics. - See the Implementation Requirements below for details. - </t> - <t> The value of this keyword is called a format attribute. It MUST be a string. A format attribute can generally only validate a given set of instance types. If @@ -536,8 +530,8 @@ <xref target="json-schema">core JSON Schema.</xref> <cref> Note that the "type" keyword in this specification defines an "integer" type - which is not part of the data model. Therefore a format attribute can be - limited to numbers, but not specifically to integers. However, a numeric + which is not part of the data model. Therefore a format attribute can be + limited to numbers, but not specifically to integers. However, a numeric format can be used alongside the "type" keyword with a value of "integer", or could be explicitly defined to always pass if the number is not an integer, which produces essentially the same behavior as only applying to integers. @@ -545,75 +539,57 @@ </t> <t> - Meta-schemas that do not use "$vocabulary" SHOULD be considered to - utilize this vocabulary as if its URI were present with a value of false. - See the Implementation Requirements below for details. + The current URI for this vocabulary, known as the Format-Annotation vocabulary, is: + <https://json-schema.org/draft/2020-11/vocab/format-annotation>. This vocabulary + is required by this specification. </t> <t> - The current URI for this vocabulary, known as the Format vocabulary, is: - <https://json-schema.org/draft/2020-11/vocab/format>. + In addition to the Format-Annotation vocabulary, a secondary vocabulary is available + for custom meta-schemas that defines "format" as an assertion. The URI for the + Format-Assertion vocabulary, is: + <https://json-schema.org/draft/2020-11/vocab/format-assertation>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-11/meta/format"/>. + <eref target="https://json-schema.org/draft/2020-11/meta/format"/>. Because the + syntactic requirements of "format" do not change between the annotation and assertion + vocabularies, the meta-schema is shared between them. + </t> + <t> + Specifying both the Format-Annotation and the Format-Assertion vocabularies is functionally + equivalent to specifying only the Format-Assertion vocabulary since its requirements + are a superset of the Format-Annotation vocabulary. </t> - </section> <section title="Implementation Requirements"> <t> - The "format" keyword functions as an annotation, and optionally as an assertion. - <cref>This is due to the keyword's history, and is not in line with current - keyword design principles.</cref> In order to manage this ambiguity, the - "format" keyword is defined in its own separate vocabulary, as noted above. - 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. + The "format" keyword functions as defined by the vocabulary which is referenced. </t> - <section title="As an annotation"> + <section title="Format-Annotation Vocabulary"> <t> The value of format MUST be collected as an annotation, if the implementation - supports annotation collection. This enables application-level validation when + supports annotation collection. This enables application-level validation when schema validation is unavailable or inadequate. </t> <t> - This requirement is not affected by the boolean value of the vocabulary - declaration, nor by the configuration of "format"'s assertion - behavior described in the next section. + Implementations MAY still treat "format" as an assertion in addition to an + annotation and attempt to validate the value's conformance to the specified + semantics. The implementation MUST provide options to enable and disable such + evaluation and MUST be disabled by default. Implementations SHOULD document + their level of support for such validation. <cref> - Requiring annotation collection even when the vocabulary is declared with - a value of false is atypical, but necessary to ensure that the best - practice of performing application-level validation is possible even when - assertion evaluation is not implemented. Since "format" has always been - a part of this specification, requiring implementations to be aware of it - even with a false vocabulary declaration is deemed to not be a burden. + Specifying the Format-Annotation vocabulary and enabling validation in an + implementation should not be viewed as being equivalent to specifying + the Format-Assertion vocabulary since implementations are not required to + provide full validation support when the Format-Assertion vocabulary + is not specified. </cref> </t> - </section> - - <section title="As an assertion"> - <t> - Regardless of the boolean value of the vocabulary declaration, - an implementation that can evaluate "format" as an assertion MUST provide - options to enable and disable such evaluation. The assertion evaluation - behavior when the option is not explicitly specified depends on - the vocabulary declaration's boolean value. - </t> - - <t> - When implementing this entire specification, this vocabulary MUST - be supported with a value of false (but see details below), - and MAY be supported with a value of true. - </t> - <t> - When the vocabulary is declared with a value of false, an implementation: + When the implementation is configured for assertion behavior, it: <list> - <t> - MUST NOT evaluate "format" as an assertion unless it is explicitly - configured to do so; - </t> <t> SHOULD provide an implementation-specific best effort validation for each format attribute defined below; @@ -622,9 +598,6 @@ MAY choose to implement validation of any or all format attributes as a no-op by always producing a validation result of true; </t> - <t> - SHOULD document its level of support for validation. - </t> </list> <cref> This matches the current reality of implementations, which provide @@ -634,14 +607,24 @@ validation in the application, which is the recommended best practice. </cref> </t> + </section> + <section title="Format-Assertion Vocabulary"> + <t> + When the Format-Assertion vocabulary is declared with a value of false, + implementations MUST provide full validation support for all of the formats + defined by this specificaion. Implementations that cannot provide full + validation support MUST refuse to process the schema. + </t> <t> - When the vocabulary is declared with a value of true, an implementation - that supports this form of the vocabulary: + An implementation that supports the Format-Assertion vocabulary: <list> <t> - MUST evaluate "format" as an assertion unless it is explicitly - configured not to do so; + MUST still collect "format" as an annotation if the implementation + supports annotation collection; + </t> + <t> + MUST evaluate "format" as an assertion; </t> <t> MUST implement syntactic validation for all format attributes defined From b9615806f1bbae17b9c711b67d72403ca71fa30e Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Sun, 22 Nov 2020 11:07:16 +1300 Subject: [PATCH 244/780] cleaning up my authorship details --- jsonschema-core.xml | 7 +------ jsonschema-validation.xml | 3 +++ 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 95fe91c4..3593eeba 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -45,13 +45,8 @@ <author fullname="Greg Dennis" initials="G" surname="Dennis"> <address> - <postal> - <street></street> - <city>Auckland</city> - <region></region> - <country>NZ</country> - </postal> <email>gregsdennis@yahoo.com</email> + <uri>https://github.com/gregsdennis</uri> </address> </author> diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 40e4e256..185b8019 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1350,6 +1350,9 @@ <author initials="B." surname="Hutton"> <organization/> </author> + <author initials="G." surname="Dennis"> + <organization/> + </author> <date year="2020" month="November"/> </front> <seriesInfo name="Internet-Draft" value="draft-bhutton-json-schema-00" /> From 9949508260ac1050f404d2bd9e3f8356c87b5b4e Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Sun, 22 Nov 2020 11:39:20 +1300 Subject: [PATCH 245/780] add clarification around custom formats --- jsonschema-validation.xml | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 9d5608c6..00b68b3e 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -668,10 +668,9 @@ <t> Implementations MAY support custom format attributes. Save for agreement between parties, schema authors SHALL NOT expect a peer implementation to support such - custom format attributes. An implementation MUST NOT fail - validation or cease processing due to an unknown format attribute. - When treating "format" as an annotation, implementations SHOULD collect both - known and unknown format attribute values. + custom format attributes. An implementation MUST NOT fail to collect unknown formats + as annotations. When the Format-Assertion vocabulary is specified, implementations + MUST fail upon encountering unknown formats. </t> <t> Vocabularies do not support specifically declaring different value sets for keywords. From 9d29a9f04c2e4b5493bcb5cb365b7b4f888a87c9 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Sun, 22 Nov 2020 11:55:48 +1300 Subject: [PATCH 246/780] fixed 'assertation' typo --- jsonschema-validation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 00b68b3e..809e9650 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -547,7 +547,7 @@ In addition to the Format-Annotation vocabulary, a secondary vocabulary is available for custom meta-schemas that defines "format" as an assertion. The URI for the Format-Assertion vocabulary, is: - <https://json-schema.org/draft/2020-11/vocab/format-assertation>. + <https://json-schema.org/draft/2020-11/vocab/format-assertion>. </t> <t> The current URI for the corresponding meta-schema is: From d5b7385b57be91c7a4459ad6ee36c50b6fed4bdf Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Sun, 22 Nov 2020 06:54:11 +0000 Subject: [PATCH 247/780] Update jsonschema-core.xml Co-authored-by: Karen Etheridge <ether@cpan.org> --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0f8bb73f..d4429969 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2581,7 +2581,7 @@ is logically considered to be valid in terms of the representation of the object or array that's expected. For example if a subschema represents a car, which requires between 2-4 wheeles, and the value of "wheeles" is 6, the instance - object is not "evaluated" to be a car, and the "wheeles" property is considerd + object is not "evaluated" to be a car, and the "wheeles" property is considered "unevaluated (successfully as a known thing)", and does not retain any annotations. </t> <t> From 4c4efc6fe95431baddbafcf025db862a3d1100a6 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Sun, 22 Nov 2020 21:46:46 +0000 Subject: [PATCH 248/780] /wheeles/wheels/ --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d4429969..3467c6c3 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2580,8 +2580,8 @@ If an item in an array or an object property is "successfully evaluated", it is logically considered to be valid in terms of the representation of the object or array that's expected. For example if a subschema represents a car, - which requires between 2-4 wheeles, and the value of "wheeles" is 6, the instance - object is not "evaluated" to be a car, and the "wheeles" property is considered + which requires between 2-4 wheels, and the value of "wheels" is 6, the instance + object is not "evaluated" to be a car, and the "wheels" property is considered "unevaluated (successfully as a known thing)", and does not retain any annotations. </t> <t> From 8acb128c915c78d691a014ed37326e1e4bfbddba Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Mon, 23 Nov 2020 18:46:34 +1300 Subject: [PATCH 249/780] split format meta-schemas; explicitly specify implementation support for format --- jsonschema-validation.xml | 17 ++++++++--------- meta/format-annotation.json | 14 ++++++++++++++ meta/{format.json => format-assertion.json} | 4 ++-- 3 files changed, 24 insertions(+), 11 deletions(-) create mode 100644 meta/format-annotation.json rename meta/{format.json => format-assertion.json} (64%) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 809e9650..7261c868 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -540,20 +540,19 @@ <t> The current URI for this vocabulary, known as the Format-Annotation vocabulary, is: - <https://json-schema.org/draft/2020-11/vocab/format-annotation>. This vocabulary - is required by this specification. + <https://json-schema.org/draft/2020-11/vocab/format-annotation>. The current + URI for the corresponding meta-schema is: + <eref target="https://json-schema.org/draft/2020-11/meta/format-annotation"/>. + Implementing support for this vocabulary is REQUIRED. </t> <t> In addition to the Format-Annotation vocabulary, a secondary vocabulary is available for custom meta-schemas that defines "format" as an assertion. The URI for the Format-Assertion vocabulary, is: - <https://json-schema.org/draft/2020-11/vocab/format-assertion>. - </t> - <t> - The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-11/meta/format"/>. Because the - syntactic requirements of "format" do not change between the annotation and assertion - vocabularies, the meta-schema is shared between them. + <https://json-schema.org/draft/2020-11/vocab/format-assertion>. The current + URI for the corresponding meta-schema is: + <eref target="https://json-schema.org/draft/2020-11/meta/format-assertion"/>. + Implementing support for the Format-Assertion vocabulary is OPTIONAL. </t> <t> Specifying both the Format-Annotation and the Format-Assertion vocabularies is functionally diff --git a/meta/format-annotation.json b/meta/format-annotation.json new file mode 100644 index 00000000..b408fb3c --- /dev/null +++ b/meta/format-annotation.json @@ -0,0 +1,14 @@ +{ + "$schema": "https://json-schema.org/draft/2019-09/schema", + "$id": "https://json-schema.org/draft/2019-09/meta/format-annotation", + "$vocabulary": { + "https://json-schema.org/draft/2019-09/vocab/format-annotation": true + }, + "$dynamicAnchor": "meta", + + "title": "Format vocabulary meta-schema", + "type": ["object", "boolean"], + "properties": { + "format": { "type": "string" } + } +} diff --git a/meta/format.json b/meta/format-assertion.json similarity index 64% rename from meta/format.json rename to meta/format-assertion.json index 68ad5b0d..7a9edfdd 100644 --- a/meta/format.json +++ b/meta/format-assertion.json @@ -1,8 +1,8 @@ { "$schema": "https://json-schema.org/draft/2019-09/schema", - "$id": "https://json-schema.org/draft/2019-09/meta/format", + "$id": "https://json-schema.org/draft/2019-09/meta/format-assertion", "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/format": true + "https://json-schema.org/draft/2019-09/vocab/format-assertion": true }, "$dynamicAnchor": "meta", From f3e5b536fb225f0b14242d0c906e3f244e408071 Mon Sep 17 00:00:00 2001 From: Karen Etheridge <ether@cpan.org> Date: Mon, 23 Nov 2020 13:35:42 -0800 Subject: [PATCH 250/780] it is no longer valid to treat $comment as an unknown keyword ..because now, we collect unknown keywords as annotations, and this behaviour is explicitly prohibited for $comment. --- jsonschema-core.xml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 18ced482..263c2dda 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1578,8 +1578,7 @@ properties are present is implementation-dependent. </t> <t> - Implementations SHOULD treat "$comment" identically to an unknown extension - keyword. They MAY strip "$comment" values at any point during processing. + Implementations MAY strip "$comment" values at any point during processing. In particular, this allows for shortening schemas when the size of deployed schemas is a concern. </t> From 242cfd0e88d311ebb77258fe166d4afd85a99bd4 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Tue, 24 Nov 2020 17:38:21 +1300 Subject: [PATCH 251/780] update title for meta-schemas --- jsonschema-validation.xml | 2 +- meta/format-annotation.json | 2 +- meta/format-assertion.json | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 7261c868..0a7f3149 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -610,7 +610,7 @@ <section title="Format-Assertion Vocabulary"> <t> - When the Format-Assertion vocabulary is declared with a value of false, + When the Format-Assertion vocabulary is declared with a value of true, implementations MUST provide full validation support for all of the formats defined by this specificaion. Implementations that cannot provide full validation support MUST refuse to process the schema. diff --git a/meta/format-annotation.json b/meta/format-annotation.json index b408fb3c..a4080d69 100644 --- a/meta/format-annotation.json +++ b/meta/format-annotation.json @@ -6,7 +6,7 @@ }, "$dynamicAnchor": "meta", - "title": "Format vocabulary meta-schema", + "title": "Format vocabulary meta-schema for annotation results", "type": ["object", "boolean"], "properties": { "format": { "type": "string" } diff --git a/meta/format-assertion.json b/meta/format-assertion.json index 7a9edfdd..ecac5c1f 100644 --- a/meta/format-assertion.json +++ b/meta/format-assertion.json @@ -6,7 +6,7 @@ }, "$dynamicAnchor": "meta", - "title": "Format vocabulary meta-schema", + "title": "Format vocabulary meta-schema for assertion results", "type": ["object", "boolean"], "properties": { "format": { "type": "string" } From fa0bc2e47dfffb232def29500503c1edde345fd4 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers <jdesrosi@gmail.com> Date: Mon, 23 Nov 2020 21:57:29 -0800 Subject: [PATCH 252/780] Fix "dynamic" keywords in core vocabulary meta-schema --- meta/core.json | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/meta/core.json b/meta/core.json index c7b6c218..1313d3fb 100644 --- a/meta/core.json +++ b/meta/core.json @@ -27,13 +27,13 @@ "type": "string", "format": "uri-reference" }, - "$recursiveRef": { + "$dynamicRef": { "type": "string", "format": "uri-reference" }, - "$recursiveAnchor": { - "type": "boolean", - "default": false + "$dynamicAnchor": { + "type": "string", + "pattern": "^[A-Za-z_][-A-Za-z0-9._]*$" }, "$vocabulary": { "type": "object", From a939163fff1ca4b99977b4b164f0737c27435d78 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Tue, 24 Nov 2020 23:24:50 +0000 Subject: [PATCH 253/780] Modify title for the format vocabulaires, as there are now two --- jsonschema-validation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 4d02627e..f9ddb103 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -509,7 +509,7 @@ </section> </section> - <section title='A Vocabulary for Semantic Content With "format"' anchor="format"> + <section title='Vocabularies for Semantic Content With "format"' anchor="format"> <section title="Foreword"> <t> From 76f32d1363a2429909f0b2562813bc612513aae8 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Tue, 24 Nov 2020 23:40:11 +0000 Subject: [PATCH 254/780] Update general-purpose meta-schema vocabulary and reference for format-annotation --- schema.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/schema.json b/schema.json index 0544997c..bfc11392 100644 --- a/schema.json +++ b/schema.json @@ -7,7 +7,7 @@ "https://json-schema.org/draft/2019-09/vocab/unevaluated": true, "https://json-schema.org/draft/2019-09/vocab/validation": true, "https://json-schema.org/draft/2019-09/vocab/meta-data": true, - "https://json-schema.org/draft/2019-09/vocab/format": false, + "https://json-schema.org/draft/2019-09/meta/format-annotation": true, "https://json-schema.org/draft/2019-09/vocab/content": true }, "$dynamicAnchor": "meta", @@ -18,7 +18,7 @@ {"$ref": "meta/applicator"}, {"$ref": "meta/validation"}, {"$ref": "meta/meta-data"}, - {"$ref": "meta/format"}, + {"$ref": "meta/format-annotation"}, {"$ref": "meta/content"} ], "type": ["object", "boolean"], From 26f223ba518ec14b633f2f553fc34c984af29d40 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Tue, 24 Nov 2020 23:43:58 +0000 Subject: [PATCH 255/780] Add format split to the validation changelog --- jsonschema-validation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index f9ddb103..1f13b611 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1426,7 +1426,7 @@ <t>Correct email format RFC reference to 5321 instead of 5322</t> <t>Clarified the set and meaning of "contentEncoding" values</t> <t>Reference ECMA-262, 11th edition for regular expression support</t> - <t></t> + <t>Split "format" into an annotation only vocabulary and an assertion vocabulary</t> <t></t> <t></t> <t></t> From fcbdf8883726f502731bb7a86b8c4f5ce1759dbd Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Thu, 26 Nov 2020 13:15:06 +0000 Subject: [PATCH 256/780] Specify that other keywords may load or inspect instance data in other locations --- jsonschema-core.xml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 42dc4328..3dd6848d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1085,6 +1085,21 @@ undesirable interactions with references in certain circumstances. </t> </section> + <section title="Loading Instance Data"> + <t> + While none of the vocabularies defined as part of this or the associated documents + define a keyword which may target and / or load instance data, it is possible that + other vocabularies may wish to do so. + </t> + <t> + Keywords MAY be defined to use JSON Pointers or Relative JSON Pointers to examine + parts of an instance outside the current scope. + </t> + <t> + Keywords that allow adjusting the location using a Relative JSON Pointer SHOULD + default to using the current location if a default is desireable. + </t> + </section> </section> <section title="The JSON Schema Core Vocabulary"> <t> From 7323afd6ca6b5896788b441705d3b808b2da86cf Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Thu, 26 Nov 2020 21:21:28 +0000 Subject: [PATCH 257/780] Update jsonschema-core.xml Co-authored-by: Karen Etheridge <ether@cpan.org> --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 3dd6848d..b9469a06 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1088,7 +1088,7 @@ <section title="Loading Instance Data"> <t> While none of the vocabularies defined as part of this or the associated documents - define a keyword which may target and / or load instance data, it is possible that + define a keyword which may target and/or load instance data, it is possible that other vocabularies may wish to do so. </t> <t> From 554d0c56f3314291546c4861b660f3af3009c911 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Fri, 27 Nov 2020 12:15:20 +0000 Subject: [PATCH 258/780] Modify some requirements and language relating to compound schema documents based on feedback in #1032. Allow embedded schema resources to use relative URIs as opposed to just absolute URIs. Reference dialect rather than in terms of processing requirements for embedded resources which don't specify their dialect via . --- jsonschema-core.xml | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 42dc4328..099a20da 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1856,14 +1856,14 @@ <t> The bundling process for creating a Compound Schema Document is defined as taking references (such as "$ref") to an external Schema Resource and embedding the referenced - Schema Resources within the referring document. Bundling is done in such a way that + Schema Resources within the referring document. Bundling SHOULD be done in such a way that all URIs (used for referencing) in the base document and any referenced/embedded documents do not require altering. </t> <t> - Each embedded JSON Schema Resource MUST identify itself with an absolute URI using the "$id" keyword, + Each embedded JSON Schema Resource MUST identify itself with a URI using the "$id" keyword, and SHOULD make use of the "$schema" keyword to identify the dialect it is using, in the root of the - schema resource. + schema resource. It is RECOMMENDED that the URI identifier value of "$id" be an Absolute URI. </t> <t> When the Schema Resource referenced by a by-reference applicator is bundled, the Schema Resource @@ -1874,7 +1874,7 @@ bundling process. </t> <t> - Bundled Schema Resource MUST NOT be bundled by replacing the schema object from which it was + Schema Resources MUST NOT be bundled by replacing the schema object from which it was referenced, or by wrapping the Schema Resource in other applicator keywords. </t> <t> @@ -1891,14 +1891,13 @@ </section> <section title="Differing and Default Dialects"> <t> - If multiple schema resources are present in a single document, then - schema resources which do not have a "$schema" keyword in their root - schema object MUST be processed as if "$schema" were present with the - same value as for the immediately enclosing resource. + When multiple schema resources are present in a single document, + schema resources which do not define with which dialect they should be processed + MUST be processed with the same dialect as the enclosing resource. </t> <t> Since any schema that can be referenced can also be embedded, embedded schema resources MAY - specify different "$schema" values from their enclosing resource. + specify different processing dialects using the "$schema" values from their enclosing resource. </t> </section> <section title="Validating"> From de08044b9c09dfd7aafb043ca7bbefce7901dd75 Mon Sep 17 00:00:00 2001 From: Shawn Silverman <shawn@pobox.com> Date: Fri, 27 Nov 2020 16:06:16 -0800 Subject: [PATCH 259/780] [1036] Add a missing "a" --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 099a20da..ed7a12b1 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1844,7 +1844,7 @@ <section title="Compound Documents"> <t> - A Compound Schema Document is defined as JSON document (sometimes called a "bundled" schema) + A Compound Schema Document is defined as a JSON document (sometimes called a "bundled" schema) which has multiple embedded JSON Schema Resources bundled into the same document to ease transportation. </t> From 7e235dd9948deee78773bb414249d7edea7e90fb Mon Sep 17 00:00:00 2001 From: Karen Etheridge <ether@cpan.org> Date: Fri, 27 Nov 2020 17:27:32 -0800 Subject: [PATCH 260/780] improve some wording in draft 2020-xx rc0 --- jsonschema-core.xml | 8 ++++---- schema.json | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 42dc4328..ed420d9f 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -287,7 +287,7 @@ where an instance may be outside any of the six JSON data types. </t> <t> - In this case, annotations still apply; but validation keywords will not be useful, + In this case, annotations still apply; but most validation keywords will not be useful, as they will always pass or always fail. </t> <t> @@ -345,7 +345,7 @@ of their subschemas. </t> <t> - Keywords within the same schema object are referred to as adjacent keywords. + Keywords which are properties within the same schema object are referred to as adjacent keywords. </t> <t> Extension keywords, meaning those defined outside of this document @@ -364,7 +364,7 @@ <section title="Boolean JSON Schemas"> <t> The boolean schema values "true" and "false" are trivial schemas that - always produce themselves as assertions results, regardless of the + always produce themselves as assertion results, regardless of the instance value. They never produce annotation results. </t> <t> @@ -547,7 +547,7 @@ dialect described in <xref target="ecma262">ECMA-262, section 21.2.1</xref>. </t> <t> - Regular expressions SHOULD be built with the "u" flag (or equivilent) to provide + Regular expressions SHOULD be built with the "u" flag (or equivalent) to provide Unicode support, or processed in such a way which provides Unicode as defined by ECMA-262. </t> diff --git a/schema.json b/schema.json index bfc11392..8701d9d7 100644 --- a/schema.json +++ b/schema.json @@ -7,7 +7,7 @@ "https://json-schema.org/draft/2019-09/vocab/unevaluated": true, "https://json-schema.org/draft/2019-09/vocab/validation": true, "https://json-schema.org/draft/2019-09/vocab/meta-data": true, - "https://json-schema.org/draft/2019-09/meta/format-annotation": true, + "https://json-schema.org/draft/2019-09/vocab/format-annotation": true, "https://json-schema.org/draft/2019-09/vocab/content": true }, "$dynamicAnchor": "meta", From ba25b0ed6667a08e23bcb45e4d26704f3dc9e289 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Sat, 28 Nov 2020 16:04:09 +0000 Subject: [PATCH 261/780] Reduce restrictions on where bundled schema resource may be located --- jsonschema-core.xml | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index ed7a12b1..37ea2d01 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1866,15 +1866,19 @@ schema resource. It is RECOMMENDED that the URI identifier value of "$id" be an Absolute URI. </t> <t> - When the Schema Resource referenced by a by-reference applicator is bundled, the Schema Resource - MUST be located as a value of a "$defs" object at the containing schema's root. + When the Schema Resource referenced by a by-reference applicator is bundled, it is RECOMMENDED that + the Schema Resource be located as a value of a "$defs" object at the containing schema's root. The key of the "$defs" for the now embedded Schema Resource MAY be the "$id" of the bundled schema or some other form of application defined unique identifer (such as a UUID). This key is not intended to be referenced in JSON Schema, but may be used by an application to aid the bundling process. </t> <t> - Schema Resources MUST NOT be bundled by replacing the schema object from which it was + A Schema Resource MAY be embedded in a location other than "$defs" where the location is defined + as a schema value. + </t> + <t> + A Bundled Schema Resource MUST NOT be bundled by replacing the schema object from which it was referenced, or by wrapping the Schema Resource in other applicator keywords. </t> <t> From 5eda485e2321f30198a02dbd651d79f73da88d60 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Sat, 28 Nov 2020 22:30:30 +0000 Subject: [PATCH 262/780] Remove media type parameters Not convinced it was used and there are outstanding questions we should look to resolve should they be re-added. I understand they were mainly for use with HyperSchema, although I can see utility if they are well and clearly defined. Look at https://github.com/json-schema-org/json-schema-spec/issues/832 should they want to be re-added. --- jsonschema-core.xml | 115 ++------------------------------------------ 1 file changed, 3 insertions(+), 112 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 37ea2d01..e597e5c8 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -208,8 +208,7 @@ </t> <t> Among these, this specification defines the "application/schema-instance+json" - media type which defines handling for fragments in the URI, - and the "schema" media type parameter. + media type which defines handling for fragments in the URI. </t> <section title="Instance Data Model"> @@ -305,7 +304,7 @@ A schema can itself be interpreted as an instance, but SHOULD always be given the media type "application/schema+json" rather than "application/schema-instance+json". The "application/schema+json" media - type is defined to offer a superset of the media type parameter and + type is defined to offer a superset of the fragment identifier syntax and semantics provided by "application/schema-instance+json". </t> @@ -2007,114 +2006,6 @@ </section> - - <section title='Identifying a Schema via a Media Type Parameter' anchor="parameter"> - <t> - Media types MAY allow for a "schema" media type parameter, which gives - HTTP servers the ability to perform Content-Type Negotiation based on schema. - The media-type parameter MUST be a whitespace-separated list of URIs - (i.e. relative references are invalid). - </t> - <t> - When using the media type application/schema-instance+json, the "schema" - parameter MUST be supplied. - </t> - <t> - When using the media type application/schema+json, the "schema" parameter - MAY be supplied. If supplied, it SHOULD contain the same URI as identified - by the "$schema" keyword, and MAY contain additional URIs. The "$schema" - URI MUST be considered the schema's canonical meta-schema, regardless - of the presence of alternative or additional meta-schemas as a media type - parameter. - </t> - <t> - The schema URI is opaque and SHOULD NOT automatically be dereferenced. - If the implementation does not understand the semantics of the provided schema, - the implementation can instead follow the "describedby" links, if any, which may - provide information on how to handle the schema. - Since "schema" doesn't necessarily point to a network location, the - "describedby" relation is used for linking to a downloadable schema. - However, for simplicity, schema authors should make these URIs point to the same - resource when possible. - </t> - - <t> - In HTTP, the media-type parameter would be sent inside the Content-Type header: - </t> - - <figure> - <artwork> - <![CDATA[ - Content-Type: application/schema-instance+json; - schema="https://example.com/my-hyper-schema" - ]]> - </artwork> - </figure> - - <t> - Multiple schemas are whitespace separated, and indicate that the - instance conforms to all of the listed schemas: - </t> - - <figure> - <artwork> - <![CDATA[ - Content-Type: application/schema-instance+json; - schema="https://example.com/alice https://example.com/bob" - ]]> - </artwork> - </figure> - - <t> - Media type parameters are also used in HTTP's Accept request header: - </t> - - <figure> - <artwork> - <![CDATA[ - Accept: application/schema-instance+json; - schema="https://example.com/qiang https://example.com/li", - application/schema-instance+json; - schema="https://example.com/kumar" - ]]> - </artwork> - </figure> - - <t> - As with Content-Type, multiple schema parameters in the same string - requests an instance that conforms to all of the listed schemas. - </t> - - <t> - Unlike Content-Type, Accept can contain multiple values to - indicate that the client can accept several media types. - In the above example, note that the two media types differ - only by their schema parameter values. This requests an - application/schema-instance+json representation that conforms to at least one - of the identified schemas. - </t> - - <t> - <cref> - This paragraph assumes that we can register a "schema" link relation. - Should we instead specify something like "tag:json-schema.org,2017:schema" - for now? - </cref> - HTTP can also send the "schema" in a Link, though this may impact media-type - semantics and Content-Type negotiation if this replaces the media-type parameter - entirely: - </t> - - <figure> - <artwork> - <![CDATA[ - Link: </alice>;rel="schema", </bob>;rel="schema" - ]]> - </artwork> - </figure> - - </section> - <section title="Usage Over HTTP"> <t> When used for hypermedia systems over a network, @@ -3954,7 +3845,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t>$dynamic* (previously $recursive) no longer use runtime base URI determination</t> <t>Define Compound Schema Documents (bundle) and processing</t> <t>Reference ECMA-262, 11th edition for regular expression support</t> - <t></t> + <t>Remove media type parameters</t> <t></t> <t></t> </list> From b6d1f275483d4f5f9b4920071892bd7e5d3280be Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Sat, 28 Nov 2020 22:41:51 +0000 Subject: [PATCH 263/780] Modify phrasing relating to instance location --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b9469a06..35b5382a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1093,7 +1093,7 @@ </t> <t> Keywords MAY be defined to use JSON Pointers or Relative JSON Pointers to examine - parts of an instance outside the current scope. + parts of an instance outside the current evaluation location. </t> <t> Keywords that allow adjusting the location using a Relative JSON Pointer SHOULD From 10e8874471da5d3eb363edb2ccf51c3641ffb75a Mon Sep 17 00:00:00 2001 From: Jason Desrosiers <jdesrosi@gmail.com> Date: Mon, 30 Nov 2020 13:28:01 -0800 Subject: [PATCH 264/780] Fixes for dynamic scope and keywords --- jsonschema-core.xml | 71 ++++++++++++++++----------------------------- 1 file changed, 25 insertions(+), 46 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b6b79553..b93ca986 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -654,25 +654,17 @@ appear in a schema resource's root schema. </t> <t> - Other keywords may take into account the dynamic scope that - exists during the evaluation of a schema, typically together - with an instance document. The outermost dynamic scope is the - root schema of the schema document in which processing begins. - The path from this root schema to any particular keyword (that - includes any "$ref" and "$dynamicRef" keywords that may have - been resolved) is considered the keyword's "validation path." - <cref> - Or should this be the schema object at which processing - begins, even if it is not a root? This has some implications - for the case where "$dynamicAnchor" is only allowed in the - root schema but processing begins in a subschema. - </cref> + Other keywords may take into account the dynamic scope that exists during the + evaluation of a schema. The outermost dynamic scope is the root schema of the + schema document in which processing begins. The path from this root schema to + any particular keyword (that includes any "$ref" and "$dynamicRef" keywords that + may have been resolved) is considered the keyword's "validation path." </t> <t> Lexical and dynamic scopes align until a reference keyword is encountered. While following the reference keyword moves processing from one lexical scope into a different one, from the perspective - of dynamic scope, following reference is no different from descending + of dynamic scope, following a reference is no different from descending into a subschema present as a value. A keyword on the far side of that reference that resolves information through the dynamic scope will consider the originating side of the reference to be their @@ -741,7 +733,7 @@ <t> Canonical schema URIs MUST NOT change while processing an instance, but keywords that affect URI-reference resolution MAY have behavior that - is only fully determined at runtime. + is only fully determined dynamically. </t> <t> While custom identifier keywords are possible, vocabulary designers should @@ -798,12 +790,10 @@ of an instance against a schema. </t> <t> - For some by-reference applicators, such as - <xref target="ref">"$ref"</xref>, the referenced schema can be determined - by static analysis of the schema document's lexical scope. Others, - such as "$dynamicRef" (with "$dynamicAnchor"), may make use of dynamic - scoping, and therefore only be resolvable in the process of evaluating - the schema with an instance. + For some by-reference applicators, such as <xref target="ref">"$ref"</xref>, the + referenced schema can be determined by static analysis of the schema document's + lexical scope. Others, such as "$dynamicRef" (with "$dynamicAnchor"), are only + resolvable with knowledge of all the schemas in it's dynamic scope. </t> </section> </section> @@ -1397,7 +1387,6 @@ The "$anchor" and "$dynamicAnchor" keywords are used to specify such fragments. They are identifier keywords that can only be used to create plain name fragments, rather than absolute URIs as seen with "$id". - The behavior of the created fragment is identical for both keywords. </t> <t> The base URI to which the resulting fragment is appended is the canonical @@ -1471,32 +1460,30 @@ </cref> </t> <t> - The value of the "$ref" property MUST be a string which is a URI-Reference. + The value of the "$ref" keyword MUST be a string which is a URI-Reference. Resolved against the current URI base, it produces the URI of the schema - to apply. This resolution is safe to perform on schema load, as the - process of evaluating an instance cannot change how the reference resolves. + to apply. This resolution is safe to perform on schema load as neither other + schemas nor the instance can change how the reference resolves. </t> </section> <section title='Dynamic References with "$dynamicRef"' anchor="dynamic-ref"> <t> - The "$dynamicRef" keyword is an applicator that allows for deferring the - full resolution until runtime, at which point it is resolved each time it is - encountered while evaluating an instance. + The "$dynamicRef" keyword is an applicator that is used to reference a + dynamically identified schema. </t> <t> Together with "$dynamicAnchor", "$dynamicRef" implements a cooperative extension mechanism that is primarily useful with recursive schemas (schemas that reference themselves). Both the extension point and the - runtime-determined extension target are defined with "$dynamicAnchor", - and only exhibit runtime dynamic behavior when referenced with - "$dynamicRef". + extension target are defined with "$dynamicAnchor", and only exhibit dynamic + behavior when referenced with "$dynamicRef". </t> <t> - The value of the "$dynamicRef" property MUST be a string which is - a URI-Reference. Resolved against the current URI base, it produces - the URI used as the starting point for runtime resolution. This initial - resolution is safe to perform on schema load. + The value of the "$dynamicRef" property MUST be a string which is a + URI-Reference. Resolved against the current URI base, it produces the URI used + as the starting point for resolution. This initial resolution is safe to perform + on schema load. </t> <t> If the initially resolved starting point URI includes a fragment that @@ -1504,18 +1491,10 @@ replaced by the URI (including the fragment) for the outermost schema resource in the <xref target="scopes">dynamic scope</xref> that defines an identically named fragment with "$dynamicAnchor". - <cref> - Requiring both the initial and final URI fragment to be defined - by "$dynamicAnchor" ensures that the more common "$anchor" - never unexpectedly changes the dynamic resolution process - due to a naming conflict across resources. Users of - "$dynamicAnchor" are expected to be aware of the possibility - of such name collisions, while users of "$anchor" are not. - </cref> </t> <t> - Otherwise, its behavior is identical to "$ref", and no runtime - resolution is needed. + Otherwise, its behavior is identical to "$ref", and no dynamic resolution is + needed. </t> <t> For a full example using these keyword, see appendix @@ -3503,7 +3482,7 @@ https://example.com/schemas/common#/$defs/count/minimum { "$schema": "https://json-schema.org/draft/2020-11/schema", "$id": "https://example.com/strict-tree", - "$dynamicAnchor": node, + "$dynamicAnchor": "node", "$ref": "tree", "unevaluatedProperties": false From 110c24cd48b3174b87ac3df81775881956e3825e Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Tue, 1 Dec 2020 11:01:10 +0000 Subject: [PATCH 265/780] Clarify contains when applying to an empty array, annotation results, and how they are used --- jsonschema-core.xml | 15 +++++++++++---- jsonschema-validation.xml | 32 ++++++++++++++++++-------------- 2 files changed, 29 insertions(+), 18 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b6b79553..451c5a22 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2360,16 +2360,23 @@ </t> <t> An array instance is valid against "contains" if at least one of - its elements is valid against the given schema. Note that when - collecting annotations, the subschema MUST be applied to every - array element even after the first match has been found. This - is to ensure that all possible annotations are collected. + its elements is valid against the given schema. The subschema MUST be + applied to every array element even after the first match has + been found, in order to collect annotations for use by other keywords. + This is to ensure that all possible annotations are collected. + </t> + <t> + Logically, the validation result of applying the value subschema to each + item in the array MUST be ORed with "false", resulting in an overall + validation result. </t> <t> This keyword produces an annotation value which is an array of the indexes to which this keyword validates successfully when applying its subschema, in ascending order. The value MAY be a boolean true if the subschema validated successfully when applied to every index of the instance. + If the instance array this keywords subschema is applicable to is empty, + the annotation value MUST NOT be missing. </t> </section> </section> diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 1f13b611..8e1f3cf2 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -408,16 +408,18 @@ <t> The value of this keyword MUST be a non-negative integer. </t> - <t> - An array instance is valid against "maxContains" if the number of - elements that are valid against the schema for - <xref target="json-schema">"contains"</xref> is - less than, or equal to, the value of this keyword. - </t> <t> If "contains" is not present within the same schema object, then this keyword has no effect. </t> + <t> + An array instance is valid against "maxContains" if its + value is less than or equal to, the array length of the annotation + result from an ajacent + <xref target="json-schema">"contains"</xref> keyword where the + annotation is an array, or the length of the instance array + where the annotation is "true". + </t> </section> <section title="minContains"> @@ -425,20 +427,22 @@ The value of this keyword MUST be a non-negative integer. </t> <t> - An array instance is valid against "minContains" if the number of - elements that are valid against the schema for - <xref target="json-schema">"contains"</xref> is - greater than, or equal to, the value of this keyword. + If "contains" is not present within the same schema object, + then this keyword has no effect. + </t> + <t> + An array instance is valid against "minContains" if its + value is greater than or equal to, the array length of the annotation + result from an ajacent + <xref target="json-schema">"contains"</xref> keyword where the + annotation is an array, or the length of the instance array + where the annotation is "true". </t> <t> A value of 0 is allowed, but is only useful for setting a range of occurrences from 0 to the value of "maxContains". A value of 0 with no "maxContains" causes "contains" to always pass validation. </t> - <t> - If "contains" is not present within the same schema object, - then this keyword has no effect. - </t> <t> Omitting this keyword has the same behavior as a value of 1. </t> From 62c7eafd50dcc9485cb1fbfc488d0edd3edb6352 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Tue, 1 Dec 2020 11:03:10 +0000 Subject: [PATCH 266/780] Quotes around value --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 451c5a22..8e56bc88 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2373,7 +2373,7 @@ <t> This keyword produces an annotation value which is an array of the indexes to which this keyword validates successfully when applying - its subschema, in ascending order. The value MAY be a boolean true if the + its subschema, in ascending order. The value MAY be a boolean "true" if the subschema validated successfully when applied to every index of the instance. If the instance array this keywords subschema is applicable to is empty, the annotation value MUST NOT be missing. From 3cf7cb8ef83713352686a5b80f2ec9fcb16b0467 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Tue, 1 Dec 2020 11:05:34 +0000 Subject: [PATCH 267/780] Nothing to see here (fix spelling) --- jsonschema-validation.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 8e1f3cf2..797986df 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -415,7 +415,7 @@ <t> An array instance is valid against "maxContains" if its value is less than or equal to, the array length of the annotation - result from an ajacent + result from an adjacent <xref target="json-schema">"contains"</xref> keyword where the annotation is an array, or the length of the instance array where the annotation is "true". @@ -433,7 +433,7 @@ <t> An array instance is valid against "minContains" if its value is greater than or equal to, the array length of the annotation - result from an ajacent + result from an adjacent <xref target="json-schema">"contains"</xref> keyword where the annotation is an array, or the length of the instance array where the annotation is "true". From 97ea4df52ae7d81d1b2d7bd871386e497f7c4cf6 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Tue, 1 Dec 2020 15:44:41 +0000 Subject: [PATCH 268/780] Update dates and authorship --- jsonschema-core.xml | 44 +++++++++++++++++++-------------------- jsonschema-validation.xml | 30 +++++++++++++------------- relative-json-pointer.xml | 9 +++++++- 3 files changed, 46 insertions(+), 37 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d0b49e24..200faffd 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -71,7 +71,7 @@ </abstract> <note title="Note to Readers"> <t> - This document a pre-release identified as JSON Schema draft 2020-11-rc-0. + This document a pre-release identified as JSON Schema draft 2020-12-rc-1. </t> <t> The issues list for this draft can be found at @@ -1119,11 +1119,11 @@ </t> <t> The current URI for the Core vocabulary is: - <https://json-schema.org/draft/2020-11/vocab/core>. + <https://json-schema.org/draft/2020-12/vocab/core>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-11/meta/core"/>. + <eref target="https://json-schema.org/draft/2020-12/meta/core"/>. </t> <t> While the "$" prefix is not formally reserved for the Core vocabulary, @@ -2051,11 +2051,11 @@ </t> <t> The current URI for this vocabulary, known as the Applicator vocabulary, is: - <https://json-schema.org/draft/2020-11/vocab/applicator>. + <https://json-schema.org/draft/2020-12/vocab/applicator>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-11/meta/applicator"/>. + <eref target="https://json-schema.org/draft/2020-12/meta/applicator"/>. </t> <t> Updated vocabulary and meta-schema URIs MAY be published between @@ -2502,11 +2502,11 @@ <t> The current URI for this vocabulary, known as the Unevaluated Applicator vocabulary, is: - <https://json-schema.org/draft/2020-11/vocab/unevaluated>. + <https://json-schema.org/draft/2020-12/vocab/unevaluated>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-11/meta/unevaluated"/>. + <eref target="https://json-schema.org/draft/2020-12/meta/unevaluated"/>. </t> <t> Updated vocabulary and meta-schema URIs MAY be published between @@ -2786,7 +2786,7 @@ https://example.com/schemas/common#/$defs/count/minimum <![CDATA[ { "$id": "https://example.com/polygon", - "$schema": "https://json-schema.org/draft/2020-11/schema", + "$schema": "https://json-schema.org/draft/2020-12/schema", "$defs": { "point": { "type": "object", @@ -2999,7 +2999,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t> Because this output structure can be quite large, a smaller example is given here for brevity. The URI of the full output structure of the example above is: - <eref target="https://json-schema.org/draft/2020-11/output/verbose-example"/>. + <eref target="https://json-schema.org/draft/2020-12/output/verbose-example"/>. </t> <figure> <artwork> @@ -3007,7 +3007,7 @@ https://example.com/schemas/common#/$defs/count/minimum // schema { "$id": "https://example.com/polygon", - "$schema": "https://json-schema.org/draft/2020-11/schema", + "$schema": "https://json-schema.org/draft/2020-12/schema", "type": "object", "properties": { "validProp": true, @@ -3061,7 +3061,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t> For convenience, JSON Schema has been provided to validate output generated by implementations. Its URI is: - <eref target="https://json-schema.org/draft/2020-11/output/schema"/>. + <eref target="https://json-schema.org/draft/2020-12/output/schema"/>. </t> </section> @@ -3235,7 +3235,7 @@ https://example.com/schemas/common#/$defs/count/minimum <author initials="B." surname="Hutton"> <organization/> </author> - <date year="2020" month="November"/> + <date year="2020" month="December"/> </front> <seriesInfo name="Internet-Draft" value="draft-bhutton-json-schema-validation-00" /> </reference> @@ -3469,7 +3469,7 @@ https://example.com/schemas/common#/$defs/count/minimum <![CDATA[ // tree schema, extensible { - "$schema": "https://json-schema.org/draft/2020-11/schema", + "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://example.com/tree", "$dynamicAnchor": "node", @@ -3487,7 +3487,7 @@ https://example.com/schemas/common#/$defs/count/minimum // strict-tree schema, guards against misspelled properties { - "$schema": "https://json-schema.org/draft/2020-11/schema", + "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://example.com/strict-tree", "$dynamicAnchor": "node", @@ -3660,19 +3660,19 @@ https://example.com/schemas/common#/$defs/count/minimum <artwork> <![CDATA[ { - "$schema": "https://json-schema.org/draft/2020-11/schema", + "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://example.com/meta/general-use-example", "$dynamicAnchor": "meta", "$vocabulary": { - "https://json-schema.org/draft/2020-11/vocab/core": true, - "https://json-schema.org/draft/2020-11/vocab/applicator": true, - "https://json-schema.org/draft/2020-11/vocab/validation": true, + "https://json-schema.org/draft/2020-12/vocab/core": true, + "https://json-schema.org/draft/2020-12/vocab/applicator": true, + "https://json-schema.org/draft/2020-12/vocab/validation": true, "https://example.com/vocab/example-vocab": true }, "allOf": [ - {"$ref": "https://json-schema.org/draft/2020-11/meta/core"}, - {"$ref": "https://json-schema.org/draft/2020-11/meta/applicator"}, - {"$ref": "https://json-schema.org/draft/2020-11/meta/validation"}, + {"$ref": "https://json-schema.org/draft/2020-12/meta/core"}, + {"$ref": "https://json-schema.org/draft/2020-12/meta/applicator"}, + {"$ref": "https://json-schema.org/draft/2020-12/meta/validation"}, {"$ref": "https://example.com/meta/example-vocab", ], "patternProperties": { @@ -3695,7 +3695,7 @@ https://example.com/schemas/common#/$defs/count/minimum <artwork> <![CDATA[ { - "$schema": "https://json-schema.org/draft/2020-11/schema", + "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://example.com/meta/example-vocab", "$dynamicAnchor": "meta", "$vocabulary": { diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 797986df..ef825870 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -71,7 +71,7 @@ <note title="Note to Readers"> <t> - This document a pre-release identified as JSON Schema draft 2020-11-rc-0. + This document a pre-release identified as JSON Schema draft 2020-12-rc-1. </t> <t> The issues list for this draft can be found at @@ -180,7 +180,7 @@ <section title="Meta-Schema" anchor="meta-schema"> <t> The current URI for the default JSON Schema dialect meta-schema is - <eref target="https://json-schema.org/draft/2020-11/schema"/>. + <eref target="https://json-schema.org/draft/2020-12/schema"/>. For schema author convenience, this meta-schema describes a dialect consisting of all vocabularies defined in this specification and the JSON Schema Core specification, @@ -209,11 +209,11 @@ </t> <t> The current URI for this vocabulary, known as the Validation vocabulary, is: - <https://json-schema.org/draft/2020-11/vocab/validation>. + <https://json-schema.org/draft/2020-12/vocab/validation>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-11/meta/validation"/>. + <eref target="https://json-schema.org/draft/2020-12/meta/validation"/>. </t> <section title="Validation Keywords for Any Instance Type" anchor="general"> @@ -544,18 +544,18 @@ <t> The current URI for this vocabulary, known as the Format-Annotation vocabulary, is: - <https://json-schema.org/draft/2020-11/vocab/format-annotation>. The current + <https://json-schema.org/draft/2020-12/vocab/format-annotation>. The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-11/meta/format-annotation"/>. + <eref target="https://json-schema.org/draft/2020-12/meta/format-annotation"/>. Implementing support for this vocabulary is REQUIRED. </t> <t> In addition to the Format-Annotation vocabulary, a secondary vocabulary is available for custom meta-schemas that defines "format" as an assertion. The URI for the Format-Assertion vocabulary, is: - <https://json-schema.org/draft/2020-11/vocab/format-assertion>. The current + <https://json-schema.org/draft/2020-12/vocab/format-assertion>. The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-11/meta/format-assertion"/>. + <eref target="https://json-schema.org/draft/2020-12/meta/format-assertion"/>. Implementing support for the Format-Assertion vocabulary is OPTIONAL. </t> <t> @@ -916,11 +916,11 @@ </t> <t> The current URI for this vocabulary, known as the Content vocabulary, is: - <https://json-schema.org/draft/2020-11/vocab/content>. + <https://json-schema.org/draft/2020-12/vocab/content>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-11/meta/content"/>. + <eref target="https://json-schema.org/draft/2020-12/meta/content"/>. </t> </section> @@ -1116,11 +1116,11 @@ </t> <t> The current URI for this vocabulary, known as the Meta-Data vocabulary, is: - <https://json-schema.org/draft/2020-11/vocab/meta-data>. + <https://json-schema.org/draft/2020-12/vocab/meta-data>. </t> <t> The current URI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-11/meta/meta-data"/>. + <eref target="https://json-schema.org/draft/2020-12/meta/meta-data"/>. </t> <section title='"title" and "description"'> @@ -1319,7 +1319,9 @@ <author initials="H." surname="Andrews"> <organization>Cloudflare, Inc.</organization> </author> - <date year="2017" month="November"/> + <author fullname="Ben Hutton" initials="B" surname="Hutton" role="editor"> + </author> + <date year="2020" month="December"/> </front> <seriesInfo name="Internet-Draft" value="draft-handrews-relative-json-pointer-01" /> </reference> @@ -1338,7 +1340,7 @@ <author initials="G." surname="Dennis"> <organization/> </author> - <date year="2020" month="November"/> + <date year="2020" month="December"/> </front> <seriesInfo name="Internet-Draft" value="draft-bhutton-json-schema-00" /> </reference> diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 06af623c..e99e898c 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -12,7 +12,7 @@ <?rfc rfcedstyle="yes"?> <?rfc comments="yes"?> <?rfc inline="yes" ?> -<rfc category="info" docName="draft-handrews-relative-json-pointer-02" ipr="trust200902"> +<rfc category="info" docName="draft-bhutton-relative-json-pointer-00" ipr="trust200902"> <front> <title abbrev="Relative JSON Pointers">Relative JSON Pointers @@ -33,6 +33,13 @@ + +
+ ben@jsonschema.dev + https://jsonschema.dev +
+ + Internet Engineering Task Force JSON From ae2ac2abea22bbab7434cd62c87ff29bd285affd Mon Sep 17 00:00:00 2001 From: "Ryan J. Miller" Date: Tue, 1 Dec 2020 14:01:43 -0500 Subject: [PATCH 269/780] Rel JSON Pointer: add ABNF/examples for index manipulation Fixes #1048 --- relative-json-pointer.xml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 06af623c..6e439369 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -91,8 +91,9 @@ + relative-json-pointer = non-negative-integer [index-manipulation] relative-json-pointer =/ non-negative-integer "#" + index-manipulation = ("+" / "-") non-negative-integer non-negative-integer = %x30 / %x31-39 *( %x30-39 ) ; "0", or digits without a leading "0" ]]> @@ -213,8 +214,10 @@ From 1e3efbfca0ffd750b0cdcaaf261d3a4ff8903395 Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Tue, 1 Dec 2020 11:29:40 -0800 Subject: [PATCH 270/780] [1043] Clarify last paragraph in "contains" section Also fixes the "validates" tense to match the first use. --- jsonschema-core.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 200faffd..4d9d8b04 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2352,10 +2352,10 @@ This keyword produces an annotation value which is an array of the indexes to which this keyword validates successfully when applying - its subschema, in ascending order. The value MAY be a boolean "true" if the - subschema validated successfully when applied to every index of the instance. - If the instance array this keywords subschema is applicable to is empty, - the annotation value MUST NOT be missing. + its subschema, in ascending order. The value MAY be a boolean "true" if + the subschema validates successfully when applied to every index of the + instance. The annotation MUST be present if the instance array to which + this keyword's schema applies is empty.
From a0405f3883a7945ba2803635fc8fa70ae5579689 Mon Sep 17 00:00:00 2001 From: Shawn Silverman Date: Tue, 1 Dec 2020 11:57:27 -0800 Subject: [PATCH 271/780] [1044] Improve "maxContains" and "minContains" descriptions --- jsonschema-validation.xml | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index ef825870..ad488497 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -413,12 +413,13 @@ then this keyword has no effect. - An array instance is valid against "maxContains" if its - value is less than or equal to, the array length of the annotation - result from an adjacent - "contains" keyword where the - annotation is an array, or the length of the instance array - where the annotation is "true". + An instance array is valid against "maxContains" in two ways, depending on + the form of the annotation result of an adjacent + "contains" keyword. The first way is if + the annotation result is an array and the length of that array is less than + or equal to the "maxContains" value. The second way is if the annotation + result is a boolean "true" and the instance array length is less than or + equal to the "maxContains" value.
@@ -431,12 +432,13 @@ then this keyword has no effect. - An array instance is valid against "minContains" if its - value is greater than or equal to, the array length of the annotation - result from an adjacent - "contains" keyword where the - annotation is an array, or the length of the instance array - where the annotation is "true". + An instance array is valid against "minContains" in two ways, depending on + the form of the annotation result of an adjacent + "contains" keyword. The first way is if + the annotation result is an array and the length of that array is greater + than or equal to the "minContains" value. The second way is if the + annotation result is a boolean "true" and the instance array length is + greater than or equal to the "minContains" value. A value of 0 is allowed, but is only useful for setting a range From f5cc93729be60b331f624daad06250fc36ef8fb5 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 3 Dec 2020 13:01:15 -0800 Subject: [PATCH 272/780] Revert changes to dynamic scope regarding dependence on instance --- jsonschema-core.xml | 50 +++++++++++++++++++++++++-------------------- 1 file changed, 28 insertions(+), 22 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 4d9d8b04..7ac54a91 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -654,11 +654,13 @@ appear in a schema resource's root schema. - Other keywords may take into account the dynamic scope that exists during the - evaluation of a schema. The outermost dynamic scope is the root schema of the - schema document in which processing begins. The path from this root schema to - any particular keyword (that includes any "$ref" and "$dynamicRef" keywords that - may have been resolved) is considered the keyword's "validation path." + Other keywords may take into account the dynamic scope that + exists during the evaluation of a schema, typically together + with an instance document. The outermost dynamic scope is the + root schema of the schema document in which processing begins. + The path from this root schema to any particular keyword (that + includes any "$ref" and "$dynamicRef" keywords that may have + been resolved) is considered the keyword's "validation path." Lexical and dynamic scopes align until a reference keyword @@ -733,7 +735,7 @@ Canonical schema URIs MUST NOT change while processing an instance, but keywords that affect URI-reference resolution MAY have behavior that - is only fully determined dynamically. + is only fully determined at runtime. While custom identifier keywords are possible, vocabulary designers should @@ -790,10 +792,12 @@ of an instance against a schema. - For some by-reference applicators, such as "$ref", the - referenced schema can be determined by static analysis of the schema document's - lexical scope. Others, such as "$dynamicRef" (with "$dynamicAnchor"), are only - resolvable with knowledge of all the schemas in it's dynamic scope. + For some by-reference applicators, such as + "$ref", the referenced schema can be determined + by static analysis of the schema document's lexical scope. Others, + such as "$dynamicRef" (with "$dynamicAnchor"), may make use of dynamic + scoping, and therefore only be resolvable in the process of evaluating + the schema with an instance.
@@ -1462,28 +1466,30 @@ The value of the "$ref" keyword MUST be a string which is a URI-Reference. Resolved against the current URI base, it produces the URI of the schema - to apply. This resolution is safe to perform on schema load as neither other - schemas nor the instance can change how the reference resolves. + to apply. This resolution is safe to perform on schema load, as the + process of evaluating an instance cannot change how the reference resolves.
- The "$dynamicRef" keyword is an applicator that is used to reference a - dynamically identified schema. + The "$dynamicRef" keyword is an applicator that allows for deferring the + full resolution until runtime, at which point it is resolved each time it is + encountered while evaluating an instance. Together with "$dynamicAnchor", "$dynamicRef" implements a cooperative extension mechanism that is primarily useful with recursive schemas (schemas that reference themselves). Both the extension point and the - extension target are defined with "$dynamicAnchor", and only exhibit dynamic - behavior when referenced with "$dynamicRef". + runtime-determined extension target are defined with "$dynamicAnchor", + and only exhibit runtime dynamic behavior when referenced with + "$dynamicRef". - The value of the "$dynamicRef" property MUST be a string which is a - URI-Reference. Resolved against the current URI base, it produces the URI used - as the starting point for resolution. This initial resolution is safe to perform - on schema load. + The value of the "$dynamicRef" property MUST be a string which is + a URI-Reference. Resolved against the current URI base, it produces + the URI used as the starting point for runtime resolution. This initial + resolution is safe to perform on schema load. If the initially resolved starting point URI includes a fragment that @@ -1493,8 +1499,8 @@ an identically named fragment with "$dynamicAnchor". - Otherwise, its behavior is identical to "$ref", and no dynamic resolution is - needed. + Otherwise, its behavior is identical to "$ref", and no runtime + resolution is needed. For a full example using these keyword, see appendix From 6dd4b13ea20d65ada8a42a75a6a642a3d9205dc1 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 4 Dec 2020 13:02:10 +0000 Subject: [PATCH 273/780] Update changelog --- jsonschema-core.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 4d9d8b04..6810980e 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -547,8 +547,8 @@ Regular expressions SHOULD be built with the "u" flag (or equivalent) to provide - Unicode support, or processed in such a way which provides Unicode as defined - by ECMA-262. + Unicode support, or processed in such a way which provides Unicode support as + defined by ECMA-262. Furthermore, given the high disparity in regular expression constructs support, @@ -3846,8 +3846,9 @@ https://example.com/schemas/common#/$defs/count/minimum $dynamic* (previously $recursive) no longer use runtime base URI determination Define Compound Schema Documents (bundle) and processing Reference ECMA-262, 11th edition for regular expression support + Regular expression should support unicode Remove media type parameters - + Specify Unknown keywords are collected as annotations From 9a6c0b22009a9202a9479fe9f52a5d19212241c7 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 4 Dec 2020 13:39:13 +0000 Subject: [PATCH 274/780] Update changelog --- jsonschema-core.xml | 2 +- jsonschema-validation.xml | 7 +------ 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 6810980e..963a6a41 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3849,7 +3849,7 @@ https://example.com/schemas/common#/$defs/count/minimum Regular expression should support unicode Remove media type parameters Specify Unknown keywords are collected as annotations - + Moved "unevaluatedItems" and "unevaluatedProperties" from core into their own vocabulary diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index ad488497..e2b50475 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1435,12 +1435,7 @@ Clarified the set and meaning of "contentEncoding" values Reference ECMA-262, 11th edition for regular expression support Split "format" into an annotation only vocabulary and an assertion vocabulary - - - - - - + Clarify "deprecated" when applicable to arrays From 1cc25c577e1621165e586baaf486476ebed98539 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Sat, 5 Dec 2020 15:52:20 -0800 Subject: [PATCH 275/780] bump draft spec version for latest release --- meta/applicator.json | 6 +++--- meta/content.json | 6 +++--- meta/core.json | 6 +++--- meta/format-annotation.json | 6 +++--- meta/format-assertion.json | 6 +++--- meta/meta-data.json | 6 +++--- meta/unevaluated.json | 6 +++--- meta/validation.json | 6 +++--- output/schema.json | 4 ++-- schema.json | 18 +++++++++--------- 10 files changed, 35 insertions(+), 35 deletions(-) diff --git a/meta/applicator.json b/meta/applicator.json index 019fb3a1..53645d60 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2019-09/schema", - "$id": "https://json-schema.org/draft/2019-09/meta/applicator", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://json-schema.org/draft/2020-12/meta/applicator", "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/applicator": true + "https://json-schema.org/draft/2020-12/vocab/applicator": true }, "$dynamicAnchor": "meta", diff --git a/meta/content.json b/meta/content.json index e69ccdfa..fc39a966 100644 --- a/meta/content.json +++ b/meta/content.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2019-09/schema", - "$id": "https://json-schema.org/draft/2019-09/meta/content", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://json-schema.org/draft/2020-12/meta/content", "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/content": true + "https://json-schema.org/draft/2020-12/vocab/content": true }, "$dynamicAnchor": "meta", diff --git a/meta/core.json b/meta/core.json index 1313d3fb..e87bd3ec 100644 --- a/meta/core.json +++ b/meta/core.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2019-09/schema", - "$id": "https://json-schema.org/draft/2019-09/meta/core", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://json-schema.org/draft/2020-12/meta/core", "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/core": true + "https://json-schema.org/draft/2020-12/vocab/core": true }, "$dynamicAnchor": "meta", diff --git a/meta/format-annotation.json b/meta/format-annotation.json index a4080d69..51ef7ea1 100644 --- a/meta/format-annotation.json +++ b/meta/format-annotation.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2019-09/schema", - "$id": "https://json-schema.org/draft/2019-09/meta/format-annotation", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://json-schema.org/draft/2020-12/meta/format-annotation", "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/format-annotation": true + "https://json-schema.org/draft/2020-12/vocab/format-annotation": true }, "$dynamicAnchor": "meta", diff --git a/meta/format-assertion.json b/meta/format-assertion.json index ecac5c1f..5e73fd75 100644 --- a/meta/format-assertion.json +++ b/meta/format-assertion.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2019-09/schema", - "$id": "https://json-schema.org/draft/2019-09/meta/format-assertion", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://json-schema.org/draft/2020-12/meta/format-assertion", "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/format-assertion": true + "https://json-schema.org/draft/2020-12/vocab/format-assertion": true }, "$dynamicAnchor": "meta", diff --git a/meta/meta-data.json b/meta/meta-data.json index bbb171e9..05cbc22a 100644 --- a/meta/meta-data.json +++ b/meta/meta-data.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2019-09/schema", - "$id": "https://json-schema.org/draft/2019-09/meta/meta-data", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://json-schema.org/draft/2020-12/meta/meta-data", "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/meta-data": true + "https://json-schema.org/draft/2020-12/vocab/meta-data": true }, "$dynamicAnchor": "meta", diff --git a/meta/unevaluated.json b/meta/unevaluated.json index e973bd29..5f62a3ff 100644 --- a/meta/unevaluated.json +++ b/meta/unevaluated.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2019-09/schema", - "$id": "https://json-schema.org/draft/2019-09/meta/unevaluated", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://json-schema.org/draft/2020-12/meta/unevaluated", "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/unevaluated": true + "https://json-schema.org/draft/2020-12/vocab/unevaluated": true }, "$dynamicAnchor": "meta", diff --git a/meta/validation.json b/meta/validation.json index 75ba4522..edb4a301 100644 --- a/meta/validation.json +++ b/meta/validation.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2019-09/schema", - "$id": "https://json-schema.org/draft/2019-09/meta/validation", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://json-schema.org/draft/2020-12/meta/validation", "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/validation": true + "https://json-schema.org/draft/2020-12/vocab/validation": true }, "$dynamicAnchor": "meta", diff --git a/output/schema.json b/output/schema.json index 0a65f20f..1eef288a 100644 --- a/output/schema.json +++ b/output/schema.json @@ -1,6 +1,6 @@ { - "$schema": "https://json-schema.org/draft/2019-09/schema", - "$id": "https://json-schema.org/draft/2019-09/output/schema", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://json-schema.org/draft/2020-12/output/schema", "description": "A schema that validates the minimum requirements for validation output", "anyOf": [ diff --git a/schema.json b/schema.json index 8701d9d7..9235df28 100644 --- a/schema.json +++ b/schema.json @@ -1,14 +1,14 @@ { - "$schema": "https://json-schema.org/draft/2019-09/schema", - "$id": "https://json-schema.org/draft/2019-09/schema", + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://json-schema.org/draft/2020-12/schema", "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/core": true, - "https://json-schema.org/draft/2019-09/vocab/applicator": true, - "https://json-schema.org/draft/2019-09/vocab/unevaluated": true, - "https://json-schema.org/draft/2019-09/vocab/validation": true, - "https://json-schema.org/draft/2019-09/vocab/meta-data": true, - "https://json-schema.org/draft/2019-09/vocab/format-annotation": true, - "https://json-schema.org/draft/2019-09/vocab/content": true + "https://json-schema.org/draft/2020-12/vocab/core": true, + "https://json-schema.org/draft/2020-12/vocab/applicator": true, + "https://json-schema.org/draft/2020-12/vocab/unevaluated": true, + "https://json-schema.org/draft/2020-12/vocab/validation": true, + "https://json-schema.org/draft/2020-12/vocab/meta-data": true, + "https://json-schema.org/draft/2020-12/vocab/format-annotation": true, + "https://json-schema.org/draft/2020-12/vocab/content": true }, "$dynamicAnchor": "meta", From 8744c9aeaf95bbca0e44cbfecfc8a6ab86448187 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 8 Dec 2020 13:50:43 +0000 Subject: [PATCH 276/780] Fix incorrect stipulation on keyword ordering for unevaluated* keywords. Fixes #1047 --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 7e7f3fde..2bacfd2a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2549,7 +2549,7 @@ This means that "prefixItems", "items", "contains", and all in-place applicators MUST be evaluated before this keyword can be evaluated. Authors of extension keywords MUST NOT define an in-place applicator - that would need to be evaluated before this keyword. + that would need to be evaluated after this keyword. If the "unevaluatedItems" subschema is applied to any @@ -2594,7 +2594,7 @@ This means that "properties", "patternProperties", "additionalProperties", and all in-place applicators MUST be evaluated before this keyword can be evaluated. Authors of extension keywords MUST NOT define an in-place - applicator that would need to be evaluated before this keyword. + applicator that would need to be evaluated after this keyword. The annotation result of this keyword is the set of instance From e256bcae6e865f2d41181613181659dda417318d Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Tue, 1 Dec 2020 10:16:22 -0800 Subject: [PATCH 277/780] contractions are a little less formal --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 2bacfd2a..f8548d69 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1632,7 +1632,7 @@ When schemas are downloaded, - for example by a generic user-agent that doesn't know until runtime which schemas to download, + for example by a generic user-agent that does not know until runtime which schemas to download, see Usage for Hypermedia. @@ -3083,7 +3083,7 @@ https://example.com/schemas/common#/$defs/count/minimum Instances and schemas are both frequently written by untrusted third parties, to be deployed on public Internet servers. - Validators should take care that the parsing and validating against schemas doesn't consume excessive + Validators should take care that the parsing and validating against schemas does not consume excessive system resources. Validators MUST NOT fall into an infinite loop. @@ -3093,7 +3093,7 @@ https://example.com/schemas/common#/$defs/count/minimum excessive consumption of system resources in such a scenario. - Servers MUST ensure that malicious parties can't change the functionality of + Servers MUST ensure that malicious parties cannot change the functionality of existing schemas by uploading a schema with a pre-existing or very similar "$id". From de85e51d844e4a89252caaae88889b54398c1764 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Tue, 1 Dec 2020 10:19:00 -0800 Subject: [PATCH 278/780] unevaluated* is now in its own vocabulary, so move some references accordingly ..also added mention of "contains" dependence on "minContains" (specifically when its value is 0) --- jsonschema-core.xml | 36 +++++++++++++++++++++++++----------- 1 file changed, 25 insertions(+), 11 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f8548d69..6f887da5 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2083,17 +2083,11 @@ "additionalProperties", whose behavior is defined in terms of "properties" and "patternProperties" - - "unevaluatedProperties", whose behavior is defined in terms of - annotations from "properties", "patternProperties", - "additionalProperties" and itself - "items", whose behavior is defined in terms of "prefixItems" - "unevaluatedItems", whose behavior is defined in terms of annotations - from "prefixItems", "items", "contains", and itself + "contains", whose behavior is defined in terms of "minContains" @@ -2521,6 +2515,26 @@ before the next to indicate the same syntax and semantics as those listed here. + +
+ + Schema keywords typically operate independently, without + affecting each other's outcomes. However, the keywords in this + vocabulary are notable exceptions: + + + "unevaluatedItems", whose behavior is defined in terms of annotations + from "prefixItems", "items", "contains", and itself + + + "unevaluatedProperties", whose behavior is defined in terms of + annotations from "properties", "patternProperties", + "additionalProperties" and itself + + + +
+
The value of "unevaluatedItems" MUST be a valid JSON Schema. @@ -2530,7 +2544,7 @@ adjacent keywords that apply to the instance location being validated. Specifically, the annotations from "prefixItems", "items", and "contains", which can come from those keywords when they are adjacent to the - "unevaluatedItems" keyword. Those two annotations, as well as + "unevaluatedItems" keyword. Those three annotations, as well as "unevaluatedItems", can also result from any and all adjacent in-place applicator keywords. This includes but is not limited to the in-place applicators @@ -3644,10 +3658,10 @@ https://example.com/schemas/common#/$defs/count/minimum keywords in that vocabulary, is shown after the main example meta-schema. - The main example meta-schema also restricts the usage of the Applicator + The main example meta-schema also restricts the usage of the Unevaluated vocabulary by forbidding the keywords prefixed with "unevaluated", which are particularly complex to implement. This does not change the semantics - or set of keywords defined by the Applicator vocabulary. It just ensures + or set of keywords defined by the other vocabularies. It just ensures that schemas using this meta-schema that attempt to use the keywords prefixed with "unevaluated" will fail validation against this meta-schema. @@ -3682,7 +3696,7 @@ https://example.com/schemas/common#/$defs/count/minimum {"$ref": "https://example.com/meta/example-vocab", ], "patternProperties": { - "^unevaluated.*$": false + "^unevaluated": false }, "properties": { "localKeyword": { From 328c0b23f8a9a538665995760fe95c7a96883ef2 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Tue, 1 Dec 2020 10:23:55 -0800 Subject: [PATCH 279/780] it is no longer the evaluator's responsibility to combine annotations similar changes were made in #787. --- jsonschema-core.xml | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 6f887da5..a4fd6563 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2374,10 +2374,7 @@ The annotation result of this keyword is the set of instance - property names matched by this keyword. Annotation results - for "properties" keywords from multiple schemas applied to - the same instance location are combined by taking the union - of the sets. + property names matched by this keyword. Omitting this keyword has the same assertion behavior as @@ -2400,10 +2397,7 @@ The annotation result of this keyword is the set of instance - property names matched by this keyword. Annotation results - for "patternProperties" keywords from multiple schemas applied to - the same instance location are combined by taking the union - of the sets. + property names matched by this keyword. Omitting this keyword has the same assertion behavior as @@ -2430,9 +2424,6 @@ The annotation result of this keyword is the set of instance property names validated by this keyword's subschema. - Annotation results for "additionalProperties" keywords from - multiple schemas applied to the same instance location are combined - by taking the union of the sets. Omitting this keyword has the same assertion behavior as @@ -2613,9 +2604,6 @@ The annotation result of this keyword is the set of instance property names validated by this keyword's subschema. - Annotation results for "unevaluatedProperties" keywords from - multiple schemas applied to the same instance location are combined - by taking the union of the sets. Omitting this keyword has the same assertion behavior as From af9009b36820dfcdfba1fd2b198df34b86b6bae7 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Tue, 1 Dec 2020 10:25:10 -0800 Subject: [PATCH 280/780] clarify the requirements to implement the different output formats --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index a4fd6563..d8d4864f 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2650,10 +2650,10 @@ structure that matches the exact structure of the schema. - An implementation SHOULD provide at least the "flag", "basic", or "detailed" + An implementation SHOULD provide at least one of the "flag", "basic", or "detailed" format and MAY provide the "verbose" format. If it provides one or more of the - complex formats, it MUST also provide the "flag" format. Implementations SHOULD - specify in their documentation which formats they support. + "detailed" or "verbose" formats, it MUST also provide the "flag" format. + Implementations SHOULD specify in their documentation which formats they support.
From 713c353b9f6541748bf107ccafc256940a9bfde5 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Tue, 1 Dec 2020 10:26:06 -0800 Subject: [PATCH 281/780] soften wording on absoluteKeywordLocation it is not strictly true that there will *always* be a fragment in this field: an error might occur at the schema resource root itself (for example if the subschema is "false") --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d8d4864f..0d713ddd 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2706,7 +2706,7 @@ Note that "absolute" here is in the sense of "absolute filesystem path" (meaning the complete location) rather than the "absolute-URI" terminology from RFC 3986 (meaning with scheme but without fragment). - Keyword absolute locations will always have a fragment in order to + Keyword absolute locations will have a fragment in order to identify the keyword. From 9e96dda6c71697afc459b812aabc084ae75eef58 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Tue, 1 Dec 2020 10:27:55 -0800 Subject: [PATCH 282/780] clarify "relative location" wording keywordLocation does not always contain a relative location that actually exists in a schema - because of reference navigation, its path contains keywords from multiple locations --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0d713ddd..262fb7ef 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2718,8 +2718,8 @@ https://example.com/schemas/common#/$defs/count/minimum - This information MAY be omitted only if either the relative location contains - no references or if the schema does not declare an absolute URI as its "$id". + This information MAY be omitted only if either the dynamic scope did not pass + over a reference or if the schema does not declare an absolute URI as its "$id". The JSON key for this information is "absoluteKeywordLocation". From f21d2b3df5e099561edfe5c1b0ec2140b1e3ac21 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Tue, 1 Dec 2020 10:28:50 -0800 Subject: [PATCH 283/780] capitalize words for emphasis, per RFC 2119 --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 262fb7ef..371a6b4d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3601,9 +3601,9 @@ https://example.com/schemas/common#/$defs/count/minimum behavior is undefined. - Vocabulary authors should provide a meta-schema that validates the + Vocabulary authors SHOULD provide a meta-schema that validates the expected usage of the vocabulary's keywords on their own. Such meta-schemas - should not forbid additional keywords, and must not forbid any + SHOULD not forbid additional keywords, and MUST not forbid any keywords from the Core vocabulary. From 8cdaf1acb9223921ee73ac89c9020358d8b8bce1 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Tue, 1 Dec 2020 10:58:41 -0800 Subject: [PATCH 284/780] evaluation does not always begin at a root schema resource for example, if we start evaluating at "https://foo.com/schema.json#/$defs/Foo" and /$defs/Foo does not contain an $id keyword --- jsonschema-core.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 371a6b4d..f4bd28ab 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -656,8 +656,9 @@ Other keywords may take into account the dynamic scope that exists during the evaluation of a schema, typically together - with an instance document. The outermost dynamic scope is the - root schema of the schema document in which processing begins. + with an instance document. + The outermost dynamic scope is the schema object at + which processing begins, even if it is not a schema resource root. The path from this root schema to any particular keyword (that includes any "$ref" and "$dynamicRef" keywords that may have been resolved) is considered the keyword's "validation path." From 600a2ecbbc0ac394c56170e8186d3a4f953dd691 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 8 Dec 2020 22:32:23 +0000 Subject: [PATCH 285/780] Remove unused changelog line --- jsonschema-validation.xml | 1 - 1 file changed, 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index e2b50475..01c53035 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1436,7 +1436,6 @@ Reference ECMA-262, 11th edition for regular expression support Split "format" into an annotation only vocabulary and an assertion vocabulary Clarify "deprecated" when applicable to arrays - From dded51ce748268968689ab68dc5d0212526a83d3 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 8 Dec 2020 22:33:06 +0000 Subject: [PATCH 286/780] Correctly identify relative json pointer changelog section header --- relative-json-pointer.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 1020c518..eae53246 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -328,7 +328,7 @@ - + Add array forward and backward index manipulation From 92dcee6ee2f8f1a3de04bbbae9821bbb7a48bcfc Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 8 Dec 2020 22:37:11 +0000 Subject: [PATCH 287/780] Move hyper-schema related XML and JSON to archive. Plan is to later migrate hyper-schema to its own repo --- hyper-schema.json => archive/hyper-schema.json | 0 jsonschema-hyperschema.xml => archive/jsonschema-hyperschema.xml | 0 links.json => archive/links.json | 0 meta/{ => archive}/hyper-schema.json | 0 4 files changed, 0 insertions(+), 0 deletions(-) rename hyper-schema.json => archive/hyper-schema.json (100%) rename jsonschema-hyperschema.xml => archive/jsonschema-hyperschema.xml (100%) rename links.json => archive/links.json (100%) rename meta/{ => archive}/hyper-schema.json (100%) diff --git a/hyper-schema.json b/archive/hyper-schema.json similarity index 100% rename from hyper-schema.json rename to archive/hyper-schema.json diff --git a/jsonschema-hyperschema.xml b/archive/jsonschema-hyperschema.xml similarity index 100% rename from jsonschema-hyperschema.xml rename to archive/jsonschema-hyperschema.xml diff --git a/links.json b/archive/links.json similarity index 100% rename from links.json rename to archive/links.json diff --git a/meta/hyper-schema.json b/meta/archive/hyper-schema.json similarity index 100% rename from meta/hyper-schema.json rename to meta/archive/hyper-schema.json From f0e4e3781b45d5d83423c7161279ed46fc5a9013 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 8 Dec 2020 22:42:00 +0000 Subject: [PATCH 288/780] Add comments to hyper-schema schemas and vocabularies and migrate them to an archive folder. --- README.md | 5 ++--- archive/hyper-schema.json | 1 + archive/links.json | 1 + {meta/archive => archive/meta}/hyper-schema.json | 1 + 4 files changed, 5 insertions(+), 3 deletions(-) rename {meta/archive => archive/meta}/hyper-schema.json (84%) diff --git a/README.md b/README.md index 5b42c293..69147dea 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ # Welcome to JSON Schema -[![Financial Contributors on Open Collective](https://opencollective.com/json-schema/all/badge.svg?label=financial+contributors)](https://opencollective.com/json-schema) +[![Financial Contributors on Open Collective](https://opencollective.com/json-schema/all/badge.svg?label=financial+contributors)](https://opencollective.com/json-schema) JSON Schema is a vocabulary that allows you to validate, annotate, and manipulate JSON documents. @@ -17,7 +17,7 @@ For the current status of issues and pull requests, please see the following lab [![Available](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20Available.svg?color=brightgreen)](https://github.com/json-schema-org/json-schema-spec/issues?q=is%3Aopen+is%3Aissue+label%3A%22Status%3A+Available%22) [![In Progress](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20In%20Progress.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Status:%20In%20Progress) [![Review Needed](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20Review%20Needed.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Status%3A%20Review%20Needed) [![Critical](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Critical.svg?color=critical -)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Critical) [![High](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20High.svg?color=important)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20High) [![Medium](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Medium.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Medium) [![Low](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Low.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Low) +)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Critical) [![High](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20High.svg?color=important)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20High) [![Medium](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Medium.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Medium) [![Low](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Low.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Low) Labels are assigned based on [Sensible Github Labels](https://github.com/Relequestual/sensible-github-labels). @@ -28,7 +28,6 @@ Labels are assigned based on [Sensible Github Labels](https://github.com/Releque * _Internet-Draft sources_ * jsonschema-core.xml - source for JSON Schema's "core" I-D * jsonschema-validation.xml - source for the validation vocabulary I-D - * jsonschema-hyperschema.xml - source for the hyper-schema vocabulary I-D * relative-json-pointer.xml - source for the Relative JSON Pointer I-D * _meta-schemas and recommended output formats_ * schema.json - JSON Schema "core" and Validation meta-schema diff --git a/archive/hyper-schema.json b/archive/hyper-schema.json index 74c6bec7..7558b6f3 100644 --- a/archive/hyper-schema.json +++ b/archive/hyper-schema.json @@ -1,4 +1,5 @@ { + "$comment": "This file represents a work in progress and may not be a complete or valid 2019-09 / 2020-12 schema or vocabulary", "$schema": "https://json-schema.org/draft/2019-09/hyper-schema", "$id": "https://json-schema.org/draft/2019-09/hyper-schema", "$vocabulary": { diff --git a/archive/links.json b/archive/links.json index 07ad7a42..8474f117 100644 --- a/archive/links.json +++ b/archive/links.json @@ -1,4 +1,5 @@ { + "$comment": "This file represents a work in progress and may not be a complete or valid 2019-09 / 2020-12 schema or vocabulary", "$schema": "https://json-schema.org/draft/2019-09/hyper-schema", "$id": "https://json-schema.org/draft/2019-09/links", "title": "Link Description Object", diff --git a/meta/archive/hyper-schema.json b/archive/meta/hyper-schema.json similarity index 84% rename from meta/archive/hyper-schema.json rename to archive/meta/hyper-schema.json index f36d3477..8bf7ac73 100644 --- a/meta/archive/hyper-schema.json +++ b/archive/meta/hyper-schema.json @@ -1,4 +1,5 @@ { + "$comment": "This file represents a work in progress and may not be a complete or valid 2019-09 / 2020-12 schema or vocabulary", "$schema": "https://json-schema.org/draft/2019-09/hyper-schema", "$id": "https://json-schema.org/draft/2019-09/meta/hyper-schema", "$vocabulary": { From 2ad7af57238b996f95b56b3cfe432c12b5638b82 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 8 Dec 2020 22:43:57 +0000 Subject: [PATCH 289/780] No Longer need to make hyperschema --- Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 3699d8f1..a85e82ce 100644 --- a/Makefile +++ b/Makefile @@ -3,9 +3,8 @@ XML2RFC=xml2rfc OUT = \ jsonschema-core.html jsonschema-core.txt \ jsonschema-validation.html jsonschema-validation.txt \ - jsonschema-hyperschema.html jsonschema-hyperschema.txt \ relative-json-pointer.html relative-json-pointer.txt - + all: $(OUT) From 6c5b6729ce7482072404b09c02533291e9c528c7 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 8 Dec 2020 23:02:14 +0000 Subject: [PATCH 290/780] Remove notice on the specs being an RC --- jsonschema-core.xml | 3 --- jsonschema-validation.xml | 3 --- 2 files changed, 6 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f4bd28ab..e6b5476e 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -70,9 +70,6 @@ - - This document a pre-release identified as JSON Schema draft 2020-12-rc-1. - The issues list for this draft can be found at . diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 01c53035..b8d68d69 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -70,9 +70,6 @@ - - This document a pre-release identified as JSON Schema draft 2020-12-rc-1. - The issues list for this draft can be found at . From fa873b95427d34eed806306ae54d47bb52092cd0 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 9 Dec 2020 21:33:29 +1300 Subject: [PATCH 291/780] updated base and core meta-schemas --- meta/core.json | 47 +++++++++++++++++++++-------------------------- schema.json | 13 +++++++++++-- 2 files changed, 32 insertions(+), 28 deletions(-) diff --git a/meta/core.json b/meta/core.json index e87bd3ec..7b5758b1 100644 --- a/meta/core.json +++ b/meta/core.json @@ -10,37 +10,18 @@ "type": ["object", "boolean"], "properties": { "$id": { - "type": "string", - "format": "uri-reference", + "$ref": "#/$defs/uriReferenceString", "$comment": "Non-empty fragments not allowed.", "pattern": "^[^#]*#?$" }, - "$schema": { - "type": "string", - "format": "uri" - }, - "$anchor": { - "type": "string", - "pattern": "^[A-Za-z_][-A-Za-z0-9._]*$" - }, - "$ref": { - "type": "string", - "format": "uri-reference" - }, - "$dynamicRef": { - "type": "string", - "format": "uri-reference" - }, - "$dynamicAnchor": { - "type": "string", - "pattern": "^[A-Za-z_][-A-Za-z0-9._]*$" - }, + "$schema": { "$ref": "#/$defs/uriString" }, + "$ref": { "$ref": "#/$defs/uriReferenceString" }, + "$anchor": { "$ref": "#/$defs/anchorString" }, + "$dynamicRef": { "$ref": "#/$defs/uriReferenceString" }, + "$dynamicAnchor": { "$ref": "#/$defs/anchorString" }, "$vocabulary": { "type": "object", - "propertyNames": { - "type": "string", - "format": "uri" - }, + "propertyNames": { "$ref": "#/$defs/uriString" }, "additionalProperties": { "type": "boolean" } @@ -53,5 +34,19 @@ "additionalProperties": { "$dynamicRef": "#meta" }, "default": {} } + }, + "$defs": { + "anchorString": { + "type": "string", + "pattern": "^[A-Za-z_][-A-Za-z0-9._]*$" + }, + "uriString": { + "type": "string", + "format": "uri" + }, + "uriReferenceString": { + "type": "string", + "format": "uri-reference" + } } } diff --git a/schema.json b/schema.json index 9235df28..84baf106 100644 --- a/schema.json +++ b/schema.json @@ -22,15 +22,16 @@ {"$ref": "meta/content"} ], "type": ["object", "boolean"], + "$comment": "This meta-schema also defines keywords that have appeared in previous drafts in order to prevent incompatible extensions as they remain in common use.", "properties": { "definitions": { - "$comment": "While no longer an official keyword as it is replaced by $defs, this keyword is retained in the meta-schema to prevent incompatible extensions as it remains in common use.", + "$comment": "\"definitions\" has been replaced by \"$defs\".", "type": "object", "additionalProperties": { "$dynamicRef": "#meta" }, "default": {} }, "dependencies": { - "$comment": "\"dependencies\" is no longer a keyword, but schema authors should avoid redefining it to facilitate a smooth transition to \"dependentSchemas\" and \"dependentRequired\"", + "$comment": "\"dependencies\" has been split and replaced by \"dependentSchemas\" and \"dependentRequired\" in order to serve their differing semantics.", "type": "object", "additionalProperties": { "anyOf": [ @@ -38,6 +39,14 @@ { "$ref": "meta/validation#/$defs/stringArray" } ] } + }, + "$recursiveAnchor": { + "$comment": "\"$recursiveAnchor\" has been replaced by \"$dynamicAnchor\".", + "$ref": "meta/core#/$defs/anchorString" + }, + "$recursiveRef": { + "$comment": "\"$recursiveRef\" has been replaced by \"$dynamicRef\".", + "$ref": "meta/core#/$defs/uriReferenceString" } } } From b7f1819bcd04d64733c51c76167142f04554b977 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 9 Dec 2020 21:51:03 +1300 Subject: [PATCH 292/780] updated applicator - added defaults; reformatted --- meta/applicator.json | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/meta/applicator.json b/meta/applicator.json index 53645d60..ff2cfc2f 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -12,7 +12,10 @@ "prefixItems": { "$ref": "#/$defs/schemaArray" }, "items": { "$dynamicRef": "#meta" }, "contains": { "$dynamicRef": "#meta" }, - "additionalProperties": { "$dynamicRef": "#meta" }, + "additionalProperties": { + "$dynamicRef": "#meta", + "default": {} + }, "properties": { "type": "object", "additionalProperties": { "$dynamicRef": "#meta" }, @@ -26,11 +29,13 @@ }, "dependentSchemas": { "type": "object", - "additionalProperties": { - "$dynamicRef": "#meta" - } + "additionalProperties": { "$dynamicRef": "#meta" }, + "default": {} + }, + "propertyNames": { + "$dynamicRef": "#meta", + "default": {} }, - "propertyNames": { "$dynamicRef": "#meta" }, "if": { "$dynamicRef": "#meta" }, "then": { "$dynamicRef": "#meta" }, "else": { "$dynamicRef": "#meta" }, From 464182fe0ce56ce5ee5ab0344350307849b2e733 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 9 Dec 2020 22:07:47 +1300 Subject: [PATCH 293/780] reorganized validation meta-schema to match order in spec --- meta/validation.json | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/meta/validation.json b/meta/validation.json index edb4a301..606b87ba 100644 --- a/meta/validation.json +++ b/meta/validation.json @@ -9,6 +9,22 @@ "title": "Validation vocabulary meta-schema", "type": ["object", "boolean"], "properties": { + "type": { + "anyOf": [ + { "$ref": "#/$defs/simpleTypes" }, + { + "type": "array", + "items": { "$ref": "#/$defs/simpleTypes" }, + "minItems": 1, + "uniqueItems": true + } + ] + }, + "const": true, + "enum": { + "type": "array", + "items": true + }, "multipleOf": { "type": "number", "exclusiveMinimum": 0 @@ -50,22 +66,6 @@ "additionalProperties": { "$ref": "#/$defs/stringArray" } - }, - "const": true, - "enum": { - "type": "array", - "items": true - }, - "type": { - "anyOf": [ - { "$ref": "#/$defs/simpleTypes" }, - { - "type": "array", - "items": { "$ref": "#/$defs/simpleTypes" }, - "minItems": 1, - "uniqueItems": true - } - ] } }, "$defs": { From 585f0e575dbd410bb33ce518a41c34ee490efc99 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 9 Dec 2020 22:19:45 +1300 Subject: [PATCH 294/780] reorganized content meta-schema to match order in spec (and happily alphabetized) --- meta/content.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/content.json b/meta/content.json index fc39a966..2f6e056a 100644 --- a/meta/content.json +++ b/meta/content.json @@ -10,8 +10,8 @@ "type": ["object", "boolean"], "properties": { - "contentMediaType": { "type": "string" }, "contentEncoding": { "type": "string" }, + "contentMediaType": { "type": "string" }, "contentSchema": { "$dynamicRef": "#meta" } } } From 7647c6f369ba59feefd69ab80db5d72fc24d309c Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 9 Dec 2020 22:24:42 +1300 Subject: [PATCH 295/780] added deprecated to old keywords --- schema.json | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/schema.json b/schema.json index 84baf106..ca910847 100644 --- a/schema.json +++ b/schema.json @@ -28,7 +28,8 @@ "$comment": "\"definitions\" has been replaced by \"$defs\".", "type": "object", "additionalProperties": { "$dynamicRef": "#meta" }, - "default": {} + "default": {}, + "deprecated": true }, "dependencies": { "$comment": "\"dependencies\" has been split and replaced by \"dependentSchemas\" and \"dependentRequired\" in order to serve their differing semantics.", @@ -38,15 +39,18 @@ { "$dynamicRef": "#meta" }, { "$ref": "meta/validation#/$defs/stringArray" } ] - } + }, + "deprecated": true }, "$recursiveAnchor": { "$comment": "\"$recursiveAnchor\" has been replaced by \"$dynamicAnchor\".", - "$ref": "meta/core#/$defs/anchorString" + "$ref": "meta/core#/$defs/anchorString", + "deprecated": true }, "$recursiveRef": { "$comment": "\"$recursiveRef\" has been replaced by \"$dynamicRef\".", - "$ref": "meta/core#/$defs/uriReferenceString" + "$ref": "meta/core#/$defs/uriReferenceString", + "deprecated": true } } } From 0612ad6a5d4c47ca3b163df23e0b4148c91b5c6c Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 17 Jan 2021 15:29:52 +1300 Subject: [PATCH 296/780] added unevaluated meta-schema to allOf list in primary meta-schema --- schema.json | 1 + 1 file changed, 1 insertion(+) diff --git a/schema.json b/schema.json index ca910847..a88709f7 100644 --- a/schema.json +++ b/schema.json @@ -16,6 +16,7 @@ "allOf": [ {"$ref": "meta/core"}, {"$ref": "meta/applicator"}, + {"$ref": "meta/unevaluated"}, {"$ref": "meta/validation"}, {"$ref": "meta/meta-data"}, {"$ref": "meta/format-annotation"}, From 0e08f03573753bebe2841023dd6fcc822490ea07 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Wed, 27 Jan 2021 05:29:22 -0800 Subject: [PATCH 297/780] Add or remove defaults as appropriate including where redundant (#1006) - Remove `default` from all subschemas that recursively-reference #meta - Add `default to `dependencies` Remove, e.g. when evaluating the "not" keyword, the subschema inside it should *not* be true, as that would produce a false result from this keyword. --- meta/applicator.json | 10 ++-------- meta/core.json | 3 +-- schema.json | 7 ++++--- 3 files changed, 7 insertions(+), 13 deletions(-) diff --git a/meta/applicator.json b/meta/applicator.json index ff2cfc2f..ca699230 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -12,10 +12,7 @@ "prefixItems": { "$ref": "#/$defs/schemaArray" }, "items": { "$dynamicRef": "#meta" }, "contains": { "$dynamicRef": "#meta" }, - "additionalProperties": { - "$dynamicRef": "#meta", - "default": {} - }, + "additionalProperties": { "$dynamicRef": "#meta" }, "properties": { "type": "object", "additionalProperties": { "$dynamicRef": "#meta" }, @@ -32,10 +29,7 @@ "additionalProperties": { "$dynamicRef": "#meta" }, "default": {} }, - "propertyNames": { - "$dynamicRef": "#meta", - "default": {} - }, + "propertyNames": { "$dynamicRef": "#meta" }, "if": { "$dynamicRef": "#meta" }, "then": { "$dynamicRef": "#meta" }, "else": { "$dynamicRef": "#meta" }, diff --git a/meta/core.json b/meta/core.json index 7b5758b1..dfc092d9 100644 --- a/meta/core.json +++ b/meta/core.json @@ -31,8 +31,7 @@ }, "$defs": { "type": "object", - "additionalProperties": { "$dynamicRef": "#meta" }, - "default": {} + "additionalProperties": { "$dynamicRef": "#meta" } } }, "$defs": { diff --git a/schema.json b/schema.json index a88709f7..d5e2d31c 100644 --- a/schema.json +++ b/schema.json @@ -29,8 +29,8 @@ "$comment": "\"definitions\" has been replaced by \"$defs\".", "type": "object", "additionalProperties": { "$dynamicRef": "#meta" }, - "default": {}, - "deprecated": true + "deprecated": true, + "default": {} }, "dependencies": { "$comment": "\"dependencies\" has been split and replaced by \"dependentSchemas\" and \"dependentRequired\" in order to serve their differing semantics.", @@ -41,7 +41,8 @@ { "$ref": "meta/validation#/$defs/stringArray" } ] }, - "deprecated": true + "deprecated": true, + "default": {} }, "$recursiveAnchor": { "$comment": "\"$recursiveAnchor\" has been replaced by \"$dynamicAnchor\".", From 28b236d390ef7a837048a7c602ca8e24c9d7f941 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 25 Mar 2021 14:44:46 -0700 Subject: [PATCH 298/780] Improve wording for the type keyword in the spec --- jsonschema-validation.xml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index b8d68d69..ef277947 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -225,8 +225,11 @@ or "integer" which matches any number with a zero fractional part. - An instance validates if and only if the instance is in any of the sets listed - for this keyword. + If the value of "type" is a string, then an instance validates successfully if + its type matches the type represented by the value of the string. + + If the value of "type" is an array, then an instance validates successfully if + its type matches any of the types indicated by the strings in the array.
From 60601c59dce0d6e1c7bbc89d7e3885ca3262b300 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Thu, 8 Apr 2021 10:37:02 -0700 Subject: [PATCH 299/780] fix example of Keyword Relative Location --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e6b5476e..f5e63d6a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2679,7 +2679,7 @@
From a39c90b3b810b87f06545e6a43142d3d6914a13b Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 11 May 2021 10:28:17 -0700 Subject: [PATCH 300/780] Update years to 2021 --- jsonschema-core.xml | 2 +- jsonschema-validation.xml | 2 +- relative-json-pointer.xml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e6b5476e..01c46242 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -50,7 +50,7 @@ - + Internet Engineering Task Force JSON Schema diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index ef277947..e12c6cd2 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -53,7 +53,7 @@ - + Internet Engineering Task Force JSON Schema diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index eae53246..03654ef3 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -40,7 +40,7 @@ - + Internet Engineering Task Force JSON JavaScript From 8c4299941acd110c30a4e59a62c9ac79314f540e Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 11 May 2021 11:38:59 -0700 Subject: [PATCH 301/780] Clarify vocab specs needn't be formal or published. --- jsonschema-core.xml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index a93c377d..88561c39 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -399,6 +399,13 @@ of any vocabulary, there is no analogous mechanism to indicate individual keyword usage. + + A schema vocabulary can be defined by anything from an informal description + to a standards proposal, depending on the audience and interoperability + expectations. In particular, in order to facilitate vocabulary use within + non-public organizations, a vocabulary specification need not be published + outside of its scope of use. +
From 6a4183ef2d46d9c65aa0ea56a2e4003eddbca263 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 11 May 2021 10:28:30 -0700 Subject: [PATCH 302/780] Remove redundant meta-schema update process notes This is covered for the entire spec as section 8.1.3. Note that the validation spec also has this, but only once in that document, so nothing else needs deleting. --- jsonschema-core.xml | 14 -------------- 1 file changed, 14 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index a93c377d..c73f0ce1 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2061,13 +2061,6 @@ The current URI for the corresponding meta-schema is: . - - Updated vocabulary and meta-schema URIs MAY be published between - specification drafts in order to correct errors. Implementations - SHOULD consider URIs dated after this specification draft and - before the next to indicate the same syntax and semantics - as those listed here. -
Schema keywords typically operate independently, without @@ -2497,13 +2490,6 @@ The current URI for the corresponding meta-schema is: . - - Updated vocabulary and meta-schema URIs MAY be published between - specification drafts in order to correct errors. Implementations - SHOULD consider URIs dated after this specification draft and - before the next to indicate the same syntax and semantics - as those listed here. -
From aa0cca68177db58ede11ef1f32b2dc82aa119fc3 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 9 Nov 2021 14:37:06 +0000 Subject: [PATCH 303/780] Defines what happens when relative JSON pointer starts with zero --- relative-json-pointer.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 03654ef3..02855426 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -125,8 +125,9 @@ Evaluation begins by processing the non-negative-integer prefix. This can be found by taking the longest continuous sequence of decimal digits available, starting from the beginning of the string, taking - the decimal numerical value. If this value is more than zero, then - the following steps are repeated that number of times: + the decimal numerical value. If the value is zero, the following stepps + are skipped. If this value is more than zero, then the following steps + are repeated that number of times: If the current referenced value is the root of the document, then From 770e7f5f917bf7f6a9e10932cccb7e7f7ca7a7b2 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 9 Nov 2021 06:47:37 -0800 Subject: [PATCH 304/780] Clarify the origin of contentEncoding (#1117) It is related to MIME's Content-Transfer-Encoding, and not HTTP's Content-Encoding. --- jsonschema-validation.xml | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index e12c6cd2..fb244a0a 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -964,7 +964,7 @@ If the instance value is a string, this property defines that the string - SHOULD be interpreted as binary data and decoded using the encoding + SHOULD be interpreted as encoded binary data and decoded using the encoding named by this property. @@ -972,7 +972,13 @@ Possible values indicating base 16, 32, and 64 encodings with several variations are listed in RFC 4648. Additionally, sections 6.7 and 6.8 of RFC 2045 provide - encodings used in MIME. As "base64" is defined in both RFCs, the definition + encodings used in MIME. This keyword is derived from MIME's + Content-Transfer-Encoding header, which was designed to map binary data + into ASCII characters. It is not related to HTTP's Content-Encoding header, + which is used for compressing HTTP request and response payloads. + + + As "base64" is defined in both RFCs, the definition from RFC 4648 SHOULD be assumed unless the string is specifically intended for use in a MIME context. Note that all of these encodings result in strings consisting only of 7-bit ASCII characters. Therefore, this keyword From 43aa7f1ff4b56fcb88489f1696fe6aa01e0d218f Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 11 Nov 2021 13:15:12 +0000 Subject: [PATCH 305/780] Update relative-json-pointer.xml Fix typo! Co-authored-by: Ethan <133719+notEthan@users.noreply.github.com> --- relative-json-pointer.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 02855426..1bd0121a 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -125,7 +125,7 @@ Evaluation begins by processing the non-negative-integer prefix. This can be found by taking the longest continuous sequence of decimal digits available, starting from the beginning of the string, taking - the decimal numerical value. If the value is zero, the following stepps + the decimal numerical value. If the value is zero, the following steps are skipped. If this value is more than zero, then the following steps are repeated that number of times: From 8eb04a8b5ef1bea4099eb02e4451f2fe863fc223 Mon Sep 17 00:00:00 2001 From: Roberto Polli Date: Fri, 19 Nov 2021 16:43:58 +0100 Subject: [PATCH 306/780] Nitpick content-encoding. See #1100 (#1150) * Nitpick content-encoding. See #1100 * Update jsonschema-validation.xml --- jsonschema-validation.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index fb244a0a..9abdc1de 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -975,7 +975,8 @@ encodings used in MIME. This keyword is derived from MIME's Content-Transfer-Encoding header, which was designed to map binary data into ASCII characters. It is not related to HTTP's Content-Encoding header, - which is used for compressing HTTP request and response payloads. + which is used to encode (e.g. compress or encrypt) + the content of HTTP request and responses. As "base64" is defined in both RFCs, the definition From 0f43deb5a6ab9f32383bf33f7fbee390569f7377 Mon Sep 17 00:00:00 2001 From: Juan Cruz Viotti Date: Thu, 30 Dec 2021 14:24:48 -0400 Subject: [PATCH 307/780] Add missing closing curly brace to D.2. example We also remove the trailing comma. See: https://github.com/json-schema-org/json-schema-spec/pull/1162 Signed-off-by: Juan Cruz Viotti --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 49df09c2..c38ff1c8 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3672,7 +3672,7 @@ https://example.com/schemas/common#/$defs/count/minimum {"$ref": "https://json-schema.org/draft/2020-12/meta/core"}, {"$ref": "https://json-schema.org/draft/2020-12/meta/applicator"}, {"$ref": "https://json-schema.org/draft/2020-12/meta/validation"}, - {"$ref": "https://example.com/meta/example-vocab", + {"$ref": "https://example.com/meta/example-vocab"} ], "patternProperties": { "^unevaluated": false From e0c6563aeb3e9605f9326ad1dd2961de2ec6b742 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Mon, 31 May 2021 14:30:11 -0700 Subject: [PATCH 308/780] mention that annotations from these keywords affect unevaluated* --- jsonschema-core.xml | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index c38ff1c8..28f24051 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2318,6 +2318,8 @@ positions within the instance array, it produces an annotation result of boolean true, indicating that all remaining array elements have been evaluated against this keyword's subschema. + This annotation affects the behavior of "unevaluatedItems" in the + Unevaluated vocabulary. Omitting this keyword has the same assertion behavior as @@ -2354,6 +2356,8 @@ the subschema validates successfully when applied to every index of the instance. The annotation MUST be present if the instance array to which this keyword's schema applies is empty. + This annotation affects the behavior of "unevaluatedItems" in the + Unevaluated vocabulary.
@@ -2373,6 +2377,8 @@ The annotation result of this keyword is the set of instance property names matched by this keyword. + This annotation affects the behavior of "additionalProperties" (in + this vocabulary) and "unevaluatedProperties" in the Unevaluated vocabulary. Omitting this keyword has the same assertion behavior as @@ -2396,6 +2402,8 @@ The annotation result of this keyword is the set of instance property names matched by this keyword. + This annotation affects the behavior of "additionalProperties" (in this + vocabulary) and "unevaluatedProperties" (in the Unevaluated vocabulary). Omitting this keyword has the same assertion behavior as @@ -2422,6 +2430,8 @@ The annotation result of this keyword is the set of instance property names validated by this keyword's subschema. + This annotation affects the behavior of "unevaluatedProperties" + in the Unevaluated vocabulary. Omitting this keyword has the same assertion behavior as @@ -2552,6 +2562,7 @@ positions within the instance array, it produces an annotation result of boolean true, analogous to the behavior of "items". + This annotation affects the behavior of "unevaluatedItems" in parent schemas. Omitting this keyword has the same assertion behavior as @@ -2595,6 +2606,7 @@ The annotation result of this keyword is the set of instance property names validated by this keyword's subschema. + This annotation affects the behavior of "unevaluatedProperties" in parent schemas. Omitting this keyword has the same assertion behavior as From cff5ac196b8092365c27d515663f9cf19095eda2 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Mon, 31 May 2021 14:37:53 -0700 Subject: [PATCH 309/780] remove uses of "production" when discussing format rules RFC3339 refers to these as "formats". The XML xs:NCName specification refers to it as a "type". We are tying our implementation to the ABNF rules explicitly, so refer to those. --- jsonschema-validation.xml | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 9abdc1de..f1c5721c 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -704,30 +704,34 @@ A string instance is valid against this attribute if it is - a valid representation according to the "date-time" production. + a valid representation according to the "date-time' ABNF rule + (referenced above) A string instance is valid against this attribute if it is - a valid representation according to the "full-date" production. + a valid representation according to the "full-date" ABNF rule + (referenced above) A string instance is valid against this attribute if it is - a valid representation according to the "full-time" production. + a valid representation according to the "full-time" ABNF rule + (referenced above) A string instance is valid against this attribute if it is - a valid representation according to the "duration" production. + a valid representation according to the "duration" ABNF rule + (referenced above) Implementations MAY support additional attributes using the other - production names defined anywhere in that RFC. If "full-date" or "full-time" + format names defined anywhere in that RFC. If "full-date" or "full-time" are implemented, the corresponding short form ("date" or "time" respectively) MUST be implemented, and MUST behave identically. Implementations SHOULD NOT define extension attributes - with any name matching an RFC 3339 production unless it validates - according to the rules of that production. + with any name matching an RFC 3339 format unless it validates + according to the rules of that format. There is not currently consensus on the need for supporting all RFC 3339 formats, so this approach of reserving the From 44f5b82735da88ad51929a4350dea456d6fadf40 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Mon, 31 May 2021 14:52:43 -0700 Subject: [PATCH 310/780] rewording of sections on "contains", "maxContains", "minContains" - More cross-references added that note the dependence of these keywords on each other - Confusing paragraph about logical results removed (and it is redundant with other paragraphs) --- jsonschema-core.xml | 26 +++++++++++++++----------- jsonschema-validation.xml | 5 +++-- 2 files changed, 18 insertions(+), 13 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 28f24051..f968c8cb 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2085,7 +2085,8 @@ "items", whose behavior is defined in terms of "prefixItems" - "contains", whose behavior is defined in terms of "minContains" + "contains", whose behavior is affected by the presence and value of + "minContains", in the Validation vocabulary @@ -2339,15 +2340,10 @@ An array instance is valid against "contains" if at least one of - its elements is valid against the given schema. The subschema MUST be - applied to every array element even after the first match has - been found, in order to collect annotations for use by other keywords. - This is to ensure that all possible annotations are collected. - - - Logically, the validation result of applying the value subschema to each - item in the array MUST be ORed with "false", resulting in an overall - validation result. + its elements is valid against the given schema, + except when "minContains" is present and has a value of 0, in which + case an array instance MUST be valid against the "contains" keyword, + even if NONE of its elements is valid against the given schema. This keyword produces an annotation value which is an array of @@ -2356,8 +2352,16 @@ the subschema validates successfully when applied to every index of the instance. The annotation MUST be present if the instance array to which this keyword's schema applies is empty. + + This annotation affects the behavior of "unevaluatedItems" in the - Unevaluated vocabulary. + Unevaluated vocabulary, and MAY also be used to implement the + "minContains" and "maxContains" keywords in the Validation vocabulary. + + + The subschema MUST be applied to every array element even after the first + match has been found, in order to collect annotations for use by other + keywords. This is to ensure that all possible annotations are collected.
diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index f1c5721c..d92a5495 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -442,8 +442,9 @@ A value of 0 is allowed, but is only useful for setting a range - of occurrences from 0 to the value of "maxContains". A value of - 0 with no "maxContains" causes "contains" to always pass validation. + of occurrences from 0 to the value of "maxContains". A value of + 0 causes "minContains" to always pass validation (but validation can + still fail against a "maxContains" keyword). Omitting this keyword has the same behavior as a value of 1. From 53736b4843da17e3b6df5eb23450d935ef1af694 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Mon, 31 May 2021 16:25:40 -0700 Subject: [PATCH 311/780] "contains" did not annotate before 2020-12 --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f968c8cb..0137a711 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3855,7 +3855,7 @@ https://example.com/schemas/common#/$defs/count/minimum "$schema" MAY change for embedded resources Array-value "items" functionality is now "prefixItems" "items" subsumes the old function of "additionalItems" - "contains" and "unevaluatedItems" interactions now specified + "contains" annotation behavior, and "contains" and "unevaluatedItems" interactions now specified Rename $recursive* to $dynamic* $dynamicAnchor defines a fragment like $anchor $dynamic* (previously $recursive) no longer use runtime base URI determination From 48736f785eb0ed84d66f8045296a0d6008db59d8 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Mon, 31 May 2021 16:26:03 -0700 Subject: [PATCH 312/780] $recursiveRef -> $dynamicRef was not just a simple keyword renaming --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0137a711..62d9b13d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3856,7 +3856,7 @@ https://example.com/schemas/common#/$defs/count/minimum Array-value "items" functionality is now "prefixItems" "items" subsumes the old function of "additionalItems" "contains" annotation behavior, and "contains" and "unevaluatedItems" interactions now specified - Rename $recursive* to $dynamic* + Rename $recursive* to $dynamic*, with behavior modification $dynamicAnchor defines a fragment like $anchor $dynamic* (previously $recursive) no longer use runtime base URI determination Define Compound Schema Documents (bundle) and processing From 6853f304a6dbe8097d25b51f466144e069d415cc Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Thu, 3 Feb 2022 20:14:32 -0800 Subject: [PATCH 313/780] improve wording Co-authored-by: Ben Hutton --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 62d9b13d..afb0c775 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2342,7 +2342,7 @@ An array instance is valid against "contains" if at least one of its elements is valid against the given schema, except when "minContains" is present and has a value of 0, in which - case an array instance MUST be valid against the "contains" keyword, + case an array instance MUST be considered valid against the "contains" keyword, even if NONE of its elements is valid against the given schema. From 8d597649cebd3649a04c3e69921a29e079db9738 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Thu, 3 Feb 2022 20:15:28 -0800 Subject: [PATCH 314/780] no shouty --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index afb0c775..104335fd 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2343,7 +2343,7 @@ its elements is valid against the given schema, except when "minContains" is present and has a value of 0, in which case an array instance MUST be considered valid against the "contains" keyword, - even if NONE of its elements is valid against the given schema. + even if none of its elements is valid against the given schema. This keyword produces an annotation value which is an array of From 371dae1577de24884a91059290787751c20b466e Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 3 Feb 2022 10:31:07 -0800 Subject: [PATCH 315/780] Remove remaining media-type param references --- jsonschema-core.xml | 29 +---------------------------- 1 file changed, 1 insertion(+), 28 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 104335fd..8233bee3 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3130,20 +3130,6 @@ https://example.com/schemas/common#/$defs/count/minimum Type name: application Subtype name: schema+json Required parameters: N/A - - Optional parameters: - - - A non-empty list of space-separated URIs, each identifying - a JSON Schema resource. The instance SHOULD successfully - validate against at least one of these meta-schemas. - Non-validating meta-schemas MAY be included for purposes such - as allowing clients to make use of older versions of - a meta-schema as long as the runtime instance validates - against that older version. - - - Encoding considerations: Encoding considerations are identical to those specified for the "application/json" @@ -3174,20 +3160,7 @@ https://example.com/schemas/common#/$defs/count/minimum Type name: application Subtype name: schema-instance+json - - Required parameters: - - - A non-empty list of space-separated URIs, each identifying - a JSON Schema resource. The instance SHOULD successfully - validate against at least one of these schemas. - Non-validating schemas MAY be included for purposes such - as allowing clients to make use of older versions of a schema - as long as the runtime instance validates against that - older version. - - - + Required parameters: N/A Encoding considerations: Encoding considerations are identical to those specified for the "application/json" From db65da82ce72886ae9fd01727db9a25a422b4652 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 14 Mar 2022 11:10:38 +0000 Subject: [PATCH 316/780] Clarify that plain name fragments are neither canonical or non-canonical (#1192) * Clarify that plain name fragments are neither canonical or non-canonical Attempt to resolve #937 Add note and cref in appendix A clarifying that we intended to define a URI phrasing which would avoid the requirement to allow for location shadowing in implementations, as this is tricky. Clarifying that plain name fragments should always be supported, and that they only can work in relation to the base URI of the Schema Resource. Otherwise there could be duplicate plain name fragments and addressing wouldn't work. --- jsonschema-core.xml | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 8233bee3..07b9436e 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -50,7 +50,7 @@ - + Internet Engineering Task Force JSON Schema @@ -1824,10 +1824,10 @@ reference target, is preferable. - An implementation MAY choose not to support addressing schemas - by non-canonical URIs. As such, it is RECOMMENDED that schema authors only - use canonical URIs, as using non-canonical URIs may reduce - schema interoperability. + An implementation MAY choose not to support addressing schema resources + (and their subschemas) by non-canonical URIs. + As such, it is RECOMMENDED that schema authors only use canonical URIs, + as using non-canonical URIs may reduce schema interoperability. This is to avoid requiring implementations to keep track of a whole stack of possible base URIs and JSON Pointer fragments for each, @@ -1836,6 +1836,11 @@ no point in forbidding it, while others have argued that it complicates schema identification and should be forbidden. Feedback on this topic is encouraged. + After some discussion, we feel that we need to remove the use of + "canonical" in favour of talking about JSON Pointers which reference + across schema resource boundaries as undefined or even forbidden behavior + (https://github.com/json-schema-org/json-schema-spec/issues/937, + https://github.com/json-schema-org/json-schema-spec/issues/1183) @@ -3390,6 +3395,18 @@ https://example.com/schemas/common#/$defs/count/minimum + + Note: The fragment part of the URI does not make it canonical or non-canonical, + rather, the base URI used (as part of the full URI with any fragment) is what + determines the canonical nature of the resulting full URI. + + Multiple "canonical" URIs? We Acknowledge this is potentially confusing, and + direct you to read the CREF located in the + JSON Pointer fragments and embedded schema resources + section for futher comments. + + +
From 4f9e8bed0157fdf57dd850fdc4939a3f56d949d0 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 13 May 2021 17:18:58 -0700 Subject: [PATCH 317/780] Clarify various things about canonical URIs Fixes issue #937, clarifying a number of other things along the way. While it touches a fair number of lines, I'm fairly sure that it doesn't anything about conformance. After spending more time reading various writings on the concept of the "canonical" URI for a resource, and reviewing our language, I came to the following conclusions: * canonical URIs only make sense at the whole-resource scope * A URI with a fragment is neither canonical nor non-canonical * It makes more sense to talk about fragments w.r.t. canonical URIs * Our language was sufficiently confusing that going this way seems fine. As part of this, I fixed an outright incorrect statement that identifier keywords set canonical URIs. Since there is only one canonical URI and a single schema object could contain three ($id, $anchor, $dynamicAnchor) or more identifier keywords, this statement is clearly a bug. These keywords assign URIs, but only $id assigns a canonical one. I revamped a lot of wording in descriptions and examples to hopefully be more precise. I separated the discussion of the empty fragment in $id from the main paragraph of its functionality, and clarified that this is talking about a media-type-specific semantic equivalence, and is not asserting that RFC 3986 normalization applies to fragments (this has been a point of confusion). --- jsonschema-core.xml | 144 ++++++++++++++++++++++++-------------------- 1 file changed, 79 insertions(+), 65 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 07b9436e..058219aa 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -315,8 +315,8 @@ of five categories: - control schema identification through setting the schema's - canonical URI and/or changing how the base URI is determined + control schema identification through setting a URI + for the schema and/or changing how the base URI is determined produce a boolean result when applied to an instance @@ -426,7 +426,9 @@ A JSON Schema resource is a schema which is canonically identified by an - absolute URI. + absolute URI. Schema resources MAY + also be identified by URIs including fragments. Any such URIs + are considered to be non-canonical. The root schema is the schema that comprises the entire JSON document @@ -730,9 +732,9 @@ be able to support those keywords or vocabularies that contain them.
-
+
- Identifiers set the canonical URI of a schema, or affect how such URIs are + Identifiers define URIs for a schema, or affect how such URIs are resolved in references, or both. The Core vocabulary defined in this document defines several identifying keywords, most notably "$id". @@ -1340,26 +1342,31 @@ If present, the value for this keyword MUST be a string, and MUST represent a valid URI-reference. This URI-reference - SHOULD be normalized, and MUST resolve to an - absolute-URI (without a fragment). Therefore, - "$id" MUST NOT contain a non-empty fragment, and SHOULD NOT contain an - empty fragment. + SHOULD be normalized, and MUST be semantically equivalent to an + absolute-URI (without a fragment). - Since an empty fragment in the context of the application/schema+json media - type refers to the same resource as the base URI without a fragment, - an implementation MAY normalize a URI ending with an empty fragment by removing - the fragment. However, schema authors SHOULD NOT rely on this behavior - across implementations. + The application/schema+json media type defines that an absolute-URI + identifying a resource and the same URI with an empty fragment + appended (which identifies the resource's root schema object) are + semantically equivalent. Since this semantic equivalence is not part + of the RFC 3986 normalization process, + implementors and schema authors cannot rely on generic URI libraries + understanding the equivalence. + + + Therefore, "$id" MUST NOT contain a non-empty fragment, and SHOULD NOT + contain an empty fragment. The absolute-URI form MUST be considered + the canonical URI, regardless of the presence or absence of an empty fragment. - This is primarily allowed because older meta-schemas have an empty - fragment in their $id (or previously, id). A future draft may outright - forbid even empty fragments in "$id". + An empty fragment is currently allowed because older meta-schemas have + an empty fragment in their $id (or previously, id). + A future draft may outright forbid even empty fragments in "$id". - This URI also serves as the base URI for relative URI-references in keywords - within the schema resource, in accordance with + The absolute-URI also serves as the base URI for relative URI-references + in keywords within the schema resource, in accordance with RFC 3986 section 5.1.1 regarding base URIs embedded in content. @@ -1623,7 +1630,7 @@ media type. - Unless the "$id" keyword described in the next section is present in the + Unless the "$id" keyword described in an earlier section is present in the root schema, this base URI SHOULD be considered the canonical URI of the schema document's root schema resource. @@ -1750,7 +1757,7 @@ Since JSON Pointer URI fragments are constructed based on the structure of the schema document, an embedded schema resource and its subschemas can be identified by JSON Pointer fragments relative to either its own - canonical URI, or relative to the containing resource's URI. + canonical URI, or relative to a containing resource's URI. Conceptually, a set of linked schema resources should behave @@ -1782,13 +1789,18 @@ } ]]> - - The URI "https://example.com/foo#/items/additionalProperties" - points to the schema of the "additionalProperties" keyword in - the embedded resource. The canonical URI of that schema, however, - is "https://example.com/bar#/additionalProperties". - + + The URI "https://example.com/foo#/items" points to the "items" schema, + which is an embedded resource. The canonical URI of that schema + resource, however, is "https://example.com/bar". + + + For the "additionalProperties" schema within that embedded resource, + the URI "https://example.com/foo#/items/additionalProperties" points + to the correct object, but that object's URI relative to its resource's + canonical URI is "https://example.com/bar#/additionalProperties". +
Now consider the following two schema resources linked by reference @@ -1810,29 +1822,31 @@ ]]> - Here we see that the canonical URI for that "additionalProperties" - subschema is still valid, while the non-canonical URI with the fragment - beginning with "#/items/$ref" now resolves to nothing. + Here we see that the URI for the "additionalProperties" schema object + that is relative to its resource's canonical URI is still valid, + while the URI relative to the "items" schema object's URI no longer + resolves to anything.
Note also that "https://example.com/foo#/items" is valid in both arrangements, but resolves to a different value. This URI ends up - functioning similarly to a retrieval URI for a resource. While valid, - examining the resolved value and either using the "$id" (if the value - is a subschema), or resolving the reference and using the "$id" of the - reference target, is preferable. + functioning similarly to a retrieval URI for a resource. While this URI + is valid, it is more robust to use the "$id" of the embedded or referenced + resource unless it is specifically desired to identify the object containing + the "$ref" in the second (non-embedded) arrangement. - An implementation MAY choose not to support addressing schema resources - (and their subschemas) by non-canonical URIs. - As such, it is RECOMMENDED that schema authors only use canonical URIs, - as using non-canonical URIs may reduce schema interoperability. + An implementation MAY choose not to support addressing schema resource + contents by URIs using a base other than the resource's canonical URI, + plus a JSON Pointer fragment relative to that base. Therefore, schema + authors SHOULD NOT rely on such URIs, as using them may reduce interoperability. This is to avoid requiring implementations to keep track of a whole stack of possible base URIs and JSON Pointer fragments for each, given that all but one will be fragile if the schema resources - are reorganized. Some have argued that this is easy so there is + are reorganized. Some + have argued that this is easy so there is no point in forbidding it, while others have argued that it complicates schema identification and should be forbidden. Feedback on this topic is encouraged. @@ -1844,9 +1858,9 @@ - Further examples of such non-canonical URIs, as well as the appropriate - canonical URIs to use instead, are provided in appendix - . + Further examples of such non-canonical URI construction, as well as + the appropriate canonical URI-based fragments to use instead, + are provided in appendix .
@@ -2709,8 +2723,8 @@
The absolute, dereferenced location of the validating keyword. The value MUST - be expressed as a full URI using the canonical URI of the relevant - schema object, and it MUST NOT include by-reference applicators + be expressed as a full URI using the canonical URI of the relevant schema resource + with a JSON Pointer fragment, and it MUST NOT include by-reference applicators such as "$ref" or "$dynamicRef" as non-terminal path components. It MAY end in such keywords if the error or annotation is for that keyword, such as an unresolvable reference. @@ -3319,10 +3333,10 @@ https://example.com/schemas/common#/$defs/count/minimum - + https://example.com/root.json - + https://example.com/root.json# @@ -3330,21 +3344,21 @@ https://example.com/schemas/common#/$defs/count/minimum https://example.com/root.json - + https://example.com/root.json#foo - + https://example.com/root.json#/$defs/A - https://example.com/other.json - + https://example.com/other.json + https://example.com/other.json# - + https://example.com/root.json#/$defs/B @@ -3352,43 +3366,43 @@ https://example.com/schemas/common#/$defs/count/minimum https://example.com/other.json - + https://example.com/other.json#bar - + https://example.com/other.json#/$defs/X - + https://example.com/root.json#/$defs/B/$defs/X - https://example.com/t/inner.json - + https://example.com/t/inner.json + https://example.com/t/inner.json#bar - + https://example.com/t/inner.json# - + https://example.com/other.json#/$defs/Y - + https://example.com/root.json#/$defs/B/$defs/Y - + urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f - + urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f# - + https://example.com/root.json#/$defs/C @@ -3432,8 +3446,8 @@ https://example.com/schemas/common#/$defs/count/minimum This transformation can be safely and reversibly done as long as all static references (e.g. "$ref") use URI-references that resolve - to canonical URIs, and all schema resources have an absolute-URI - as the "$id" in their root schema. + to URIs using the canonical resource URI as the base, and all schema + resources have an absolute-URI as the "$id" in their root schema. With these conditions met, each external resource can be copied @@ -3441,7 +3455,7 @@ https://example.com/schemas/common#/$defs/count/minimum schema objects, and without changing any aspect of validation or annotation results. The names of the schemas under "$defs" do not affect behavior, assuming they are each unique, as they - do not appear in canonical URIs for the embedded resources. + do not appear in the canonical URIs for the embedded resources.
From afca53d622aad3ce646917e2bd764f612c544806 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 13 Jul 2021 16:47:56 -0700 Subject: [PATCH 318/780] Update based on review feedback. --- jsonschema-core.xml | 46 +++++++++++++++++++++++++++++---------------- 1 file changed, 30 insertions(+), 16 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 058219aa..00738358 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -427,14 +427,24 @@ A JSON Schema resource is a schema which is canonically identified by an absolute URI. Schema resources MAY - also be identified by URIs including fragments. Any such URIs - are considered to be non-canonical. + also be identified by URIs, including URIs with fragments, + if the resulting secondary resource (as defined by + section 3.5 of RFC 3986) is identical + to the primary resource. This can occur with the empty fragment, + or when one schema resource is embedded in another. Any such URIs + with fragments are considered to be non-canonical. The root schema is the schema that comprises the entire JSON document in question. The root schema is always a schema resource, where the URI is determined as described in section . + + Note that documents that embed schemas in another format will not + have a root schema resource in this sense. Exactly how such usages + fit with the JSON Schema document and resource concepts will be + clarified in a future draft. + Some keywords take schemas themselves, allowing JSON Schemas to be nested: @@ -1342,17 +1352,19 @@ If present, the value for this keyword MUST be a string, and MUST represent a valid URI-reference. This URI-reference - SHOULD be normalized, and MUST be semantically equivalent to an - absolute-URI (without a fragment). + SHOULD be normalized, and MUST resolve to an + absolute-URI (without a fragment), + or to a URI with an empty fragment. - The application/schema+json media type defines that an absolute-URI - identifying a resource and the same URI with an empty fragment - appended (which identifies the resource's root schema object) are - semantically equivalent. Since this semantic equivalence is not part - of the RFC 3986 normalization process, - implementors and schema authors cannot rely on generic URI libraries - understanding the equivalence. + The empty fragment form is NOT RECOMMENDED and is retained only + for backwards compatibility, and because the + application/schema+json media type defines that a URI with an + empty fragment identifies the same resource as the same URI + with the fragment removed. However, since this equivalence is not + part of the RFC 3986 normalization process, + implementers and schema authors cannot rely on generic URI libraries + understanding it. Therefore, "$id" MUST NOT contain a non-empty fragment, and SHOULD NOT @@ -1757,7 +1769,7 @@ Since JSON Pointer URI fragments are constructed based on the structure of the schema document, an embedded schema resource and its subschemas can be identified by JSON Pointer fragments relative to either its own - canonical URI, or relative to a containing resource's URI. + canonical URI, or relative to any containing resource's URI. Conceptually, a set of linked schema resources should behave @@ -1822,10 +1834,12 @@ ]]> - Here we see that the URI for the "additionalProperties" schema object - that is relative to its resource's canonical URI is still valid, - while the URI relative to the "items" schema object's URI no longer - resolves to anything. + Here we see that "https://example.com/bar#/additionalProperties", + using a JSON Pointer fragment appended to the canonical URI of + the "bar" schema resource, is still valid, while + "https://example.com/foo#/items/additionalProperties", which relied + on a JSON Pointer fragment appended to the canonical URI of the + "foo" schema resource, no longer resolves to anything. From c186b9a5b37e8a26d7e0ed4faa796d76a3005e26 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 30 Mar 2022 09:46:52 +0100 Subject: [PATCH 319/780] Add CREF about ambiguous behaviour of additionalProperties Fixes #1172 Must see new issue relating to the behaviour of annotation collection for resolving in the next draft. --- jsonschema-core.xml | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 00738358..5622cc38 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2480,6 +2480,28 @@ checking the names in "properties" and the patterns in "patternProperties" against the instance property set. Implementations that do not support annotation collection MUST do so. + + In defining this option, it seems there is the potential for + ambiguity in the output format. The ambiguity does not affect validation results, + but it does affect the resulting output format. + The ambiguity allows for multiple valid output results depending on whether annotations + are used or a solution that "produces the same effect" as draft-07. It is understood + that annotations from failing schemas are dropped. See + https://github.com/json-schema-org/community/discussions/57 for details. + We discussed the possible solutions at length (https://github.com/json-schema-org/json-schema-spec/issues/1172). + We concluded that we need to re-evaluate the annotation collection system + and its use for validation purposes, but we also agreed not to do so for this release. + This confusion stemmed from the understanding of "evaluated" and the impact on + annotation collection. + It was proposed that we could read a different interpretation (https://github.com/json-schema-org/json-schema-spec/issues/1172#issuecomment-1049686478) + however the previous interpretation is still valid. + The only consensus we could reach for this release was to note all this + in a CREF, which you're now reading, and acknowledge that both results + as described in https://github.com/json-schema-org/community/discussions/57. + If you encounter the same issue regarding ambiguity of the output format, + please do reach out to us, either via emails as per editors of this specification, + or other official JSON Schema channels like our Slack or Twitter. +
From f13350a971899eb4893383e729680a91b9428880 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 8 Apr 2022 15:53:07 +0100 Subject: [PATCH 320/780] Remove detail about ambiguity and reasoning. Link out to pending ADR --- jsonschema-core.xml | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 5622cc38..b4e2efa2 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2486,21 +2486,10 @@ but it does affect the resulting output format. The ambiguity allows for multiple valid output results depending on whether annotations are used or a solution that "produces the same effect" as draft-07. It is understood - that annotations from failing schemas are dropped. See - https://github.com/json-schema-org/community/discussions/57 for details. - We discussed the possible solutions at length (https://github.com/json-schema-org/json-schema-spec/issues/1172). - We concluded that we need to re-evaluate the annotation collection system - and its use for validation purposes, but we also agreed not to do so for this release. - This confusion stemmed from the understanding of "evaluated" and the impact on - annotation collection. - It was proposed that we could read a different interpretation (https://github.com/json-schema-org/json-schema-spec/issues/1172#issuecomment-1049686478) - however the previous interpretation is still valid. - The only consensus we could reach for this release was to note all this - in a CREF, which you're now reading, and acknowledge that both results - as described in https://github.com/json-schema-org/community/discussions/57. - If you encounter the same issue regarding ambiguity of the output format, - please do reach out to us, either via emails as per editors of this specification, - or other official JSON Schema channels like our Slack or Twitter. + that annotations from failing schemas are dropped. + See our + [Decision Record](https://github.com/json-schema-org/json-schema-spec/tree/HEAD/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md) + for further details.
From e8a602877264001f9b11de3f81755747922811ae Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 8 Apr 2022 16:00:19 +0100 Subject: [PATCH 321/780] Add folder for architectural decision records (ADRs) Add first spec related ADR about the handling of additionalProperties ambiguity in 2019-09 and 2020-12 for the patch release by adding a CREF --- ...iguity-and-fix-later-gh-spec-issue-1172.md | 87 +++++++++++++++++++ adr/README.md | 15 ++++ adr/template.md | 72 +++++++++++++++ 3 files changed, 174 insertions(+) create mode 100644 adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md create mode 100644 adr/README.md create mode 100644 adr/template.md diff --git a/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md new file mode 100644 index 00000000..cd7fb61d --- /dev/null +++ b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md @@ -0,0 +1,87 @@ +# Acknowledge ambiguity in additionalProperties behaviour and fix after patch release + +* Status: proposed +* Deciders: @relequestual @gregsdennis, @jdesrosiers, @karenetheridge +* Date: 2022-04-08 + +https://github.com/json-schema-org/json-schema-spec/issues/1172 +https://github.com/json-schema-org/community/discussions/57 +https://github.com/json-schema-org/json-schema-spec/pull/1203 + +## Context and Problem Statement + +When we changed the specification to use annotations as the context in which some keywords behave, we included a clause that implementations which didn't use annotations may implement or optimize the processing of `additionalProperties` in another way which produces the same effect as the prior behaviour. +This section created an ambiguity in terms of the resulting output format, but not validation. + +We needed to decide on how to proceed for the patch release of the 2020-12 version of the specification. + +The two above links are to a GitHub Discussion and a GitHub Issue detailing the problems. +Details with an example of the problem can be seen in the Discussion's opening post specifically. + +## Decision Drivers + +* The "patch release" should not change anything functionally +* Annotations as they are, are confusing to users, implementers, and specification editors alike +* Patch release is behind schedule +* There are currently no tests for the output format +* It's hard to see any immediate consensus on changing the annotation based behaviour + +## Considered Options + +* [Leaving it "as is" and do nothing](https://github.com/json-schema-org/community/discussions/57#discussioncomment-1413777) +* [Pick one](https://github.com/json-schema-org/community/discussions/57#discussioncomment-1416683) of the behaviours +* [Revert back to draft-07 behaviour](https://github.com/json-schema-org/community/discussions/57#discussioncomment-1453723) +* [Reinterpret how we understand annotation collection](https://github.com/json-schema-org/json-schema-spec/issues/1172#issuecomment-1049686478) to allow reading annotations within the same schema object regardless of assertion results +* [Acknowledge and accept that two approaches and results are allowable](https://github.com/json-schema-org/community/issues/161#issue-1173742930) +* Redefine annotation collection behaviour and/or how `additionalProperties` works + +## Decision Outcome + +Chosen option: "Acknowledge and accept that two approaches and results are allowable", because + +* Leaving it "as is" will continue to cause confusion +* The change is non-functional which is required for the patch release +* The patch release is behind schedule +* Finding consensus of other solutions proved to be difficult +* There's no test suite for the output format, so it's not easy to see unintended consequences of a functional change +* We need to properly re-evaluate annotation collection and how annotations are used by other keywords + +### Positive Consequences + +* Patch release can move forward +* Validation result is not impacted +* Confusion is at least seen and acknowledged +* Implementations which pick either approach are seen to be compliant + +### Negative Consequences + +* May have an impact for downstream tools which process full output data +* A test suite (not yet developed) which covers this situation needs to allow for multiple valid answers + +## Pros and Cons of the Options + +### Leaving it "as is" and do nothing + +Agree to do nothing and hope for the best. There isn't any downstream tooling yet anyway. + +* Good, because no functional change +* Good, because no impact on downstream tooling +* Bad, because leaves a known ambiguity in the specification + +### Pick one / Revert to draft-07 behaviour / Reinterpret annotation collection + +* Good, because ambiguity is removed +* Good, because not many tools will be effected +* Bad, because it can be seen as a functional change (not really allowed for the patch release) +* Bad, because it can break existing implementations and downstream tools +* Bad, because without a test suite it's hard to see unexpected consequences + +## Links + +* Issue: [Ambiguous behaviour of additionalProperties when invalid](https://github.com/json-schema-org/json-schema-spec/issues/1172) +* Discussion: [The meaning of "additionalProperties" has changed](https://github.com/json-schema-org/community/discussions/57) +* Resolving Pull Request: [Add CREF about ambiguous behaviour of additionalProperties](https://github.com/json-schema-org/json-schema-spec/pull/1203) +* Alternative solution proposal: [Resolve contradictions in the described behaviour of "additionalProperties" and "items"](https://github.com/json-schema-org/json-schema-spec/pull/1154) + +* [Result of discussing](https://github.com/json-schema-org/json-schema-spec/issues/1172#issuecomment-1063962900) on an Open Community Working Meeting call - @jdesrosiers proposed a less controversial and more agreeable solution to add a comment that both are allowable +* [Related GitHub Discussion](https://github.com/json-schema-org/community/discussions/67) on alternative behaviour for `unevaluated*` keywords diff --git a/adr/README.md b/adr/README.md new file mode 100644 index 00000000..331cd6bf --- /dev/null +++ b/adr/README.md @@ -0,0 +1,15 @@ +# Architectural Decision Log + +This log lists the architectural decisions for the JSON Schema specification. + + + +* [ADR-2022-04-08](2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md) - Acknowledge ambiguity in additionalProperties behaviour and fix after patch release + + + +You can find the ADR for using ADRs in our [community repo ADR log](https://github.com/json-schema-org/community/tree/HEAD/docs/adr). + +For new ADRs, please use [template.md](template.md) as basis. +More information on MADR is available at . +General information about architectural decision records is available at . diff --git a/adr/template.md b/adr/template.md new file mode 100644 index 00000000..25696bbe --- /dev/null +++ b/adr/template.md @@ -0,0 +1,72 @@ +# [short title of solved problem and solution] + +* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] +* Deciders: [list everyone involved in the decision] +* Date: [YYYY-MM-DD when the decision was last updated] + +Technical Story: [description | ticket/issue URL] + +## Context and Problem Statement + +[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.] + +## Decision Drivers + +* [driver 1, e.g., a force, facing concern, …] +* [driver 2, e.g., a force, facing concern, …] +* … + +## Considered Options + +* [option 1] +* [option 2] +* [option 3] +* … + +## Decision Outcome + +Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)]. + +### Positive Consequences + +* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …] +* … + +### Negative Consequences + +* [e.g., compromising quality attribute, follow-up decisions required, …] +* … + +## Pros and Cons of the Options + +### [option 1] + +[example | description | pointer to more information | …] + +* Good, because [argument a] +* Good, because [argument b] +* Bad, because [argument c] +* … + +### [option 2] + +[example | description | pointer to more information | …] + +* Good, because [argument a] +* Good, because [argument b] +* Bad, because [argument c] +* … + +### [option 3] + +[example | description | pointer to more information | …] + +* Good, because [argument a] +* Good, because [argument b] +* Bad, because [argument c] +* … + +## Links + +* [Link type] [Link to ADR] +* … From 26bfeb8a9c753c8f2b02a8d9f19f7220960838be Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 20 Apr 2022 10:16:38 +0100 Subject: [PATCH 322/780] Tidy initial links in an ADR --- ...ref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md index cd7fb61d..f4fab086 100644 --- a/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md +++ b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md @@ -4,9 +4,12 @@ * Deciders: @relequestual @gregsdennis, @jdesrosiers, @karenetheridge * Date: 2022-04-08 -https://github.com/json-schema-org/json-schema-spec/issues/1172 -https://github.com/json-schema-org/community/discussions/57 -https://github.com/json-schema-org/json-schema-spec/pull/1203 +Related... +Issue: https://github.com/json-schema-org/json-schema-spec/issues/1172 + +Discussion: https://github.com/json-schema-org/community/discussions/57 + +Pull Request: https://github.com/json-schema-org/json-schema-spec/pull/1203 ## Context and Problem Statement From 74a4e7ede7522074974556d65a2f26360a576ae9 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 20 Apr 2022 10:16:52 +0100 Subject: [PATCH 323/780] Further tidy --- ...-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md | 1 + 1 file changed, 1 insertion(+) diff --git a/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md index f4fab086..aee552e4 100644 --- a/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md +++ b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md @@ -5,6 +5,7 @@ * Date: 2022-04-08 Related... + Issue: https://github.com/json-schema-org/json-schema-spec/issues/1172 Discussion: https://github.com/json-schema-org/community/discussions/57 From 98e3ee7756ea9e0c3b22b2ea5f23e7a804e8cd91 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 28 Apr 2022 13:30:21 +0100 Subject: [PATCH 324/780] Change date of validation spec to 2022. Year has to be current or xml2rfc says no. --- jsonschema-validation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index d92a5495..ad005c07 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -53,7 +53,7 @@ - + Internet Engineering Task Force JSON Schema From 56ebcd09302714ddfaafa212fa764b9b1a1e2714 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 28 Apr 2022 16:54:33 +0100 Subject: [PATCH 325/780] Update draft identifiers for 2020-12 patch release --- jsonschema-core.xml | 6 +++--- jsonschema-validation.xml | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b4e2efa2..a9604a2f 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -20,7 +20,7 @@ - + JSON Schema: A Media Type for Describing JSON Documents @@ -3267,9 +3267,9 @@ https://example.com/schemas/common#/$defs/count/minimum - + - + diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index ad005c07..8c4820fb 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -28,7 +28,7 @@ - + JSON Schema Validation: A Vocabulary for Structural Validation of JSON @@ -1354,9 +1354,9 @@ <author initials="G." surname="Dennis"> <organization/> </author> - <date year="2020" month="December"/> + <date year="2022" month="May"/> </front> - <seriesInfo name="Internet-Draft" value="draft-bhutton-json-schema-00" /> + <seriesInfo name="Internet-Draft" value="draft-bhutton-json-schema-01" /> </reference> </references> From 9afa06b1dfbfac5266ac79bf053e01512ef0d31c Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Tue, 10 May 2022 14:13:40 +0100 Subject: [PATCH 326/780] Changes ADR phrasing to improve readability --- ...04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md index aee552e4..03b976dc 100644 --- a/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md +++ b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md @@ -14,7 +14,7 @@ Pull Request: https://github.com/json-schema-org/json-schema-spec/pull/1203 ## Context and Problem Statement -When we changed the specification to use annotations as the context in which some keywords behave, we included a clause that implementations which didn't use annotations may implement or optimize the processing of `additionalProperties` in another way which produces the same effect as the prior behaviour. +When we changed the specification to use annotations as the context in which some keywords behave, we included a clause that allowed implementations which didn't use annotations to optimize the processing of `additionalProperties` in another way which produces the same effect as the prior behaviour. This section created an ambiguity in terms of the resulting output format, but not validation. We needed to decide on how to proceed for the patch release of the 2020-12 version of the specification. From 859ca972a4bd66b005dab987d6f628a81ea873c7 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Thu, 19 May 2022 12:06:35 +0100 Subject: [PATCH 327/780] Add changelog for 2020-12 patch 1 update Specifically draft-bhutton-json-schema-01 and draft-bhutton-json-schema-validation-01 --- jsonschema-core.xml | 10 ++++++++++ jsonschema-validation.xml | 6 ++++++ 2 files changed, 16 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index a9604a2f..d3beca54 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3879,6 +3879,16 @@ https://example.com/schemas/common#/$defs/count/minimum </t> <t> <list style="hanging"> + <t hangText="draft-bhutton-json-schema-01"> + <list style="symbols"> + <t>Improve and clarify the "type", "contains", "unevaluatedProperties", and "unevaluatedItems" keyword explanations</t> + <t>Clarify various aspects of "canonical URIs"</t> + <t>Comment on ambiguity around annotations and "additionalProperties"</t> + <t>Clarify Vocabularies need not be formally defined</t> + <t>Remove references to remaining media-type parameters</t> + <t>Fix multiple examples</t> + </list> + </t> <t hangText="draft-bhutton-json-schema-00"> <list style="symbols"> <t>"$schema" MAY change for embedded resources</t> diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 8c4820fb..fdc3d4a4 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1441,6 +1441,12 @@ </t> <t> <list style="hanging"> + <t hangText="draft-bhutton-json-schema-validation-01"> + <list style="symbols"> + <t>Improve and clarify the "minContains" keyword explanation</t> + <t>Remove the use of "production" in favour of "ABNF rule"</t> + </list> + </t> <t hangText="draft-bhutton-json-schema-validation-00"> <list style="symbols"> <t>Correct email format RFC reference to 5321 instead of 5322</t> From 438866ebba372d15f6b0085d2999d8648d9f334e Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Thu, 19 May 2022 16:10:32 +0100 Subject: [PATCH 328/780] Updated ADR status to accepted and updated date to current, reflecting last updated --- ...-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md index 03b976dc..5e83dd95 100644 --- a/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md +++ b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md @@ -1,8 +1,8 @@ # Acknowledge ambiguity in additionalProperties behaviour and fix after patch release -* Status: proposed +* Status: accepted * Deciders: @relequestual @gregsdennis, @jdesrosiers, @karenetheridge -* Date: 2022-04-08 +* Date: 2022-05-19 Related... From 4c8337713f343a9250fb68601ecd0b5382482ece Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Thu, 26 May 2022 21:51:27 +1200 Subject: [PATCH 329/780] add clarification that minContains:0 also causes contains to pass --- jsonschema-validation.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index fdc3d4a4..ee3ee1b6 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -443,8 +443,8 @@ <t> A value of 0 is allowed, but is only useful for setting a range of occurrences from 0 to the value of "maxContains". A value of - 0 causes "minContains" to always pass validation (but validation can - still fail against a "maxContains" keyword). + 0 causes "minContains" and "contains" to always pass validation + (but validation can still fail against a "maxContains" keyword). </t> <t> Omitting this keyword has the same behavior as a value of 1. From 6410e59f3ae283a0a45c5a1618c60bc36c88e241 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Fri, 10 Jun 2022 10:47:34 +0100 Subject: [PATCH 330/780] Update month for cross reference of core and validaiton specifications --- jsonschema-core.xml | 2 +- jsonschema-validation.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index d3beca54..26426dc3 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3267,7 +3267,7 @@ https://example.com/schemas/common#/$defs/count/minimum <author initials="B." surname="Hutton"> <organization/> </author> - <date year="2022" month="May"/> + <date year="2022" month="June"/> </front> <seriesInfo name="Internet-Draft" value="draft-bhutton-json-schema-validation-01" /> </reference> diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index ee3ee1b6..169924e2 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1354,7 +1354,7 @@ <author initials="G." surname="Dennis"> <organization/> </author> - <date year="2022" month="May"/> + <date year="2022" month="June"/> </front> <seriesInfo name="Internet-Draft" value="draft-bhutton-json-schema-01" /> </reference> From dd18e4a844005d98207c99f17360557aa2bd6343 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Fri, 10 Jun 2022 11:20:26 +0100 Subject: [PATCH 331/780] Add org affiliation for Ben Hutton --- jsonschema-core.xml | 1 + jsonschema-validation.xml | 1 + 2 files changed, 2 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 26426dc3..70a71da7 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -40,6 +40,7 @@ <address> <email>ben@jsonschema.dev</email> <uri>https://jsonschema.dev</uri> + <organization>Postman</organization> </address> </author> diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 169924e2..4d3a30c3 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -50,6 +50,7 @@ <address> <email>ben@jsonschema.dev</email> <uri>https://jsonschema.dev</uri> + <organization>Postman</organization> </address> </author> From add836e705c9a07434c467b6b90946ba45258a73 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Fri, 10 Jun 2022 11:38:26 +0100 Subject: [PATCH 332/780] Fix organization tag location --- jsonschema-core.xml | 2 +- jsonschema-validation.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 70a71da7..8397999f 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -37,10 +37,10 @@ </author> <author fullname="Ben Hutton" initials="B" surname="Hutton" role="editor"> + <organization>Postman</organization> <address> <email>ben@jsonschema.dev</email> <uri>https://jsonschema.dev</uri> - <organization>Postman</organization> </address> </author> diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 4d3a30c3..bbac5ca0 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -47,10 +47,10 @@ </author> <author fullname="Ben Hutton" initials="B" surname="Hutton" role="editor"> + <organization>Postman</organization> <address> <email>ben@jsonschema.dev</email> <uri>https://jsonschema.dev</uri> - <organization>Postman</organization> </address> </author> From e44120fa2d66c45a08984006ac3f1a60dbe5f0fb Mon Sep 17 00:00:00 2001 From: Jason Desrosiers <jdesrosi@gmail.com> Date: Mon, 19 Apr 2021 13:32:53 -0700 Subject: [PATCH 333/780] Allow contains to apply to objects as well as arrays --- jsonschema-core.xml | 20 ++++++++++++++------ jsonschema-validation.xml | 16 ++++++++-------- 2 files changed, 22 insertions(+), 14 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 8397999f..60a89889 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2380,12 +2380,20 @@ even if none of its elements is valid against the given schema. </t> <t> - This keyword produces an annotation value which is an array of - the indexes to which this keyword validates successfully when applying - its subschema, in ascending order. The value MAY be a boolean "true" if - the subschema validates successfully when applied to every index of the - instance. The annotation MUST be present if the instance array to which - this keyword's schema applies is empty. + An object instance is valid against "contains" if at least one of + its properties is valid against the given schema, + except when "minContains" is present and has a value of 0, in which + case an object instance MUST be considered valid against the "contains" keyword, + even if none of its property values is valid against the given schema. + </t> + <t> + This keyword produces an annotation value which is an array of the + indexes or property names to which this keyword validates successfully + when applying its subschema, in ascending order. The value MAY be a + boolean "true" if the subschema validates successfully when applied to + every index or property value of the instance. The annotation MUST be + present if the instance array or object to which this keyword's schema + applies is empty. </t> <t> This annotation affects the behavior of "unevaluatedItems" in the diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index bbac5ca0..12652584 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -414,13 +414,13 @@ then this keyword has no effect. </t> <t> - An instance array is valid against "maxContains" in two ways, depending on - the form of the annotation result of an adjacent + An instance array or object is valid against "maxContains" in two ways, + depending on the form of the annotation result of an adjacent <xref target="json-schema">"contains"</xref> keyword. The first way is if the annotation result is an array and the length of that array is less than or equal to the "maxContains" value. The second way is if the annotation - result is a boolean "true" and the instance array length is less than or - equal to the "maxContains" value. + result is a boolean "true" and the instance length is less than or equal to + the "maxContains" value. </t> </section> @@ -433,13 +433,13 @@ then this keyword has no effect. </t> <t> - An instance array is valid against "minContains" in two ways, depending on - the form of the annotation result of an adjacent + An instance array or object is valid against "minContains" in two ways, + depending on the form of the annotation result of an adjacent <xref target="json-schema">"contains"</xref> keyword. The first way is if the annotation result is an array and the length of that array is greater than or equal to the "minContains" value. The second way is if the - annotation result is a boolean "true" and the instance array length is - greater than or equal to the "minContains" value. + annotation result is a boolean "true" and the instance length is greater + than or equal to the "minContains" value. </t> <t> A value of 0 is allowed, but is only useful for setting a range From b997bb4972e00bda74e2a9e2f80d795e7d1404a7 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers <jdesrosi@gmail.com> Date: Tue, 20 Apr 2021 11:08:30 -0700 Subject: [PATCH 334/780] Move contains to "other" applicator section --- jsonschema-core.xml | 81 +++++++++++++++++++++++---------------------- 1 file changed, 42 insertions(+), 39 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 60a89889..0703ca89 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2367,45 +2367,6 @@ Implementations that do not support annotation collection MUST do so. </t> </section> - - <section title="contains"> - <t> - The value of this keyword MUST be a valid JSON Schema. - </t> - <t> - An array instance is valid against "contains" if at least one of - its elements is valid against the given schema, - except when "minContains" is present and has a value of 0, in which - case an array instance MUST be considered valid against the "contains" keyword, - even if none of its elements is valid against the given schema. - </t> - <t> - An object instance is valid against "contains" if at least one of - its properties is valid against the given schema, - except when "minContains" is present and has a value of 0, in which - case an object instance MUST be considered valid against the "contains" keyword, - even if none of its property values is valid against the given schema. - </t> - <t> - This keyword produces an annotation value which is an array of the - indexes or property names to which this keyword validates successfully - when applying its subschema, in ascending order. The value MAY be a - boolean "true" if the subschema validates successfully when applied to - every index or property value of the instance. The annotation MUST be - present if the instance array or object to which this keyword's schema - applies is empty. - </t> - <t> - This annotation affects the behavior of "unevaluatedItems" in the - Unevaluated vocabulary, and MAY also be used to implement the - "minContains" and "maxContains" keywords in the Validation vocabulary. - </t> - <t> - The subschema MUST be applied to every array element even after the first - match has been found, in order to collect annotations for use by other - keywords. This is to ensure that all possible annotations are collected. - </t> - </section> </section> <section title="Keywords for Applying Subschemas to Objects"> @@ -2517,6 +2478,48 @@ </t> </section> </section> + + <section title="Other Keywords for Applying Subschemas"> + + <section title="contains"> + <t> + The value of this keyword MUST be a valid JSON Schema. + </t> + <t> + An array instance is valid against "contains" if at least one of + its elements is valid against the given schema, + except when "minContains" is present and has a value of 0, in which + case an array instance MUST be considered valid against the "contains" keyword, + even if none of its elements is valid against the given schema. + </t> + <t> + An object instance is valid against "contains" if at least one of + its properties is valid against the given schema, + except when "minContains" is present and has a value of 0, in which + case an object instance MUST be considered valid against the "contains" keyword, + even if none of its property values is valid against the given schema. + </t> + <t> + This keyword produces an annotation value which is an array of the + indexes or property names to which this keyword validates successfully + when applying its subschema, in ascending order. The value MAY be a + boolean "true" if the subschema validates successfully when applied to + every index or property value of the instance. The annotation MUST be + present if the instance array or object to which this keyword's schema + applies is empty. + </t> + <t> + This annotation affects the behavior of "unevaluatedItems" in the + Unevaluated vocabulary, and MAY also be used to implement the + "minContains" and "maxContains" keywords in the Validation vocabulary. + </t> + <t> + The subschema MUST be applied to every array element even after the first + match has been found, in order to collect annotations for use by other + keywords. This is to ensure that all possible annotations are collected. + </t> + </section> + </section> </section> </section> From 2480128c4ceb9ba43593e7bba2679851160a9b4c Mon Sep 17 00:00:00 2001 From: Jason Desrosiers <jdesrosi@gmail.com> Date: Tue, 20 Apr 2021 11:09:03 -0700 Subject: [PATCH 335/780] Clarify that "length" applies to objects as well as arrays --- jsonschema-validation.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 12652584..c1b0c9b1 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -419,8 +419,8 @@ <xref target="json-schema">"contains"</xref> keyword. The first way is if the annotation result is an array and the length of that array is less than or equal to the "maxContains" value. The second way is if the annotation - result is a boolean "true" and the instance length is less than or equal to - the "maxContains" value. + result is a boolean "true" and the instance length (number of items or + properties) is less than or equal to the "maxContains" value. </t> </section> @@ -438,8 +438,8 @@ <xref target="json-schema">"contains"</xref> keyword. The first way is if the annotation result is an array and the length of that array is greater than or equal to the "minContains" value. The second way is if the - annotation result is a boolean "true" and the instance length is greater - than or equal to the "minContains" value. + annotation result is a boolean "true" and the instance length (number of + items or properties) is greater than or equal to the "minContains" value. </t> <t> A value of 0 is allowed, but is only useful for setting a range From 7380cf051d261488f88a449d20eea4481e422408 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers <jdesrosi@gmail.com> Date: Fri, 14 May 2021 11:37:48 -0700 Subject: [PATCH 336/780] Add change log for bhutton-next --- jsonschema-core.xml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0703ca89..6eaa0583 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3891,6 +3891,10 @@ https://example.com/schemas/common#/$defs/count/minimum </t> <t> <list style="hanging"> + <t hangText="draft-bhutton-json-schema-next"> + <list style="symbols"> + </list> + </t> <t hangText="draft-bhutton-json-schema-01"> <list style="symbols"> <t>Improve and clarify the "type", "contains", "unevaluatedProperties", and "unevaluatedItems" keyword explanations</t> From 3de561426427dc0c2efba129d2504df94071d978 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers <jdesrosi@gmail.com> Date: Fri, 14 May 2021 11:40:24 -0700 Subject: [PATCH 337/780] Add to change log "contains" applies to objects --- jsonschema-core.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 6eaa0583..3621f78d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3893,6 +3893,7 @@ https://example.com/schemas/common#/$defs/count/minimum <list style="hanging"> <t hangText="draft-bhutton-json-schema-next"> <list style="symbols"> + <t>"contains" now applies to objects as well as arrays</t> </list> </t> <t hangText="draft-bhutton-json-schema-01"> From 7d9aa8ed9d2af77a15674e697e5a4d4096f24019 Mon Sep 17 00:00:00 2001 From: Henry Andrews <andrews_henry@yahoo.com> Date: Wed, 11 Aug 2021 07:05:07 -0700 Subject: [PATCH 338/780] Document new branching process (#1115) --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ddeda4cd..3e21ad31 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -22,7 +22,7 @@ If the pull request would solve a particular issue, reference the issue in the p Changes that would affect implementation behavior should typically be opened as an issue first. -Pull requests should be made to master. +Pull requests should be made to the default branch, which may be `draft-patch`, `draft-next`, or `master` depending on where we are in the [release process](https://github.com/json-schema-org/community/discussions/7). Most PRs, including all PRs that impact implementation behavior, will be left open for a minimum of 14 days. Minor wording fixes may be merged more quickly once approved by a project member. @@ -78,4 +78,4 @@ Support this project with your organization. Your logo will show up here with a <a href="https://opencollective.com/json-schema/organization/6/website"><img src="https://opencollective.com/json-schema/organization/6/avatar.svg"></a> <a href="https://opencollective.com/json-schema/organization/7/website"><img src="https://opencollective.com/json-schema/organization/7/avatar.svg"></a> <a href="https://opencollective.com/json-schema/organization/8/website"><img src="https://opencollective.com/json-schema/organization/8/avatar.svg"></a> -<a href="https://opencollective.com/json-schema/organization/9/website"><img src="https://opencollective.com/json-schema/organization/9/avatar.svg"></a> \ No newline at end of file +<a href="https://opencollective.com/json-schema/organization/9/website"><img src="https://opencollective.com/json-schema/organization/9/avatar.svg"></a> From 531ee1548941e7c410f60b43e615dc3d1958596b Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Fri, 27 Aug 2021 10:03:08 +0100 Subject: [PATCH 339/780] Add Code of Conduct badge --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 69147dea..6567d2d0 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ # Welcome to JSON Schema -[![Financial Contributors on Open Collective](https://opencollective.com/json-schema/all/badge.svg?label=financial+contributors)](https://opencollective.com/json-schema) +[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg)](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md) [![Financial Contributors on Open Collective](https://opencollective.com/json-schema/all/badge.svg?label=financial+contributors)](https://opencollective.com/json-schema) JSON Schema is a vocabulary that allows you to validate, annotate, and manipulate JSON documents. From dbe4e0018f32a25f1b5d4a6e008208aa99dce6e2 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers <jdesrosi@gmail.com> Date: Wed, 13 Oct 2021 18:21:07 -0700 Subject: [PATCH 340/780] Add "contains" to keywords that effect "unevaluatedProperties" --- jsonschema-core.xml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 3621f78d..a14c1063 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2581,7 +2581,7 @@ <t> "unevaluatedProperties", whose behavior is defined in terms of annotations from "properties", "patternProperties", - "additionalProperties" and itself + "additionalProperties", "contains", and itself </t> </list> </t> @@ -2638,9 +2638,9 @@ The behavior of this keyword depends on the annotation results of adjacent keywords that apply to the instance location being validated. Specifically, the annotations from "properties", "patternProperties", - and "additionalProperties", which can come from those keywords when + "contains", and "additionalProperties", which can come from those keywords when they are adjacent to the "unevaluatedProperties" keyword. Those - three annotations, as well as "unevaluatedProperties", can also + four annotations, as well as "unevaluatedProperties", can also result from any and all adjacent <xref target="in-place">in-place applicator</xref> keywords. This includes but is not limited to the in-place applicators @@ -2649,7 +2649,7 @@ <t> Validation with "unevaluatedProperties" applies only to the child values of instance names that do not appear in the "properties", - "patternProperties", "additionalProperties", or + "patternProperties", "additionalProperties", "contains", or "unevaluatedProperties" annotation results that apply to the instance location being validated. </t> @@ -2659,7 +2659,7 @@ </t> <t> This means that "properties", "patternProperties", "additionalProperties", - and all in-place applicators MUST be evaluated before this keyword can + "contains" and all in-place applicators MUST be evaluated before this keyword can be evaluated. Authors of extension keywords MUST NOT define an in-place applicator that would need to be evaluated after this keyword. </t> From db15f3df1529f3a359f6affe720a34d185cd2769 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jakub=20Kl=C3=ADmek?= <jakub@jakubklimek.com> Date: Fri, 5 Nov 2021 21:48:08 +0100 Subject: [PATCH 341/780] Support for IRI references (#1137) * Change URIs to IRIs where appropriate --- jsonschema-core.xml | 348 ++++++++++++++++++++------------------ jsonschema-validation.xml | 41 +++-- meta/core.json | 18 +- 3 files changed, 211 insertions(+), 196 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index a14c1063..479b4987 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2,6 +2,7 @@ <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml"> +<!ENTITY RFC3987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3987.xml"> <!ENTITY RFC6596 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6596.xml"> <!ENTITY RFC6839 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6839.xml"> <!ENTITY RFC6901 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6901.xml"> @@ -206,7 +207,7 @@ </t> <t> Among these, this specification defines the "application/schema-instance+json" - media type which defines handling for fragments in the URI. + media type which defines handling for fragments in the IRI. </t> <section title="Instance Data Model"> @@ -316,8 +317,8 @@ of five categories: <list style="hanging"> <t hangText="identifiers:"> - control schema identification through setting a URI - for the schema and/or changing how the base URI is determined + control schema identification through setting a IRI + for the schema and/or changing how the base IRI is determined </t> <t hangText="assertions:"> produce a boolean result when applied to an instance @@ -394,7 +395,7 @@ <t> Vocabularies are the primary unit of re-use in JSON Schema, as schema authors can indicate what vocabularies are required or optional in - order to process the schema. Since vocabularies are identified by URIs + order to process the schema. Since vocabularies are identified by IRIs in the meta-schema, generic implementations can load extensions to support previously unknown vocabularies. While keywords can be supported outside of any vocabulary, there is no analogous mechanism to indicate individual @@ -427,18 +428,18 @@ <t> A JSON Schema resource is a schema which is <xref target="RFC6596">canonically</xref> identified by an - <xref target="RFC3986">absolute URI</xref>. Schema resources MAY - also be identified by URIs, including URIs with fragments, + <xref target="RFC3987">absolute IRI</xref>. Schema resources MAY + also be identified by IRIs, including IRIs with fragments, if the resulting secondary resource (as defined by <xref target="RFC3986">section 3.5 of RFC 3986</xref>) is identical to the primary resource. This can occur with the empty fragment, - or when one schema resource is embedded in another. Any such URIs + or when one schema resource is embedded in another. Any such IRIs with fragments are considered to be non-canonical. </t> <t> The root schema is the schema that comprises the entire JSON document in question. The root schema is always a schema resource, where the - URI is determined as described in section + IRI is determined as described in section <xref target="initial-base" format="counter"></xref>. <cref> Note that documents that embed schemas in another format will not @@ -502,7 +503,7 @@ fragment identifier structure: JSON Pointers. </t> <t> - The use of JSON Pointers as URI fragment identifiers is described in + The use of JSON Pointers as IRI fragment identifiers is described in <xref target="RFC6901">RFC 6901</xref>. For "application/schema+json", which supports two fragment identifier syntaxes, fragment identifiers matching the JSON Pointer syntax, including the empty string, @@ -658,9 +659,9 @@ schema object with no subschemas. </t> <t> - Keywords MAY be defined with a partial value, such as a URI-reference, + Keywords MAY be defined with a partial value, such as a IRI-reference, which must be resolved against another value, such as another - URI-reference or a full URI, which is found through the lexical + IRI-reference or a full IRI, which is found through the lexical structure of the JSON document. The "$id", "$ref", and "$dynamicRef" core keywords, and the "base" JSON Hyper-Schema keyword, are examples of this sort of behavior. @@ -745,20 +746,20 @@ </section> <section title="Identifiers"> <t> - Identifiers define URIs for a schema, or affect how such URIs are + Identifiers define IRIs for a schema, or affect how such IRIs are resolved in <xref target="references">references</xref>, or both. The Core vocabulary defined in this document defines several identifying keywords, most notably "$id". </t> <t> - Canonical schema URIs MUST NOT change while processing an instance, but - keywords that affect URI-reference resolution MAY have behavior that + Canonical schema IRIs MUST NOT change while processing an instance, but + keywords that affect IRI-reference resolution MAY have behavior that is only fully determined at runtime. </t> <t> While custom identifier keywords are possible, vocabulary designers should take care not to disrupt the functioning of core keywords. For example, - the "$dynamicAnchor" keyword in this specification limits its URI resolution + the "$dynamicAnchor" keyword in this specification limits its IRI resolution effects to the matching "$dynamicRef" keyword, leaving the behavior of "$ref" undisturbed. </t> @@ -933,7 +934,7 @@ such as "$ref" were followed to reach the absolute schema location. </t> <t> - The absolute schema location of the attaching keyword, as a URI. + The absolute schema location of the attaching keyword, as a IRI. This MAY be omitted if it is the same as the schema location path from above. </t> @@ -1137,14 +1138,14 @@ </t> <t> Meta-schemas that do not use "$vocabulary" MUST be considered to - require the Core vocabulary as if its URI were present with a value of true. + require the Core vocabulary as if its IRI were present with a value of true. </t> <t> - The current URI for the Core vocabulary is: + The current IRI for the Core vocabulary is: <https://json-schema.org/draft/2020-12/vocab/core>. </t> <t> - The current URI for the corresponding meta-schema is: + The current IRI for the corresponding meta-schema is: <eref target="https://json-schema.org/draft/2020-12/meta/core"/>. </t> <t> @@ -1196,12 +1197,12 @@ set of valid schemas written for this particular dialect. </t> <t> - The value of this keyword MUST be a <xref target="RFC3986">URI</xref> - (containing a scheme) and this URI MUST be normalized. - The current schema MUST be valid against the meta-schema identified by this URI. + The value of this keyword MUST be a <xref target="RFC3987">IRI</xref> + (containing a scheme) and this IRI MUST be normalized. + The current schema MUST be valid against the meta-schema identified by this IRI. </t> <t> - If this URI identifies a retrievable resource, that resource SHOULD be of + If this IRI identifies a retrievable resource, that resource SHOULD be of media type "application/schema+json". </t> <t> @@ -1228,15 +1229,15 @@ </t> <t> The value of this keyword MUST be an object. The property names in the - object MUST be URIs (containing a scheme) and this URI MUST be normalized. - Each URI that appears as a property name identifies a specific set of + object MUST be IRIs (containing a scheme) and this IRI MUST be normalized. + Each IRI that appears as a property name identifies a specific set of keywords and their semantics. </t> <t> - The URI MAY be a URL, but the nature of the retrievable resource is + The IRI MAY be a URL, but the nature of the retrievable resource is currently undefined, and reserved for future use. Vocabulary authors MAY use the URL of the vocabulary specification, in a human-readable - media type such as text/html or text/plain, as the vocabulary URI. + media type such as text/html or text/plain, as the vocabulary IRI. <cref> Vocabulary documents may be added in forthcoming drafts. For now, identifying the keyword set is deemed sufficient as that, @@ -1277,7 +1278,7 @@ <t> If "$vocabulary" is absent, an implementation MAY determine behavior based on the meta-schema if it is recognized from the - URI value of the referring schema's "$schema" keyword. + IRI value of the referring schema's "$schema" keyword. This is how behavior (such as Hyper-Schema usage) has been recognized prior to the existence of vocabularies. </t> @@ -1317,60 +1318,60 @@ </t> </section> </section> - <section title="Updates to Meta-Schema and Vocabulary URIs"> + <section title="Updates to Meta-Schema and Vocabulary IRIs"> <t> - Updated vocabulary and meta-schema URIs MAY be published between + Updated vocabulary and meta-schema IRIs MAY be published between specification drafts in order to correct errors. Implementations - SHOULD consider URIs dated after this specification draft and + SHOULD consider IRIs dated after this specification draft and before the next to indicate the same syntax and semantics as those listed here. </t> </section> </section> - <section title="Base URI, Anchors, and Dereferencing"> + <section title="Base IRI, Anchors, and Dereferencing"> <t> To differentiate between schemas in a vast ecosystem, schemas are - identified by <xref target="RFC3986">URI</xref>, and can embed references - to other schemas by specifying their URI. + identified by <xref target="RFC3987">IRI</xref>, and can embed references + to other schemas by specifying their IRI. </t> <t> - Several keywords can accept a relative <xref target="RFC3986">URI-reference</xref>, - or a value used to construct a relative URI-reference. For these keywords, - it is necessary to establish a base URI in order to resolve the reference. + Several keywords can accept a relative <xref target="RFC3987">IRI-reference</xref>, + or a value used to construct a relative IRI-reference. For these keywords, + it is necessary to establish a base IRI in order to resolve the reference. </t> <section title='The "$id" Keyword' anchor="id-keyword"> <t> The "$id" keyword identifies a schema resource with its - <xref target="RFC6596">canonical</xref> URI. + <xref target="RFC6596">canonical</xref> IRI. </t> <t> - Note that this URI is an identifier and not necessarily a network locator. + Note that this IRI is an identifier and not necessarily a network locator. In the case of a network-addressable URL, a schema need not be downloadable - from its canonical URI. + from its canonical IRI. </t> <t> If present, the value for this keyword MUST be a string, and MUST represent a - valid <xref target="RFC3986">URI-reference</xref>. This URI-reference + valid <xref target="RFC3987">IRI-reference</xref>. This IRI-reference SHOULD be normalized, and MUST resolve to an - <xref target="RFC3986">absolute-URI</xref> (without a fragment), - or to a URI with an empty fragment. + <xref target="RFC3987">absolute-IRI</xref> (without a fragment), + or to a IRI with an empty fragment. </t> <t> The empty fragment form is NOT RECOMMENDED and is retained only for backwards compatibility, and because the - application/schema+json media type defines that a URI with an - empty fragment identifies the same resource as the same URI + application/schema+json media type defines that a IRI with an + empty fragment identifies the same resource as the same IRI with the fragment removed. However, since this equivalence is not part of the <xref target="RFC3986">RFC 3986 normalization process</xref>, - implementers and schema authors cannot rely on generic URI libraries + implementers and schema authors cannot rely on generic IRI libraries understanding it. </t> <t> Therefore, "$id" MUST NOT contain a non-empty fragment, and SHOULD NOT - contain an empty fragment. The absolute-URI form MUST be considered - the canonical URI, regardless of the presence or absence of an empty fragment. + contain an empty fragment. The absolute-IRI form MUST be considered + the canonical IRI, regardless of the presence or absence of an empty fragment. <cref> An empty fragment is currently allowed because older meta-schemas have an empty fragment in their $id (or previously, id). @@ -1378,28 +1379,30 @@ </cref> </t> <t> - The absolute-URI also serves as the base URI for relative URI-references + The absolute-IRI also serves as the base IRI for relative IRI-references in keywords within the schema resource, in accordance with - <xref target="RFC3986">RFC 3986 section 5.1.1</xref> regarding base URIs + <xref target="RFC3987">RFC 3987 section 6.5</xref> and + <xref target="RFC3986">RFC 3986 section 5.1.1</xref> regarding base IRIs embedded in content. </t> <t> The presence of "$id" in a subschema indicates that the subschema constitutes a distinct schema resource within a single schema document. Furthermore, - in accordance with <xref target="RFC3986">RFC 3986 section 5.1.2</xref> - regarding encapsulating entities, if an "$id" in a subschema is a relative - URI-reference, the base URI for resolving that reference is the URI of + in accordance with <xref target="RFC3987">RFC 3987 section 6.5</xref> and + <xref target="RFC3986">RFC 3986 section 5.1.2</xref> regarding + encapsulating entities, if an "$id" in a subschema is a relative + IRI-reference, the base IRI for resolving that reference is the IRI of the parent schema resource. </t> <t> If no parent schema object explicitly identifies itself as a resource - with "$id", the base URI is that of the entire document, as established + with "$id", the base IRI is that of the entire document, as established by the steps given in the <xref target="initial-base">previous section.</xref> </t> <section title="Identifying the root schema"> <t> The root schema of a JSON Schema document SHOULD contain an "$id" keyword - with an <xref target="RFC3986">absolute-URI</xref> (containing a scheme, + with an <xref target="RFC3987">absolute-IRI</xref> (containing a scheme, but no fragment). </t> </section> @@ -1415,17 +1418,19 @@ <t> The "$anchor" and "$dynamicAnchor" keywords are used to specify such fragments. They are identifier keywords that can only be used to create - plain name fragments, rather than absolute URIs as seen with "$id". + plain name fragments, rather than absolute IRIs as seen with "$id". </t> <t> - The base URI to which the resulting fragment is appended is the canonical - URI of the schema resource containing the "$anchor" or "$dynamicAnchor" + The base IRI to which the resulting fragment is appended is the canonical + IRI of the schema resource containing the "$anchor" or "$dynamicAnchor" in question. As discussed in the previous section, this is either the - nearest "$id" in the same or parent schema object, or the base URI - for the document as determined according to RFC 3986. + nearest "$id" in the same or parent schema object, + or the base IRI for the document as determined according to + <xref target="RFC3987">RFC 3987</xref> and + <xref target="RFC3986">RFC 3986</xref>. </t> <t> - Separately from the usual usage of URIs, "$dynamicAnchor" + Separately from the usual usage of IRIs, "$dynamicAnchor" indicates that the fragment is an extension point when used with the "$dynamicRef" keyword. This low-level, advanced feature makes it easier to extend recursive schemas such as the meta-schemas, @@ -1447,8 +1452,8 @@ <xref target="xml-names">NCName production</xref>. <cref> Note that the anchor string does not include the "#" character, - as it is not a URI-reference. An "$anchor": "foo" becomes the - fragment "#foo" when used in a URI. See below for full examples. + as it is not a IRI-reference. An "$anchor": "foo" becomes the + fragment "#foo" when used in a IRI. See below for full examples. </cref> </t> <t> @@ -1466,17 +1471,17 @@ keywords, applying the referenced schema to the instance. </t> <t> - As the values of "$ref" and "$dynamicRef" are URI References, this allows + As the values of "$ref" and "$dynamicRef" are IRI References, this allows the possibility to externalise or divide a schema across multiple files, and provides the ability to validate recursive structures through self-reference. </t> <t> - The resolved URI produced by these keywords is not necessarily a network + The resolved IRI produced by these keywords is not necessarily a network locator, only an identifier. A schema need not be downloadable from the address if it is a network-addressable URL, and implementations SHOULD NOT assume they should perform a network operation when they encounter - a network-addressable URI. + a network-addressable IRI. </t> <section title='Direct References with "$ref"' anchor="ref"> @@ -1489,8 +1494,8 @@ </cref> </t> <t> - The value of the "$ref" keyword MUST be a string which is a URI-Reference. - Resolved against the current URI base, it produces the URI of the schema + The value of the "$ref" keyword MUST be a string which is a IRI-Reference. + Resolved against the current IRI base, it produces the IRI of the schema to apply. This resolution is safe to perform on schema load, as the process of evaluating an instance cannot change how the reference resolves. </t> @@ -1512,14 +1517,14 @@ </t> <t> The value of the "$dynamicRef" property MUST be a string which is - a URI-Reference. Resolved against the current URI base, it produces - the URI used as the starting point for runtime resolution. This initial + a IRI-Reference. Resolved against the current IRI base, it produces + the IRI used as the starting point for runtime resolution. This initial resolution is safe to perform on schema load. </t> <t> - If the initially resolved starting point URI includes a fragment that - was created by the "$dynamicAnchor" keyword, the initial URI MUST be - replaced by the URI (including the fragment) for the outermost schema + If the initially resolved starting point IRI includes a fragment that + was created by the "$dynamicAnchor" keyword, the initial IRI MUST be + replaced by the IRI (including the fragment) for the outermost schema resource in the <xref target="scopes">dynamic scope</xref> that defines an identically named fragment with "$dynamicAnchor". </t> @@ -1616,44 +1621,47 @@ <t> </t> <section title="Loading a Schema"> - <section title="Initial Base URI" anchor="initial-base"> + <section title="Initial Base IRI" anchor="initial-base"> <t> - <xref target="RFC3986">RFC3986 Section 5.1</xref> defines how to determine the - default base URI of a document. + <xref target="RFC3987">RFC 3987 Section 6.5</xref> and + <xref target="RFC3986">RFC 3986 Section 5.1</xref> defines how to determine the + default base IRI of a document. </t> <t> - Informatively, the initial base URI of a schema is the URI at which it was + Informatively, the initial base IRI of a schema is the IRI at which it was found, whether that was a network location, a local filesystem, or any other - situation identifiable by a URI of any known scheme. + situation identifiable by a IRI of any known scheme. </t> <t> - If a schema document defines no explicit base URI with "$id" - (embedded in content), the base URI is that determined per + If a schema document defines no explicit base IRI with "$id" + (embedded in content), the base IRI is that determined per + <xref target="RFC3987">RFC 3987 Section 6.5</xref> and <xref target="RFC3986">RFC 3986 section 5</xref>. </t> <t> - If no source is known, or no URI scheme is known for the source, a suitable - implementation-specific default URI MAY be used as described in - <xref target="RFC3986"> RFC 3986 Section 5.1.4</xref>. It is RECOMMENDED - that implementations document any default base URI that they assume. + If no source is known, or no IRI scheme is known for the source, a suitable + implementation-specific default IRI MAY be used as described in + <xref target="RFC3987">RFC 3987 Section 6.5</xref> and + <xref target="RFC3986">RFC 3986 Section 5.1.4</xref>. It is RECOMMENDED + that implementations document any default base IRI that they assume. </t> <t> If a schema object is embedded in a document of another media type, then - the initial base URI is determined according to the rules of that + the initial base IRI is determined according to the rules of that media type. </t> <t> Unless the "$id" keyword described in an earlier section is present in the - root schema, this base URI SHOULD be considered the canonical URI of the + root schema, this base IRI SHOULD be considered the canonical IRI of the schema document's root schema resource. </t> </section> <section title="Loading a referenced schema"> <t> - The use of URIs to identify remote schemas does not necessarily mean anything is downloaded, + The use of IRIs to identify remote schemas does not necessarily mean anything is downloaded, but instead JSON Schema implementations SHOULD understand ahead of time which schemas they will be using, - and the URIs that identify them. + and the IRIs that identify them. </t> <t> When schemas are downloaded, @@ -1661,17 +1669,17 @@ see <xref target="hypermedia">Usage for Hypermedia</xref>. </t> <t> - Implementations SHOULD be able to associate arbitrary URIs with an arbitrary - schema and/or automatically associate a schema's "$id"-given URI, depending - on the trust that the validator has in the schema. Such URIs and schemas + Implementations SHOULD be able to associate arbitrary IRIs with an arbitrary + schema and/or automatically associate a schema's "$id"-given IRI, depending + on the trust that the validator has in the schema. Such IRIs and schemas can be supplied to an implementation prior to processing instances, or may be noted within a schema document as it is processed, producing associations as shown in appendix <xref target="idExamples" format="counter"></xref>. </t> <t> - A schema MAY (and likely will) have multiple URIs, but there is no way for a - URI to identify more than one schema. When multiple schemas try to identify - as the same URI, validators SHOULD raise an error condition. + A schema MAY (and likely will) have multiple IRIs, but there is no way for a + IRI to identify more than one schema. When multiple schemas try to identify + as the same IRI, validators SHOULD raise an error condition. </t> </section> @@ -1703,14 +1711,14 @@ <section title="Dereferencing"> <t> - Schemas can be identified by any URI that has been given to them, including - a JSON Pointer or their URI given directly by "$id". In all cases, + Schemas can be identified by any IRI that has been given to them, including + a JSON Pointer or their IRI given directly by "$id". In all cases, dereferencing a "$ref" reference involves first resolving its value as a - URI reference against the current base URI per + IRI reference against the current base IRI per <xref target="RFC3986">RFC 3986</xref>. </t> <t> - If the resulting URI identifies a schema within the current document, or + If the resulting IRI identifies a schema within the current document, or within another schema document that has been made available to the implementation, then that schema SHOULD be used automatically. </t> @@ -1741,7 +1749,7 @@ <t> When an implementation encounters the <#/$defs/single> schema, it resolves the "$anchor" value as a fragment name against the current - base URI to form <https://example.net/root.json#item>. + base IRI to form <https://example.net/root.json#item>. </t> <t> When an implementation then looks inside the <#/items> schema, it @@ -1767,10 +1775,10 @@ <section title="JSON Pointer fragments and embedded schema resources" anchor="embedded"> <t> - Since JSON Pointer URI fragments are constructed based on the structure + Since JSON Pointer IRI fragments are constructed based on the structure of the schema document, an embedded schema resource and its subschemas can be identified by JSON Pointer fragments relative to either its own - canonical URI, or relative to any containing resource's URI. + canonical IRI, or relative to any containing resource's IRI. </t> <t> Conceptually, a set of linked schema resources should behave @@ -1780,10 +1788,10 @@ subschemas. </t> <t> - Since URIs involving JSON Pointer fragments relative to the parent - schema resource's URI cease to be valid when the embedded schema + Since IRIs involving JSON Pointer fragments relative to the parent + schema resource's IRI cease to be valid when the embedded schema is moved to a separate document and referenced, applications and schemas - SHOULD NOT use such URIs to identify embedded schema resources or + SHOULD NOT use such IRIs to identify embedded schema resources or locations within them. </t> <figure> @@ -1804,20 +1812,20 @@ </artwork> </figure> <t> - The URI "https://example.com/foo#/items" points to the "items" schema, - which is an embedded resource. The canonical URI of that schema + The IRI "https://example.com/foo#/items" points to the "items" schema, + which is an embedded resource. The canonical IRI of that schema resource, however, is "https://example.com/bar". </t> <t> For the "additionalProperties" schema within that embedded resource, - the URI "https://example.com/foo#/items/additionalProperties" points - to the correct object, but that object's URI relative to its resource's - canonical URI is "https://example.com/bar#/additionalProperties". + the IRI "https://example.com/foo#/items/additionalProperties" points + to the correct object, but that object's IRI relative to its resource's + canonical IRI is "https://example.com/bar#/additionalProperties". </t> <figure> <preamble> Now consider the following two schema resources linked by reference - using a URI value for "$ref": + using a IRI value for "$ref": </preamble> <artwork> <![CDATA[ @@ -1836,29 +1844,29 @@ </artwork> <postamble> Here we see that "https://example.com/bar#/additionalProperties", - using a JSON Pointer fragment appended to the canonical URI of + using a JSON Pointer fragment appended to the canonical IRI of the "bar" schema resource, is still valid, while "https://example.com/foo#/items/additionalProperties", which relied - on a JSON Pointer fragment appended to the canonical URI of the + on a JSON Pointer fragment appended to the canonical IRI of the "foo" schema resource, no longer resolves to anything. </postamble> </figure> <t> Note also that "https://example.com/foo#/items" is valid in both - arrangements, but resolves to a different value. This URI ends up - functioning similarly to a retrieval URI for a resource. While this URI + arrangements, but resolves to a different value. This IRI ends up + functioning similarly to a retrieval IRI for a resource. While this IRI is valid, it is more robust to use the "$id" of the embedded or referenced resource unless it is specifically desired to identify the object containing the "$ref" in the second (non-embedded) arrangement. </t> <t> An implementation MAY choose not to support addressing schema resource - contents by URIs using a base other than the resource's canonical URI, + contents by IRIs using a base other than the resource's canonical IRI, plus a JSON Pointer fragment relative to that base. Therefore, schema - authors SHOULD NOT rely on such URIs, as using them may reduce interoperability. + authors SHOULD NOT rely on such IRIs, as using them may reduce interoperability. <cref> This is to avoid requiring implementations to keep track of a whole - stack of possible base URIs and JSON Pointer fragments for each, + stack of possible base IRIs and JSON Pointer fragments for each, given that all but one will be fragile if the schema resources are reorganized. Some have argued that this is easy so there is @@ -1873,8 +1881,8 @@ </cref> </t> <t> - Further examples of such non-canonical URI construction, as well as - the appropriate canonical URI-based fragments to use instead, + Further examples of such non-canonical IRI construction, as well as + the appropriate canonical IRI-based fragments to use instead, are provided in appendix <xref target="idExamples" format="counter"></xref>. </t> </section> @@ -1895,13 +1903,13 @@ The bundling process for creating a Compound Schema Document is defined as taking references (such as "$ref") to an external Schema Resource and embedding the referenced Schema Resources within the referring document. Bundling SHOULD be done in such a way that - all URIs (used for referencing) in the base document and any referenced/embedded + all IRIs (used for referencing) in the base document and any referenced/embedded documents do not require altering. </t> <t> - Each embedded JSON Schema Resource MUST identify itself with a URI using the "$id" keyword, + Each embedded JSON Schema Resource MUST identify itself with a IRI using the "$id" keyword, and SHOULD make use of the "$schema" keyword to identify the dialect it is using, in the root of the - schema resource. It is RECOMMENDED that the URI identifier value of "$id" be an Absolute URI. + schema resource. It is RECOMMENDED that the IRI identifier value of "$id" be an Absolute IRI. </t> <t> When the Schema Resource referenced by a by-reference applicator is bundled, it is RECOMMENDED that @@ -1922,7 +1930,7 @@ <t> In order to produce identical output, references in the containing schema document to the previously external Schema Resources MUST NOT be changed, and now resolve to a schema using the - "$id" of an embedded Schema Resource. Such identical output includes validation evaluation and URIs + "$id" of an embedded Schema Resource. Such identical output includes validation evaluation and IRIs or paths used in resulting annotations or errors. </t> <t> @@ -2092,14 +2100,14 @@ </t> <t> Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its URI were present with a value of true. + require this vocabulary as if its IRI were present with a value of true. </t> <t> - The current URI for this vocabulary, known as the Applicator vocabulary, is: + The current IRI for this vocabulary, known as the Applicator vocabulary, is: <https://json-schema.org/draft/2020-12/vocab/applicator>. </t> <t> - The current URI for the corresponding meta-schema is: + The current IRI for the corresponding meta-schema is: <eref target="https://json-schema.org/draft/2020-12/meta/applicator"/>. </t> <section title="Keyword Independence"> @@ -2556,15 +2564,15 @@ </t> <t> Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its URI were present with a value of true. + require this vocabulary as if its IRI were present with a value of true. </t> <t> - The current URI for this vocabulary, known as the Unevaluated Applicator + The current IRI for this vocabulary, known as the Unevaluated Applicator vocabulary, is: <https://json-schema.org/draft/2020-12/vocab/unevaluated>. </t> <t> - The current URI for the corresponding meta-schema is: + The current IRI for the corresponding meta-schema is: <eref target="https://json-schema.org/draft/2020-12/meta/unevaluated"/>. </t> @@ -2760,15 +2768,15 @@ <section title="Keyword Absolute Location"> <t> The absolute, dereferenced location of the validating keyword. The value MUST - be expressed as a full URI using the canonical URI of the relevant schema resource + be expressed as a full IRI using the canonical IRI of the relevant schema resource with a JSON Pointer fragment, and it MUST NOT include by-reference applicators such as "$ref" or "$dynamicRef" as non-terminal path components. It MAY end in such keywords if the error or annotation is for that keyword, such as an unresolvable reference. <cref> Note that "absolute" here is in the sense of "absolute filesystem path" - (meaning the complete location) rather than the "absolute-URI" - terminology from RFC 3986 (meaning with scheme but without fragment). + (meaning the complete location) rather than the "absolute-IRI" + terminology from RFC 3987 (meaning with scheme but without fragment). Keyword absolute locations will have a fragment in order to identify the keyword. </cref> @@ -2782,7 +2790,7 @@ https://example.com/schemas/common#/$defs/count/minimum </figure> <t> This information MAY be omitted only if either the dynamic scope did not pass - over a reference or if the schema does not declare an absolute URI as its "$id". + over a reference or if the schema does not declare an absolute IRI as its "$id". </t> <t> The JSON key for this information is "absoluteKeywordLocation". @@ -3069,7 +3077,7 @@ https://example.com/schemas/common#/$defs/count/minimum </t> <t> Because this output structure can be quite large, a smaller example is given - here for brevity. The URI of the full output structure of the example above is: + here for brevity. The IRI of the full output structure of the example above is: <eref target="https://json-schema.org/draft/2020-12/output/verbose-example"/>. </t> <figure> @@ -3131,7 +3139,7 @@ https://example.com/schemas/common#/$defs/count/minimum <section title="Output validation schemas"> <t> For convenience, JSON Schema has been provided to validate output generated - by implementations. Its URI is: + by implementations. Its IRI is: <eref target="https://json-schema.org/draft/2020-12/output/schema"/>. </t> </section> @@ -3247,6 +3255,7 @@ https://example.com/schemas/common#/$defs/count/minimum <references title="Normative References"> &RFC2119; &RFC3986; + &RFC3987; &RFC6839; &RFC6901; &RFC8259; @@ -3360,9 +3369,9 @@ https://example.com/schemas/common#/$defs/count/minimum </artwork> </figure> <t> - The schemas at the following URI-encoded <xref target="RFC6901">JSON + The schemas at the following IRI-encoded <xref target="RFC6901">JSON Pointers</xref> (relative to the root schema) have the following - base URIs, and are identifiable by any listed URI in accordance with + base IRIs, and are identifiable by any listed IRI in accordance with sections <xref target="fragments" format="counter"></xref> and <xref target="embedded" format="counter"></xref> above. </t> @@ -3370,76 +3379,76 @@ https://example.com/schemas/common#/$defs/count/minimum <list style="hanging"> <t hangText="# (document root)"> <list style="hanging"> - <t hangText="canonical (and base) URI"> + <t hangText="canonical (and base) IRI"> https://example.com/root.json </t> - <t hangText="canonical resource URI plus pointer fragment"> + <t hangText="canonical resource IRI plus pointer fragment"> https://example.com/root.json# </t> </list> </t> <t hangText="#/$defs/A"> <list> - <t hangText="base URI">https://example.com/root.json</t> - <t hangText="canonical resource URI plus plain fragment"> + <t hangText="base IRI">https://example.com/root.json</t> + <t hangText="canonical resource IRI plus plain fragment"> https://example.com/root.json#foo </t> - <t hangText="canonical resource URI plus pointer fragment"> + <t hangText="canonical resource IRI plus pointer fragment"> https://example.com/root.json#/$defs/A </t> </list> </t> <t hangText="#/$defs/B"> <list style="hanging"> - <t hangText="canonical (and base) URI">https://example.com/other.json</t> - <t hangText="canonical resource URI plus pointer fragment"> + <t hangText="canonical (and base) IRI">https://example.com/other.json</t> + <t hangText="canonical resource IRI plus pointer fragment"> https://example.com/other.json# </t> - <t hangText="base URI of enclosing (root.json) resource plus fragment"> + <t hangText="base IRI of enclosing (root.json) resource plus fragment"> https://example.com/root.json#/$defs/B </t> </list> </t> <t hangText="#/$defs/B/$defs/X"> <list style="hanging"> - <t hangText="base URI">https://example.com/other.json</t> - <t hangText="canonical resource URI plus plain fragment"> + <t hangText="base IRI">https://example.com/other.json</t> + <t hangText="canonical resource IRI plus plain fragment"> https://example.com/other.json#bar </t> - <t hangText="canonical resource URI plus pointer fragment"> + <t hangText="canonical resource IRI plus pointer fragment"> https://example.com/other.json#/$defs/X </t> - <t hangText="base URI of enclosing (root.json) resource plus fragment"> + <t hangText="base IRI of enclosing (root.json) resource plus fragment"> https://example.com/root.json#/$defs/B/$defs/X </t> </list> </t> <t hangText="#/$defs/B/$defs/Y"> <list style="hanging"> - <t hangText="canonical (and base) URI">https://example.com/t/inner.json</t> - <t hangText="canonical URI plus plain fragment"> + <t hangText="canonical (and base) IRI">https://example.com/t/inner.json</t> + <t hangText="canonical IRI plus plain fragment"> https://example.com/t/inner.json#bar </t> - <t hangText="canonical URI plus pointer fragment"> + <t hangText="canonical IRI plus pointer fragment"> https://example.com/t/inner.json# </t> - <t hangText="base URI of enclosing (other.json) resource plus fragment"> + <t hangText="base IRI of enclosing (other.json) resource plus fragment"> https://example.com/other.json#/$defs/Y </t> - <t hangText="base URI of enclosing (root.json) resource plus fragment"> + <t hangText="base IRI of enclosing (root.json) resource plus fragment"> https://example.com/root.json#/$defs/B/$defs/Y </t> </list> </t> <t hangText="#/$defs/C"> <list style="hanging"> - <t hangText="canonical (and base) URI"> + <t hangText="canonical (and base) IRI"> urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f </t> - <t hangText="canonical URI plus pointer fragment"> + <t hangText="canonical IRI plus pointer fragment"> urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f# </t> - <t hangText="base URI of enclosing (root.json) resource plus fragment"> + <t hangText="base IRI of enclosing (root.json) resource plus fragment"> https://example.com/root.json#/$defs/C </t> </list> @@ -3447,11 +3456,11 @@ https://example.com/schemas/common#/$defs/count/minimum </list> </t> <t> - Note: The fragment part of the URI does not make it canonical or non-canonical, - rather, the base URI used (as part of the full URI with any fragment) is what - determines the canonical nature of the resulting full URI. + Note: The fragment part of the IRI does not make it canonical or non-canonical, + rather, the base IRI used (as part of the full IRI with any fragment) is what + determines the canonical nature of the resulting full IRI. <cref> - Multiple "canonical" URIs? We Acknowledge this is potentially confusing, and + Multiple "canonical" IRIs? We Acknowledge this is potentially confusing, and direct you to read the CREF located in the <xref target="embedded">JSON Pointer fragments and embedded schema resources</xref> section for futher comments. @@ -3482,9 +3491,9 @@ https://example.com/schemas/common#/$defs/count/minimum </t> <t> This transformation can be safely and reversibly done as long as - all static references (e.g. "$ref") use URI-references that resolve - to URIs using the canonical resource URI as the base, and all schema - resources have an absolute-URI as the "$id" in their root schema. + all static references (e.g. "$ref") use IRI-references that resolve + to IRIs using the canonical resource IRI as the base, and all schema + resources have an absolute-IRI as the "$id" in their root schema. </t> <t> With these conditions met, each external resource can be copied @@ -3492,7 +3501,7 @@ https://example.com/schemas/common#/$defs/count/minimum schema objects, and without changing any aspect of validation or annotation results. The names of the schemas under "$defs" do not affect behavior, assuming they are each unique, as they - do not appear in the canonical URIs for the embedded resources. + do not appear in the canonical IRIs for the embedded resources. </t> </section> <section title="Reference removal is not always safe"> @@ -3561,7 +3570,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t> When we load these two schemas, we will notice the "$dynamicAnchor" named "node" (note the lack of "#" as this is just the name) - present in each, resulting in the following full schema URIs: + present in each, resulting in the following full schema IRIs: <list style="symbols"> <t>"https://example.com/tree#node"</t> <t>"https://example.com/strict-tree#node"</t> @@ -3572,9 +3581,9 @@ https://example.com/schemas/common#/$defs/count/minimum <t> If we apply the "strict-tree" schema to the instance, we will follow the "$ref" to the "tree" schema, examine its "children" subschema, - and find the "$dynamicRef": to "#node" (note the "#" for URI fragment syntax) + and find the "$dynamicRef": to "#node" (note the "#" for IRI fragment syntax) in its "items" subschema. That reference resolves to - "https://example.com/tree#node", which is a URI with a fragment + "https://example.com/tree#node", which is a IRI with a fragment created by "$dynamicAnchor". Therefore we must examine the dynamic scope before following the reference. </t> @@ -3778,7 +3787,7 @@ https://example.com/schemas/common#/$defs/count/minimum The standard meta-schemas that combine all vocabularies defined by the Core and Validation specification, and that combine all vocabularies defined by those specifications as well as the Hyper-Schema specification, - demonstrate additional complex combinations. These URIs for these + demonstrate additional complex combinations. These IRIs for these meta-schemas may be found in the Validation and Hyper-Schema specifications, respectively. </t> @@ -3894,6 +3903,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t hangText="draft-bhutton-json-schema-next"> <list style="symbols"> <t>"contains" now applies to objects as well as arrays</t> + <t>Use IRIs instead of URIs</t> </list> </t> <t hangText="draft-bhutton-json-schema-01"> diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index c1b0c9b1..4f78997d 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -177,20 +177,20 @@ <section title="Meta-Schema" anchor="meta-schema"> <t> - The current URI for the default JSON Schema dialect meta-schema is + The current IRI for the default JSON Schema dialect meta-schema is <eref target="https://json-schema.org/draft/2020-12/schema"/>. For schema author convenience, this meta-schema describes a dialect consisting of all vocabularies defined in this specification and the JSON Schema Core specification, as well as two former keywords which are reserved for a transitional period. - Individual vocabulary and vocabulary meta-schema URIs are given for + Individual vocabulary and vocabulary meta-schema IRIs are given for each section below. Certain vocabularies are optional to support, which is explained in detail in the relevant sections. </t> <t> - Updated vocabulary and meta-schema URIs MAY be published between + Updated vocabulary and meta-schema IRIs MAY be published between specification drafts in order to correct errors. Implementations - SHOULD consider URIs dated after this specification draft and + SHOULD consider IRIs dated after this specification draft and before the next to indicate the same syntax and semantics as those listed here. </t> @@ -203,14 +203,14 @@ </t> <t> Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its URI were present with a value of true. + require this vocabulary as if its IRI were present with a value of true. </t> <t> - The current URI for this vocabulary, known as the Validation vocabulary, is: + The current IRI for this vocabulary, known as the Validation vocabulary, is: <https://json-schema.org/draft/2020-12/vocab/validation>. </t> <t> - The current URI for the corresponding meta-schema is: + The current IRI for the corresponding meta-schema is: <eref target="https://json-schema.org/draft/2020-12/meta/validation"/>. </t> @@ -547,18 +547,18 @@ </t> <t> - The current URI for this vocabulary, known as the Format-Annotation vocabulary, is: + The current IRI for this vocabulary, known as the Format-Annotation vocabulary, is: <https://json-schema.org/draft/2020-12/vocab/format-annotation>. The current - URI for the corresponding meta-schema is: + IRI for the corresponding meta-schema is: <eref target="https://json-schema.org/draft/2020-12/meta/format-annotation"/>. Implementing support for this vocabulary is REQUIRED. </t> <t> In addition to the Format-Annotation vocabulary, a secondary vocabulary is available - for custom meta-schemas that defines "format" as an assertion. The URI for the + for custom meta-schemas that defines "format" as an assertion. The IRI for the Format-Assertion vocabulary, is: <https://json-schema.org/draft/2020-12/vocab/format-assertion>. The current - URI for the corresponding meta-schema is: + IRI for the corresponding meta-schema is: <eref target="https://json-schema.org/draft/2020-12/meta/format-assertion"/>. Implementing support for the Format-Assertion vocabulary is OPTIONAL. </t> @@ -819,7 +819,7 @@ <list style="hanging"> <t hangText="uri:"> A string instance is valid against this attribute if it is - a valid URI, according to <xref target="RFC3986"/>. + a valid IRI, according to <xref target="RFC3987"/>. </t> <t hangText="uri-reference:"> A string instance is valid against this attribute if it is a valid URI @@ -920,14 +920,14 @@ </t> <t> Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its URI were present with a value of true. + require this vocabulary as if its IRI were present with a value of true. </t> <t> - The current URI for this vocabulary, known as the Content vocabulary, is: + The current IRI for this vocabulary, known as the Content vocabulary, is: <https://json-schema.org/draft/2020-12/vocab/content>. </t> <t> - The current URI for the corresponding meta-schema is: + The current IRI for the corresponding meta-schema is: <eref target="https://json-schema.org/draft/2020-12/meta/content"/>. </t> </section> @@ -1127,14 +1127,14 @@ </t> <t> Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its URI were present with a value of true. + require this vocabulary as if its IRI were present with a value of true. </t> <t> - The current URI for this vocabulary, known as the Meta-Data vocabulary, is: + The current IRI for this vocabulary, known as the Meta-Data vocabulary, is: <https://json-schema.org/draft/2020-12/vocab/meta-data>. </t> <t> - The current URI for the corresponding meta-schema is: + The current IRI for the corresponding meta-schema is: <eref target="https://json-schema.org/draft/2020-12/meta/meta-data"/>. </t> @@ -1442,6 +1442,11 @@ </t> <t> <list style="hanging"> + <t hangText="draft-next"> + <list style="symbols"> + <t>Use IRIs instead of URIs</t> + </list> + </t> <t hangText="draft-bhutton-json-schema-validation-01"> <list style="symbols"> <t>Improve and clarify the "minContains" keyword explanation</t> diff --git a/meta/core.json b/meta/core.json index dfc092d9..8617b7a8 100644 --- a/meta/core.json +++ b/meta/core.json @@ -10,18 +10,18 @@ "type": ["object", "boolean"], "properties": { "$id": { - "$ref": "#/$defs/uriReferenceString", + "$ref": "#/$defs/iriReferenceString", "$comment": "Non-empty fragments not allowed.", "pattern": "^[^#]*#?$" }, - "$schema": { "$ref": "#/$defs/uriString" }, - "$ref": { "$ref": "#/$defs/uriReferenceString" }, + "$schema": { "$ref": "#/$defs/iriString" }, + "$ref": { "$ref": "#/$defs/iriReferenceString" }, "$anchor": { "$ref": "#/$defs/anchorString" }, - "$dynamicRef": { "$ref": "#/$defs/uriReferenceString" }, + "$dynamicRef": { "$ref": "#/$defs/iriReferenceString" }, "$dynamicAnchor": { "$ref": "#/$defs/anchorString" }, "$vocabulary": { "type": "object", - "propertyNames": { "$ref": "#/$defs/uriString" }, + "propertyNames": { "$ref": "#/$defs/iriString" }, "additionalProperties": { "type": "boolean" } @@ -39,13 +39,13 @@ "type": "string", "pattern": "^[A-Za-z_][-A-Za-z0-9._]*$" }, - "uriString": { + "iriString": { "type": "string", - "format": "uri" + "format": "iri" }, - "uriReferenceString": { + "iriReferenceString": { "type": "string", - "format": "uri-reference" + "format": "iri-reference" } } } From 4920b3642e22a28acfee1c08fc26d26db87f69c1 Mon Sep 17 00:00:00 2001 From: Karen Etheridge <ether@cpan.org> Date: Fri, 19 Nov 2021 07:40:56 -0800 Subject: [PATCH 342/780] update schema identifiers to "draft/next" everywhere, so implementations can start testing with them (#1148) --- jsonschema-core.xml | 42 ++++++++++++++++++------------------- jsonschema-validation.xml | 22 +++++++++---------- meta/applicator.json | 6 +++--- meta/content.json | 6 +++--- meta/core.json | 6 +++--- meta/format-annotation.json | 6 +++--- meta/format-assertion.json | 6 +++--- meta/meta-data.json | 6 +++--- meta/unevaluated.json | 6 +++--- meta/validation.json | 6 +++--- output/schema.json | 4 ++-- schema.json | 18 ++++++++-------- 12 files changed, 67 insertions(+), 67 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 479b4987..abe8a48c 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1142,11 +1142,11 @@ </t> <t> The current IRI for the Core vocabulary is: - <https://json-schema.org/draft/2020-12/vocab/core>. + <https://json-schema.org/draft/next/vocab/core>. </t> <t> The current IRI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-12/meta/core"/>. + <eref target="https://json-schema.org/draft/next/meta/core"/>. </t> <t> While the "$" prefix is not formally reserved for the Core vocabulary, @@ -2104,11 +2104,11 @@ </t> <t> The current IRI for this vocabulary, known as the Applicator vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/applicator>. + <https://json-schema.org/draft/next/vocab/applicator>. </t> <t> The current IRI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-12/meta/applicator"/>. + <eref target="https://json-schema.org/draft/next/meta/applicator"/>. </t> <section title="Keyword Independence"> <t> @@ -2569,11 +2569,11 @@ <t> The current IRI for this vocabulary, known as the Unevaluated Applicator vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/unevaluated>. + <https://json-schema.org/draft/next/vocab/unevaluated>. </t> <t> The current IRI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-12/meta/unevaluated"/>. + <eref target="https://json-schema.org/draft/next/meta/unevaluated"/>. </t> <section title="Keyword Independence"> @@ -2865,7 +2865,7 @@ https://example.com/schemas/common#/$defs/count/minimum <![CDATA[ { "$id": "https://example.com/polygon", - "$schema": "https://json-schema.org/draft/2020-12/schema", + "$schema": "https://json-schema.org/draft/next/schema", "$defs": { "point": { "type": "object", @@ -3078,7 +3078,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t> Because this output structure can be quite large, a smaller example is given here for brevity. The IRI of the full output structure of the example above is: - <eref target="https://json-schema.org/draft/2020-12/output/verbose-example"/>. + <eref target="https://json-schema.org/draft/next/output/verbose-example"/>. </t> <figure> <artwork> @@ -3086,7 +3086,7 @@ https://example.com/schemas/common#/$defs/count/minimum // schema { "$id": "https://example.com/polygon", - "$schema": "https://json-schema.org/draft/2020-12/schema", + "$schema": "https://json-schema.org/draft/next/schema", "type": "object", "properties": { "validProp": true, @@ -3140,7 +3140,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t> For convenience, JSON Schema has been provided to validate output generated by implementations. Its IRI is: - <eref target="https://json-schema.org/draft/2020-12/output/schema"/>. + <eref target="https://json-schema.org/draft/next/output/schema"/>. </t> </section> @@ -3534,7 +3534,7 @@ https://example.com/schemas/common#/$defs/count/minimum <![CDATA[ // tree schema, extensible { - "$schema": "https://json-schema.org/draft/2020-12/schema", + "$schema": "https://json-schema.org/draft/next/schema", "$id": "https://example.com/tree", "$dynamicAnchor": "node", @@ -3552,7 +3552,7 @@ https://example.com/schemas/common#/$defs/count/minimum // strict-tree schema, guards against misspelled properties { - "$schema": "https://json-schema.org/draft/2020-12/schema", + "$schema": "https://json-schema.org/draft/next/schema", "$id": "https://example.com/strict-tree", "$dynamicAnchor": "node", @@ -3725,20 +3725,20 @@ https://example.com/schemas/common#/$defs/count/minimum <artwork> <![CDATA[ { - "$schema": "https://json-schema.org/draft/2020-12/schema", + "$schema": "https://json-schema.org/draft/next/schema", "$id": "https://example.com/meta/general-use-example", "$dynamicAnchor": "meta", "$vocabulary": { - "https://json-schema.org/draft/2020-12/vocab/core": true, - "https://json-schema.org/draft/2020-12/vocab/applicator": true, - "https://json-schema.org/draft/2020-12/vocab/validation": true, + "https://json-schema.org/draft/next/vocab/core": true, + "https://json-schema.org/draft/next/vocab/applicator": true, + "https://json-schema.org/draft/next/vocab/validation": true, "https://example.com/vocab/example-vocab": true }, "allOf": [ - {"$ref": "https://json-schema.org/draft/2020-12/meta/core"}, - {"$ref": "https://json-schema.org/draft/2020-12/meta/applicator"}, - {"$ref": "https://json-schema.org/draft/2020-12/meta/validation"}, - {"$ref": "https://example.com/meta/example-vocab"} + {"$ref": "https://json-schema.org/draft/next/meta/core"}, + {"$ref": "https://json-schema.org/draft/next/meta/applicator"}, + {"$ref": "https://json-schema.org/draft/next/meta/validation"}, + {"$ref": "https://example.com/meta/example-vocab", ], "patternProperties": { "^unevaluated": false @@ -3760,7 +3760,7 @@ https://example.com/schemas/common#/$defs/count/minimum <artwork> <![CDATA[ { - "$schema": "https://json-schema.org/draft/2020-12/schema", + "$schema": "https://json-schema.org/draft/next/schema", "$id": "https://example.com/meta/example-vocab", "$dynamicAnchor": "meta", "$vocabulary": { diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 4f78997d..a8426471 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -178,7 +178,7 @@ <section title="Meta-Schema" anchor="meta-schema"> <t> The current IRI for the default JSON Schema dialect meta-schema is - <eref target="https://json-schema.org/draft/2020-12/schema"/>. + <eref target="https://json-schema.org/draft/next/schema"/>. For schema author convenience, this meta-schema describes a dialect consisting of all vocabularies defined in this specification and the JSON Schema Core specification, @@ -207,11 +207,11 @@ </t> <t> The current IRI for this vocabulary, known as the Validation vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/validation>. + <https://json-schema.org/draft/next/vocab/validation>. </t> <t> The current IRI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-12/meta/validation"/>. + <eref target="https://json-schema.org/draft/next/meta/validation"/>. </t> <section title="Validation Keywords for Any Instance Type" anchor="general"> @@ -548,18 +548,18 @@ <t> The current IRI for this vocabulary, known as the Format-Annotation vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/format-annotation>. The current + <https://json-schema.org/draft/next/vocab/format-annotation>. The current IRI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-12/meta/format-annotation"/>. + <eref target="https://json-schema.org/draft/next/meta/format-annotation"/>. Implementing support for this vocabulary is REQUIRED. </t> <t> In addition to the Format-Annotation vocabulary, a secondary vocabulary is available for custom meta-schemas that defines "format" as an assertion. The IRI for the Format-Assertion vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/format-assertion>. The current + <https://json-schema.org/draft/next/vocab/format-assertion>. The current IRI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-12/meta/format-assertion"/>. + <eref target="https://json-schema.org/draft/next/meta/format-assertion"/>. Implementing support for the Format-Assertion vocabulary is OPTIONAL. </t> <t> @@ -924,11 +924,11 @@ </t> <t> The current IRI for this vocabulary, known as the Content vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/content>. + <https://json-schema.org/draft/next/vocab/content>. </t> <t> The current IRI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-12/meta/content"/>. + <eref target="https://json-schema.org/draft/next/meta/content"/>. </t> </section> @@ -1131,11 +1131,11 @@ </t> <t> The current IRI for this vocabulary, known as the Meta-Data vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/meta-data>. + <https://json-schema.org/draft/next/vocab/meta-data>. </t> <t> The current IRI for the corresponding meta-schema is: - <eref target="https://json-schema.org/draft/2020-12/meta/meta-data"/>. + <eref target="https://json-schema.org/draft/next/meta/meta-data"/>. </t> <section title='"title" and "description"'> diff --git a/meta/applicator.json b/meta/applicator.json index ca699230..948f4193 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://json-schema.org/draft/2020-12/meta/applicator", + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/draft/next/meta/applicator", "$vocabulary": { - "https://json-schema.org/draft/2020-12/vocab/applicator": true + "https://json-schema.org/draft/next/vocab/applicator": true }, "$dynamicAnchor": "meta", diff --git a/meta/content.json b/meta/content.json index 2f6e056a..2c29ee50 100644 --- a/meta/content.json +++ b/meta/content.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://json-schema.org/draft/2020-12/meta/content", + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/draft/next/meta/content", "$vocabulary": { - "https://json-schema.org/draft/2020-12/vocab/content": true + "https://json-schema.org/draft/next/vocab/content": true }, "$dynamicAnchor": "meta", diff --git a/meta/core.json b/meta/core.json index 8617b7a8..087ebd37 100644 --- a/meta/core.json +++ b/meta/core.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://json-schema.org/draft/2020-12/meta/core", + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/draft/next/meta/core", "$vocabulary": { - "https://json-schema.org/draft/2020-12/vocab/core": true + "https://json-schema.org/draft/next/vocab/core": true }, "$dynamicAnchor": "meta", diff --git a/meta/format-annotation.json b/meta/format-annotation.json index 51ef7ea1..562f78f8 100644 --- a/meta/format-annotation.json +++ b/meta/format-annotation.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://json-schema.org/draft/2020-12/meta/format-annotation", + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/draft/next/meta/format-annotation", "$vocabulary": { - "https://json-schema.org/draft/2020-12/vocab/format-annotation": true + "https://json-schema.org/draft/next/vocab/format-annotation": true }, "$dynamicAnchor": "meta", diff --git a/meta/format-assertion.json b/meta/format-assertion.json index 5e73fd75..d60ead96 100644 --- a/meta/format-assertion.json +++ b/meta/format-assertion.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://json-schema.org/draft/2020-12/meta/format-assertion", + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/draft/next/meta/format-assertion", "$vocabulary": { - "https://json-schema.org/draft/2020-12/vocab/format-assertion": true + "https://json-schema.org/draft/next/vocab/format-assertion": true }, "$dynamicAnchor": "meta", diff --git a/meta/meta-data.json b/meta/meta-data.json index 05cbc22a..345a6916 100644 --- a/meta/meta-data.json +++ b/meta/meta-data.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://json-schema.org/draft/2020-12/meta/meta-data", + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/draft/next/meta/meta-data", "$vocabulary": { - "https://json-schema.org/draft/2020-12/vocab/meta-data": true + "https://json-schema.org/draft/next/vocab/meta-data": true }, "$dynamicAnchor": "meta", diff --git a/meta/unevaluated.json b/meta/unevaluated.json index 5f62a3ff..58b411dd 100644 --- a/meta/unevaluated.json +++ b/meta/unevaluated.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://json-schema.org/draft/2020-12/meta/unevaluated", + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/draft/next/meta/unevaluated", "$vocabulary": { - "https://json-schema.org/draft/2020-12/vocab/unevaluated": true + "https://json-schema.org/draft/next/vocab/unevaluated": true }, "$dynamicAnchor": "meta", diff --git a/meta/validation.json b/meta/validation.json index 606b87ba..69d52e95 100644 --- a/meta/validation.json +++ b/meta/validation.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://json-schema.org/draft/2020-12/meta/validation", + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/draft/next/meta/validation", "$vocabulary": { - "https://json-schema.org/draft/2020-12/vocab/validation": true + "https://json-schema.org/draft/next/vocab/validation": true }, "$dynamicAnchor": "meta", diff --git a/output/schema.json b/output/schema.json index 1eef288a..72551fc6 100644 --- a/output/schema.json +++ b/output/schema.json @@ -1,6 +1,6 @@ { - "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://json-schema.org/draft/2020-12/output/schema", + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/draft/next/output/schema", "description": "A schema that validates the minimum requirements for validation output", "anyOf": [ diff --git a/schema.json b/schema.json index d5e2d31c..e7f5a2c7 100644 --- a/schema.json +++ b/schema.json @@ -1,14 +1,14 @@ { - "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://json-schema.org/draft/2020-12/schema", + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/draft/next/schema", "$vocabulary": { - "https://json-schema.org/draft/2020-12/vocab/core": true, - "https://json-schema.org/draft/2020-12/vocab/applicator": true, - "https://json-schema.org/draft/2020-12/vocab/unevaluated": true, - "https://json-schema.org/draft/2020-12/vocab/validation": true, - "https://json-schema.org/draft/2020-12/vocab/meta-data": true, - "https://json-schema.org/draft/2020-12/vocab/format-annotation": true, - "https://json-schema.org/draft/2020-12/vocab/content": true + "https://json-schema.org/draft/next/vocab/core": true, + "https://json-schema.org/draft/next/vocab/applicator": true, + "https://json-schema.org/draft/next/vocab/unevaluated": true, + "https://json-schema.org/draft/next/vocab/validation": true, + "https://json-schema.org/draft/next/vocab/meta-data": true, + "https://json-schema.org/draft/next/vocab/format-annotation": true, + "https://json-schema.org/draft/next/vocab/content": true }, "$dynamicAnchor": "meta", From fe2a46f8f62c4e869312577c7a240706c1194099 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers <jdesrosi@gmail.com> Date: Fri, 3 Dec 2021 12:27:00 -0800 Subject: [PATCH 343/780] Remove bookending requirement for dynamicRef (#1139) * Remove bookending requirement for dynamicRef * Add $dynamicRef changes to change log --- jsonschema-core.xml | 30 +++++++++++++----------------- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index abe8a48c..85cfcd84 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1510,27 +1510,22 @@ <t> Together with "$dynamicAnchor", "$dynamicRef" implements a cooperative extension mechanism that is primarily useful with recursive schemas - (schemas that reference themselves). Both the extension point and the - runtime-determined extension target are defined with "$dynamicAnchor", - and only exhibit runtime dynamic behavior when referenced with - "$dynamicRef". + (schemas that reference themselves). The extension point is defined with + "$dynamicAnchor" and only exhibits runtime dynamic behavior when referenced + with "$dynamicRef". </t> <t> - The value of the "$dynamicRef" property MUST be a string which is - a IRI-Reference. Resolved against the current IRI base, it produces - the IRI used as the starting point for runtime resolution. This initial - resolution is safe to perform on schema load. + The value of the "$dynamicRef" property MUST be a string which is a + IRI-Reference that contains a valid <xref target="anchor">plain name + fragment</xref>. Resolved against the current IRI base, it indicates + the schema resource used as the starting point for runtime resolution. + This initial resolution is safe to perform on schema load. </t> <t> - If the initially resolved starting point IRI includes a fragment that - was created by the "$dynamicAnchor" keyword, the initial IRI MUST be - replaced by the IRI (including the fragment) for the outermost schema - resource in the <xref target="scopes">dynamic scope</xref> that defines - an identically named fragment with "$dynamicAnchor". - </t> - <t> - Otherwise, its behavior is identical to "$ref", and no runtime - resolution is needed. + The schema to apply is the outermost schema resource in the + <xref target="scopes">dynamic scope</xref> that defines a + "$dynamicAnchor" that matches the plain name fragment in the initially + resolved IRI. </t> <t> For a full example using these keyword, see appendix @@ -3904,6 +3899,7 @@ https://example.com/schemas/common#/$defs/count/minimum <list style="symbols"> <t>"contains" now applies to objects as well as arrays</t> <t>Use IRIs instead of URIs</t> + <t>Remove bookending requirement for "$dynamicRef"</t> </list> </t> <t hangText="draft-bhutton-json-schema-01"> From 255c13b90473a4d73d8db946099a64303a81d903 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Mon, 20 Dec 2021 21:24:12 +0000 Subject: [PATCH 344/780] Add repo status --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 6567d2d0..506939e1 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ # Welcome to JSON Schema -[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg)](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md) [![Financial Contributors on Open Collective](https://opencollective.com/json-schema/all/badge.svg?label=financial+contributors)](https://opencollective.com/json-schema) +[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg)](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md) [![Project Status: Active – The project has reached a stable, usable state and is being actively developed.](https://www.repostatus.org/badges/latest/active.svg)](https://www.repostatus.org/#active) [![Financial Contributors on Open Collective](https://opencollective.com/json-schema/all/badge.svg?label=financial+contributors)](https://opencollective.com/json-schema) JSON Schema is a vocabulary that allows you to validate, annotate, and manipulate JSON documents. From 63fbd7bf561a6ef04a38fd63589a3d93d1c149ff Mon Sep 17 00:00:00 2001 From: Karen Etheridge <ether@cpan.org> Date: Thu, 6 Jan 2022 22:02:10 -0800 Subject: [PATCH 345/780] fix broken reference ..from #1137 --- schema.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/schema.json b/schema.json index e7f5a2c7..066d86b9 100644 --- a/schema.json +++ b/schema.json @@ -51,7 +51,8 @@ }, "$recursiveRef": { "$comment": "\"$recursiveRef\" has been replaced by \"$dynamicRef\".", - "$ref": "meta/core#/$defs/uriReferenceString", + "type": "string", + "format": "uri-reference", "deprecated": true } } From 43404805e136dac1f39c37569c67e9abbddd3a76 Mon Sep 17 00:00:00 2001 From: Juan Cruz Viotti <jv@jviotti.com> Date: Wed, 29 Dec 2021 18:33:16 -0400 Subject: [PATCH 346/780] Add README instructions on how to install xml2rfc Signed-off-by: Juan Cruz Viotti <jv@jviotti.com> --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 506939e1..5dd3478d 100644 --- a/README.md +++ b/README.md @@ -35,7 +35,7 @@ Labels are assigned based on [Sensible Github Labels](https://github.com/Releque * links.json - JSON Hyper-Schema's Link Description Object meta-schema * hyper-schema-output.json - The recommended output format for JSON Hyper-Schema links -Type "make" at a shell to build the .txt and .html spec files. +Install "xml2rfc" using "pip" (https://pypi.org/project/xml2rfc/) and type "make" at a shell to build the .txt and .html spec files. Descriptions of the xml2rfc, I-D documents, and RFC processes: From 0e40e2a2d01d84c1b235eb8195f211c908b72133 Mon Sep 17 00:00:00 2001 From: Juan Cruz Viotti <jv@jviotti.com> Date: Wed, 29 Dec 2021 18:22:58 -0400 Subject: [PATCH 347/780] Add the "all" target to the list of PHONY targets Looks like this one has been missed. Signed-off-by: Juan Cruz Viotti <jv@jviotti.com> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a85e82ce..b1dfa883 100644 --- a/Makefile +++ b/Makefile @@ -24,4 +24,4 @@ json-schema.tar.gz: $(OUT) clean: rm -f $(OUT) json-schema.tar.gz -.PHONY: clean +.PHONY: clean all From a350eaa6b68bf7e9cb07e500bbd7f7b7f209ed4f Mon Sep 17 00:00:00 2001 From: Juan Cruz Viotti <jv@jviotti.com> Date: Wed, 29 Dec 2021 18:16:00 -0400 Subject: [PATCH 348/780] Allow the XML2RFC GNU Make variable to be overridden by the caller It is a best practice to allow callers to override the value of these program variables. For example, with this chance, you can do: ```sh make XML2RFC=/opt/bin/xml2rfc ``` See: https://www.gnu.org/software/make/manual/make.html#Command-Variables Signed-off-by: Juan Cruz Viotti <jv@jviotti.com> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index b1dfa883..9607d187 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -XML2RFC=xml2rfc +XML2RFC ?= xml2rfc OUT = \ jsonschema-core.html jsonschema-core.txt \ From dca1d11fb9aab37ce0d8133c8509c05011a83fc6 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers <jdesrosi@gmail.com> Date: Thu, 21 Oct 2021 14:05:32 -0700 Subject: [PATCH 349/780] Add propertyDependencies keyword --- jsonschema-core.xml | 20 ++++++++++++++++++++ meta/applicator.json | 9 +++++++++ 2 files changed, 29 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 85cfcd84..a3b8e11f 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2300,6 +2300,25 @@ Omitting this keyword has the same behavior as an empty object. </t> </section> + <section title="propertyDependencies"> + <t> + This keyword specifies subschemas that are evaluated if the instance is + an object and contains a certain property with a certain string value. + </t> + <t> + This keyword's value MUST be an object. Each value in the object MUST be + an object whose values MUST be valid JSON Schemas. + </t> + <t> + If the outer object key is a property in the instance and the inner + object key is equal to the value of that property, the entire instance + must validate against the schema. Its use is dependent on the presence + and value of the property. + </t> + <t> + Omitting this keyword has the same behavior as an empty object. + </t> + </section> </section> </section> <section title="Keywords for Applying Subschemas to Child Instances"> @@ -3900,6 +3919,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t>"contains" now applies to objects as well as arrays</t> <t>Use IRIs instead of URIs</t> <t>Remove bookending requirement for "$dynamicRef"</t> + <t>Add "propertyDependencies" keyword</t> </list> </t> <t hangText="draft-bhutton-json-schema-01"> diff --git a/meta/applicator.json b/meta/applicator.json index 948f4193..1b2f8c2e 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -29,6 +29,15 @@ "additionalProperties": { "$dynamicRef": "#meta" }, "default": {} }, + "propertyDependencies": { + "type": "object", + "additionalProperties": { + "type": "object", + "additionalProperties": { "$dynamicRef": "#meta" }, + "default": {} + }, + "default": {} + }, "propertyNames": { "$dynamicRef": "#meta" }, "if": { "$dynamicRef": "#meta" }, "then": { "$dynamicRef": "#meta" }, From 9e38f049d93683d06c668c2a3ea12e6b5bb4b14b Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Wed, 22 Jun 2022 13:41:55 +1200 Subject: [PATCH 350/780] output - change property names in declarations --- jsonschema-core.xml | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index a3b8e11f..b95baf6c 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2759,9 +2759,10 @@ <section title="Keyword Relative Location"> <t> - The relative location of the validating keyword that follows the validation - path. The value MUST be expressed as a JSON Pointer, and it MUST include - any by-reference applicators such as "$ref" or "$dynamicRef". + The relative location of the validating keyword that follows the path + traversed through the schema. The value MUST be expressed as a JSON + Pointer, and it MUST include any by-reference applicators such as + "$ref" or "$dynamicRef". </t> <figure> <artwork> @@ -2775,7 +2776,7 @@ due to the inclusion of these by-reference applicator keywords. </t> <t> - The JSON key for this information is "keywordLocation". + The JSON key for this information is "evaluationPath". </t> </section> @@ -2807,7 +2808,7 @@ https://example.com/schemas/common#/$defs/count/minimum over a reference or if the schema does not declare an absolute IRI as its "$id". </t> <t> - The JSON key for this information is "absoluteKeywordLocation". + The JSON key for this information is "schemaLocation". </t> </section> @@ -2841,13 +2842,15 @@ https://example.com/schemas/common#/$defs/count/minimum <section title="Nested Results"> <t> - For the two hierarchical structures, this property will hold nested errors - and annotations. + For "basic", this property will appear only at the root node and will hold + all errors or annotations in a list. </t> <t> - The JSON key for nested results in failed validations is "errors"; for - successful validations it is "annotations". Note the plural forms, as - a keyword with nested results can also have a local error or annotation. + For "detailed" and "verbose", this property will hold nested errors + and annotations in a tree structure, mimicking that of the schema. + </t> + <t> + The JSON key for nested results is "nested". </t> </section> @@ -2857,19 +2860,14 @@ https://example.com/schemas/common#/$defs/count/minimum <t> The output MUST be an object containing a boolean property named "valid". When additional information about the result is required, the output MUST also contain - "errors" or "annotations" as described below. + "nested" as described below. <list> <t> "valid" - a boolean value indicating the overall validation success or failure </t> <t> - "errors" - the collection of errors or annotations produced by a failed - validation - </t> - <t> - "annotations" - the collection of errors or annotations produced by a - successful validation + "nested" - the collection of errors or annotations produced by a keyword </t> </list> For these examples, the following schema and instance will be used. From c46fa46e47e1fc548f17f1ff59e26644d171c75b Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Wed, 22 Jun 2022 13:48:50 +1200 Subject: [PATCH 351/780] output - apply new property names to output examples --- jsonschema-core.xml | 52 ++++++++++++------------- output/verbose-example.json | 76 ++++++++++++++++++------------------- 2 files changed, 64 insertions(+), 64 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b95baf6c..597f6026 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2963,35 +2963,35 @@ https://example.com/schemas/common#/$defs/count/minimum <![CDATA[ { "valid": false, - "errors": [ + "nested": [ { - "keywordLocation": "", + "evaluationPath": "", "instanceLocation": "", "error": "A subschema had errors." }, { - "keywordLocation": "/items/$ref", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref", + "schemaLocation": "https://example.com/polygon#/$defs/point", "instanceLocation": "/1", "error": "A subschema had errors." }, { - "keywordLocation": "/items/$ref/required", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/required", + "schemaLocation": "https://example.com/polygon#/$defs/point/required", "instanceLocation": "/1", "error": "Required property 'y' not found." }, { - "keywordLocation": "/items/$ref/additionalProperties", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/additionalProperties", + "schemaLocation": "https://example.com/polygon#/$defs/point/additionalProperties", "instanceLocation": "/1/z", "error": "Additional property 'z' found but was invalid." }, { - "keywordLocation": "/minItems", + "evaluationPath": "/minItems", "instanceLocation": "", "error": "Expected at least 3 items but found 2" } @@ -3032,28 +3032,28 @@ https://example.com/schemas/common#/$defs/count/minimum <![CDATA[ { "valid": false, - "keywordLocation": "", + "evaluationPath": "", "instanceLocation": "", - "errors": [ + "nested": [ { "valid": false, - "keywordLocation": "/items/$ref", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref", + "schemaLocation": "https://example.com/polygon#/$defs/point", "instanceLocation": "/1", - "errors": [ + "nested": [ { "valid": false, - "keywordLocation": "/items/$ref/required", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/required", + "schemaLocation": "https://example.com/polygon#/$defs/point/required", "instanceLocation": "/1", "error": "Required property 'y' not found." }, { "valid": false, - "keywordLocation": "/items/$ref/additionalProperties", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/additionalProperties", + "schemaLocation": "https://example.com/polygon#/$defs/point/additionalProperties", "instanceLocation": "/1/z", "error": "Additional property 'z' found but was invalid." @@ -3062,7 +3062,7 @@ https://example.com/schemas/common#/$defs/count/minimum }, { "valid": false, - "keywordLocation": "/minItems", + "evaluationPath": "/minItems", "instanceLocation": "", "error": "Expected at least 3 items but found 2" } @@ -3115,27 +3115,27 @@ https://example.com/schemas/common#/$defs/count/minimum // result { "valid": false, - "keywordLocation": "", + "evaluationPath": "", "instanceLocation": "", - "errors": [ + "nested": [ { "valid": true, - "keywordLocation": "/type", + "evaluationPath": "/type", "instanceLocation": "" }, { "valid": true, - "keywordLocation": "/properties", + "evaluationPath": "/properties", "instanceLocation": "" }, { "valid": false, - "keywordLocation": "/additionalProperties", + "evaluationPath": "/additionalProperties", "instanceLocation": "", - "errors": [ + "nested": [ { "valid": false, - "keywordLocation": "/additionalProperties", + "evaluationPath": "/additionalProperties", "instanceLocation": "/disallowedProp", "error": "Additional property 'disallowedProp' found but was invalid." } diff --git a/output/verbose-example.json b/output/verbose-example.json index 5e6fbb4a..d74c10ea 100644 --- a/output/verbose-example.json +++ b/output/verbose-example.json @@ -1,62 +1,62 @@ { "valid": false, - "keywordLocation": "", + "evaluationPath": "", "instanceLocation": "", - "errors": [ + "nested": [ { "valid": true, - "keywordLocation": "/$defs", + "evaluationPath": "/$defs", "instanceLocation": "" }, { "valid": true, - "keywordLocation": "/type", + "evaluationPath": "/type", "instanceLocation": "" }, { "valid": false, - "keywordLocation": "/items", + "evaluationPath": "/items", "instanceLocation": "", - "errors": [ + "nested": [ { "valid": true, - "keywordLocation": "/items/$ref", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref", + "schemaLocation": "https://example.com/polygon#/items/$ref", "instanceLocation": "/0", - "annotations": [ + "nested": [ { "valid": true, - "keywordLocation": "/items/$ref", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref", + "schemaLocation": "https://example.com/polygon#/$defs/point", "instanceLocation": "/0", - "annotations": [ + "nested": [ { "valid": true, - "keywordLocation": "/items/$ref/type", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/type", + "schemaLocation": "https://example.com/polygon#/$defs/point/type", "instanceLocation": "/0" }, { "valid": true, - "keywordLocation": "/items/$ref/properties", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/properties", + "schemaLocation": "https://example.com/polygon#/$defs/point/properties", "instanceLocation": "/0" }, { "valid": true, - "keywordLocation": "/items/$ref/required", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/required", + "schemaLocation": "https://example.com/polygon#/$defs/point/required", "instanceLocation": "/0" }, { "valid": true, - "keywordLocation": "/items/$ref/additionalProperties", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/additionalProperties", + "schemaLocation": "https://example.com/polygon#/$defs/point/additionalProperties", "instanceLocation": "/0" } @@ -66,50 +66,50 @@ }, { "valid": false, - "keywordLocation": "/items/$ref", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref", + "schemaLocation": "https://example.com/polygon#/items/$ref", "instanceLocation": "/1", - "errors": [ + "nested": [ { "valid": false, - "keywordLocation": "/items/$ref", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref", + "schemaLocation": "https://example.com/polygon#/$defs/point", "instanceLocation": "/1", - "errors": [ + "nested": [ { "valid": true, - "keywordLocation": "/items/$ref/type", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/type", + "schemaLocation": "https://example.com/polygon#/$defs/point/type", "instanceLocation": "/1" }, { "valid": true, - "keywordLocation": "/items/$ref/properties", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/properties", + "schemaLocation": "https://example.com/polygon#/$defs/point/properties", "instanceLocation": "/1" }, { "valid": false, - "keywordLocation": "/items/$ref/required", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/required", + "schemaLocation": "https://example.com/polygon#/$defs/point/required", "instanceLocation": "/1" }, { "valid": false, - "keywordLocation": "/items/$ref/additionalProperties", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/additionalProperties", + "schemaLocation": "https://example.com/polygon#/$defs/point/additionalProperties", "instanceLocation": "/1", - "errors": [ + "nested": [ { "valid": false, - "keywordLocation": "/items/$ref/additionalProperties", - "absoluteKeywordLocation": + "evaluationPath": "/items/$ref/additionalProperties", + "schemaLocation": "https://example.com/polygon#/$defs/point/additionalProperties", "instanceLocation": "/1/z" } @@ -123,7 +123,7 @@ }, { "valid": false, - "keywordLocation": "/minItems", + "evaluationPath": "/minItems", "instanceLocation": "" } ] From 559e2f785cbc3ad824b51deaecd0e478368caa43 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Mon, 27 Jun 2022 12:54:46 +1200 Subject: [PATCH 352/780] adds cref for further clarification on evaluation path in output node --- jsonschema-core.xml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 597f6026..f580d50c 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2760,9 +2760,14 @@ <section title="Keyword Relative Location"> <t> The relative location of the validating keyword that follows the path - traversed through the schema. The value MUST be expressed as a JSON + traversed through the schema. The value MUST be expressed as a JSON Pointer, and it MUST include any by-reference applicators such as "$ref" or "$dynamicRef". + <cref> + The schema may not actually have a value at the location indicated + by this pointer. It is provided as an indication of the traversal + path only. + </cref> </t> <figure> <artwork> From 38fccc053538593b76d53ea91ee66542ee64f8e6 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers <jdesrosi@gmail.com> Date: Fri, 8 Jul 2022 08:20:24 -0700 Subject: [PATCH 353/780] Update CONTRIBUTING.md with the new branching strategy --- CONTRIBUTING.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3e21ad31..942f71a8 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -22,7 +22,11 @@ If the pull request would solve a particular issue, reference the issue in the p Changes that would affect implementation behavior should typically be opened as an issue first. -Pull requests should be made to the default branch, which may be `draft-patch`, `draft-next`, or `master` depending on where we are in the [release process](https://github.com/json-schema-org/community/discussions/7). +Generally, pull requests should be made to the `main` branch unless it is a +patch update and we are in a patch phase of the +[release process](https://github.com/json-schema-org/community/discussions/7). +In that case there will be a branch named something like `2020-12-patch` that +the PR should target instead. Most PRs, including all PRs that impact implementation behavior, will be left open for a minimum of 14 days. Minor wording fixes may be merged more quickly once approved by a project member. From 00f22bc30e60d7bac61f41aa92f3021976cb58cf Mon Sep 17 00:00:00 2001 From: Austin Wright <aaa@bzfx.net> Date: Fri, 8 Jul 2022 12:50:18 -0700 Subject: [PATCH 354/780] Add PDF output generation to Makefile --- .gitignore | 2 ++ Makefile | 4 ++++ 2 files changed, 6 insertions(+) diff --git a/.gitignore b/.gitignore index 2e2169f7..83386b0d 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,6 @@ jsonschema-*.html +jsonschema-*.pdf jsonschema-*.txt relative-json-pointer.html +relative-json-pointer.pdf relative-json-pointer.txt diff --git a/Makefile b/Makefile index 9607d187..cb7008f7 100644 --- a/Makefile +++ b/Makefile @@ -11,10 +11,14 @@ all: $(OUT) %.txt: %.xml $(XML2RFC) --text $< -o $@ +%.pdf: %.xml + $(XML2RFC) --pdf $< -o $@ + %.html: %.xml $(XML2RFC) --html $< -o $@ json-schema.tar.gz: $(OUT) + test ! -e json-schema mkdir json-schema git clone . json-schema (cd json-schema && make) From 91fea475260db56b7ec6dfc08d2b7867c4114658 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers <jdesrosi@gmail.com> Date: Tue, 20 Apr 2021 11:08:30 -0700 Subject: [PATCH 355/780] Move contains to "other" applicator section --- jsonschema-core.xml | 1 - 1 file changed, 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f580d50c..7e810925 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2502,7 +2502,6 @@ </section> <section title="Other Keywords for Applying Subschemas"> - <section title="contains"> <t> The value of this keyword MUST be a valid JSON Schema. From a469d9b06d2d385235d2f1d3cc882babd3496e95 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Mon, 27 Jun 2022 14:06:18 +1200 Subject: [PATCH 356/780] updated output structure description, example schema and instances, and explanation of results --- jsonschema-core.xml | 204 +++++++++++++++++++++++++++++++------------- 1 file changed, 146 insertions(+), 58 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 7e810925..b6c61108 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2756,9 +2756,9 @@ Implementations MAY elect to provide additional information. </t> - <section title="Keyword Relative Location"> + <section title="Subschema Relative Location"> <t> - The relative location of the validating keyword that follows the path + The relative location of the validating subschema that follows the path traversed through the schema. The value MUST be expressed as a JSON Pointer, and it MUST include any by-reference applicators such as "$ref" or "$dynamicRef". @@ -2776,22 +2776,20 @@ </artwork> </figure> <t> - Note that this pointer may not be resolvable by the normal JSON Pointer process - due to the inclusion of these by-reference applicator keywords. + Note that this pointer may not be resolvable by the normal JSON Pointer process + due to the inclusion of these by-reference applicator keywords. </t> <t> The JSON key for this information is "evaluationPath". </t> </section> - <section title="Keyword Absolute Location"> + <section title="Subschema Absolute Location"> <t> - The absolute, dereferenced location of the validating keyword. The value MUST - be expressed as a full IRI using the canonical IRI of the relevant schema resource - with a JSON Pointer fragment, and it MUST NOT include by-reference applicators - such as "$ref" or "$dynamicRef" as non-terminal path components. - It MAY end in such keywords if the error or annotation is for that - keyword, such as an unresolvable reference. + The absolute, dereferenced location of the validating subschema. The value MUST + be expressed as a full IRI using the canonical IRI of the relevant + schema object, and it MUST NOT include by-reference applicators + such as "$ref" or "$dynamicRef" as path components. <cref> Note that "absolute" here is in the sense of "absolute filesystem path" (meaning the complete location) rather than the "absolute-IRI" @@ -2807,10 +2805,6 @@ https://example.com/schemas/common#/$defs/count/minimum ]]> </artwork> </figure> - <t> - This information MAY be omitted only if either the dynamic scope did not pass - over a reference or if the schema does not declare an absolute IRI as its "$id". - </t> <t> The JSON key for this information is "schemaLocation". </t> @@ -2826,32 +2820,48 @@ https://example.com/schemas/common#/$defs/count/minimum </t> </section> - <section title="Error or Annotation"> + <section title="Errors"> <t> - The error or annotation that is produced by the validation. + Any errors produced by the validation. This property MUST NOT + be included if the validation was successful. The value + for this property is an object where the keys are the names of + keywords and the values are the error message produced by the + associated keyword. </t> <t> - For errors, the specific wording for the message is not defined by this + The specific wording for the message is not defined by this specification. Implementations will need to provide this. </t> <t> - For annotations, each keyword that produces an annotation specifies its - format. By default, it is the keyword's value. + The JSON key for this information is "errors". + </t> + </section> + + <section title="Annotations"> + <t> + Any annotations produced by the validation. This property MUST NOT + be included if the validation was unsuccessful. The value + for this property is an object where the keys are the names of + keywords and the values are the annotations produced by the + associated keyword. + </t> + <t> + Each keyword defines its own annotation data type (e.g. "properties" + produces a list of keywords, whereas "$title" produces a string). </t> <t> - The JSON key for failed validations is "error"; for successful validations - it is "annotation". + The JSON key for this information is "annotations". </t> </section> <section title="Nested Results"> <t> For "basic", this property will appear only at the root node and will hold - all errors or annotations in a list. + all results in a flat list. </t> <t> - For "detailed" and "verbose", this property will hold nested errors - and annotations in a tree structure, mimicking that of the schema. + For "detailed" and "verbose", this property will hold nested results + in a tree structure, mimicking that of the schema. </t> <t> The JSON key for nested results is "nested". @@ -2871,67 +2881,145 @@ https://example.com/schemas/common#/$defs/count/minimum failure </t> <t> - "nested" - the collection of errors or annotations produced by a keyword + "nested" - the collection of errors or annotations produced by a subschema </t> </list> - For these examples, the following schema and instance will be used. + For these examples, the following schema and instances will be used. </t> <figure> <artwork> <![CDATA[ +// schema { - "$id": "https://example.com/polygon", "$schema": "https://json-schema.org/draft/next/schema", - "$defs": { - "point": { + "$id": "https://json-schema.org/schemas/example", + "type": "object", + "title": "root", + "properties": { + "foo": { "type": "object", + "title": "foo-title", "properties": { - "x": { "type": "number" }, - "y": { "type": "number" } - }, - "additionalProperties": false, - "required": [ "x", "y" ] + "foo-prop": { + "const": 1, + "title": "foo-prop-title" + } + } + }, + "bar": { + "$ref": "#/$defs/bar" } }, - "type": "array", - "items": { "$ref": "#/$defs/point" }, - "minItems": 3 + "$defs": { + "bar": { + "type": "object", + "title": "bar-title", + "properties": { + "bar-prop": { + "type": "integer", + "minimum": 10, + "title": "bar-prop-title" + } + } + } + } } -[ - { - "x": 2.5, - "y": 1.3 - }, - { - "x": 1, - "z": 6.7 - } -] +// failing instance +{ + "foo": {"foo-prop": "not 1"}, + "bar": {"bar-prop": 2} +} + +// passing instance +{ + "foo": {"foo-prop": 1}, + "bar": {"bar-prop": 20} +} ]]> </artwork> </figure> <t> - This instance will fail validation and produce errors, but it's trivial to deduce - examples for passing schemas that produce annotations. + The failing instance will produce the following errors: + <list> + <t> + The value at "/foo/foo-prop" + validated at "/properties/foo/properties/foo-prop" + by following the path "/properties/foo/properties/foo-prop" + by the "const" keyword + is not the constant value 1. + </t> + <t> + The value at "/bar/bar-prop" + validated at "/$defs/bar/properties/bar-prop" + by following the path "/properties/bar/$ref/properties/bar-prop" + by the "type" keyword + is not a number. + </t> + </list> + <cref> + "minimum" doesn't produce an error because it only operates on + instances that are numbers. + </cref> + <cref> + Note that the error message wording as depicted in the examples below is not a + requirement of this specification. Implementations SHOULD craft error messages + tailored for their audience or provide a templating mechanism that allows their + users to craft their own messages. + </cref> </t> <t> - Specifically, the errors it will produce are: + The passing instance will produce the following annotations: <list> <t> - The second object is missing a "y" property. + The keyword "title" + validated at "" + by following the path "" + will produce "root". + </t> + <t> + The keyword "properties" + validated at "" + by following the path "" + will produce "["foo", "bar"]". + </t> + <t> + The keyword "title" + validated at "/properties/foo" + by following the path "/properties/foo" + will produce "foo-title". + </t> + <t> + The keyword "properties" + validated at "/properties/foo" + by following the path "/properties/foo" + will produce "["foo-prop"]". + </t> + <t> + The keyword "title" + validated at "/properties/foo/properties/foo-prop" + by following the path "/properties/foo/properties/foo-prop" + will produce "foo-prop-title". + </t> + <t> + The keyword "title" + validated at "/$defs/bar" + by following the path "/properties/bar/$ref" + will produce "bar-title". </t> <t> - The second object has a disallowed "z" property. + The keyword "properties" + validated at "/$defs/bar" + by following the path "/properties/var/$ref" + will produce "["bar-prop"]". </t> <t> - There are only two objects, but three are required. + The keyword "title" + validated at "/$defs/bar/properties/bar-prop" + by following the path "/properties/bar/$ref/properties/bar-prop" + will produce "bar-prop-title". </t> </list> - Note that the error message wording as depicted in these examples is not a - requirement of this specification. Implementations SHOULD craft error messages - tailored for their audience or provide a templating mechanism that allows their - users to craft their own messages. </t> <section title="Flag"> From 8a73d7b90a87fc020d4e9fe9afa2e664e2800301 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Tue, 28 Jun 2022 00:23:37 +1200 Subject: [PATCH 357/780] update wording for structures and associated examples --- jsonschema-core.xml | 337 +++++++++++++++++++++--------------- output/verbose-example.json | 130 -------------- 2 files changed, 198 insertions(+), 269 deletions(-) delete mode 100644 output/verbose-example.json diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b6c61108..c413d439 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2826,7 +2826,8 @@ https://example.com/schemas/common#/$defs/count/minimum be included if the validation was successful. The value for this property is an object where the keys are the names of keywords and the values are the error message produced by the - associated keyword. + associated keyword. If the subschema itself is producing the + error, that error MUST be listed with an empty string key. </t> <t> The specific wording for the message is not defined by this @@ -2856,13 +2857,17 @@ https://example.com/schemas/common#/$defs/count/minimum <section title="Nested Results"> <t> - For "basic", this property will appear only at the root node and will hold - all results in a flat list. + For "basic", this property will appear only at the root output unit + and will hold all results in a flat list. </t> <t> For "detailed" and "verbose", this property will hold nested results in a tree structure, mimicking that of the schema. </t> + <t> + The sequence of output units within this list is not specified and + may be determined by the implementation. + </t> <t> The JSON key for nested results is "nested". </t> @@ -2897,14 +2902,20 @@ https://example.com/schemas/common#/$defs/count/minimum "title": "root", "properties": { "foo": { - "type": "object", - "title": "foo-title", - "properties": { - "foo-prop": { - "const": 1, - "title": "foo-prop-title" + "allOf": [ + { "required": [ "unspecified-prop" ] }, + { + "type": "object", + "title": "foo-title", + "properties": { + "foo-prop": { + "const": 1, + "title": "foo-prop-title" + } + }, + "additionalProperties": { "type": "boolean" } } - } + ] }, "bar": { "$ref": "#/$defs/bar" @@ -2927,13 +2938,16 @@ https://example.com/schemas/common#/$defs/count/minimum // failing instance { - "foo": {"foo-prop": "not 1"}, + "foo": {"foo-prop": "not 1", "other-prop": false}, "bar": {"bar-prop": 2} } // passing instance { - "foo": {"foo-prop": 1}, + "foo": { + "foo-prop": 1, + "unspecified-prop": true + }, "bar": {"bar-prop": 20} } ]]> @@ -2942,10 +2956,17 @@ https://example.com/schemas/common#/$defs/count/minimum <t> The failing instance will produce the following errors: <list> + <t> + The value at "/foo" + validated at "/properties/foo/allOf/0" + by following the path "/properties/foo/allOf/0" + by the "required" keyword + is missing the property "unspecified-prop". + </t> <t> The value at "/foo/foo-prop" - validated at "/properties/foo/properties/foo-prop" - by following the path "/properties/foo/properties/foo-prop" + validated at "/properties/foo/allOf/1/properties/foo-prop" + by following the path "/properties/foo/allOf/1/properties/foo-prop" by the "const" keyword is not the constant value 1. </t> @@ -2975,49 +2996,55 @@ https://example.com/schemas/common#/$defs/count/minimum The keyword "title" validated at "" by following the path "" - will produce "root". + will produce <sourcecode>"root"</sourcecode>. </t> <t> The keyword "properties" validated at "" by following the path "" - will produce "["foo", "bar"]". + will produce <sourcecode>["foo", "bar"]</sourcecode>. </t> <t> The keyword "title" validated at "/properties/foo" by following the path "/properties/foo" - will produce "foo-title". + will produce <sourcecode>"foo-title"</sourcecode>. </t> <t> The keyword "properties" - validated at "/properties/foo" - by following the path "/properties/foo" - will produce "["foo-prop"]". + validated at "/properties/foo/allOf/1" + by following the path "/properties/foo/allOf/1" + will produce <sourcecode>["foo-prop"]</sourcecode>. </t> <t> The keyword "title" - validated at "/properties/foo/properties/foo-prop" - by following the path "/properties/foo/properties/foo-prop" - will produce "foo-prop-title". + validated at "/properties/foo/allOf/1/properties/foo-prop" + by following the path "/properties/foo/allOf/1/properties/foo-prop" + will produce <sourcecode>"foo-prop-title"</sourcecode>. + </t> + <t> + The keyword "additionalProperties" + validated at "/properties/foo/allOf/1" + by following the path "/properties/foo/allOf/1" + will produce <sourcecode>["unspecified-prop"]</sourcecode>. </t> <t> The keyword "title" validated at "/$defs/bar" by following the path "/properties/bar/$ref" - will produce "bar-title". + will produce <sourcecode>"bar-title"</sourcecode>. </t> <t> The keyword "properties" validated at "/$defs/bar" by following the path "/properties/var/$ref" - will produce "["bar-prop"]". + will produce <sourcecode>["bar-prop"]</sourcecode>. </t> <t> The keyword "title" validated at "/$defs/bar/properties/bar-prop" by following the path "/properties/bar/$ref/properties/bar-prop" - will produce "bar-prop-title". + will produce <sourcecode>"bar-prop-title"</sourcecode>. </t> </list> </t> @@ -3025,7 +3052,8 @@ https://example.com/schemas/common#/$defs/count/minimum <section title="Flag"> <t> In the simplest case, merely the boolean result for the "valid" valid property - needs to be fulfilled. + needs to be fulfilled. For this format, all other information is explicitly + omitted. </t> <figure> <artwork> @@ -3040,7 +3068,7 @@ https://example.com/schemas/common#/$defs/count/minimum Because no errors or annotations are returned with this format, it is RECOMMENDED that implementations use short-circuiting logic to return failure or success as soon as the outcome can be determined. For example, - if an "anyOf" keyword contains five sub-schemas, and the second one + if an "anyOf" keyword contains five subschemas, and the second one passes, there is no need to check the other three. The logic can simply return with success. </t> @@ -3048,44 +3076,52 @@ https://example.com/schemas/common#/$defs/count/minimum <section title="Basic"> <t> - The "Basic" structure is a flat list of output units. + The "Basic" structure is a flat list of output units contained within a + root output unit. + </t> + <t> + The root output unit contains "valid" for the overall result and "nested" + for the list of specific results. All other information is explicitly + omitted from the root output unit. + </t> + <t> + Intermediate output units, which do not themselves produce errors but + represent subschemas that contain error-producing subschemas, MAY be + included. </t> <figure> <artwork> <![CDATA[ +// failing results { "valid": false, "nested": [ { - "evaluationPath": "", - "instanceLocation": "", - "error": "A subschema had errors." - }, - { - "evaluationPath": "/items/$ref", + "evaluationPath": "/properties/foo/allOf/0", "schemaLocation": - "https://example.com/polygon#/$defs/point", - "instanceLocation": "/1", - "error": "A subschema had errors." + "https://json-schema.org/schemas/example#/properties/foo/allOf/0", + "instanceLocation": "/foo", + "errors": { + "type": "Expected the property \"unspecified-prop\"." + } }, { - "evaluationPath": "/items/$ref/required", + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", "schemaLocation": - "https://example.com/polygon#/$defs/point/required", - "instanceLocation": "/1", - "error": "Required property 'y' not found." + "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "errors": { + "type": "Expected the value \"1\"." + } }, { - "evaluationPath": "/items/$ref/additionalProperties", + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", "schemaLocation": - "https://example.com/polygon#/$defs/point/additionalProperties", - "instanceLocation": "/1/z", - "error": "Additional property 'z' found but was invalid." - }, - { - "evaluationPath": "/minItems", - "instanceLocation": "", - "error": "Expected at least 3 items but found 2" + "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "errors": { + "type": "Expected a value of type \"integer\"." + } } ] } @@ -3096,67 +3132,72 @@ https://example.com/schemas/common#/$defs/count/minimum <section title="Detailed"> <t> - The "Detailed" structure is based on the schema and can be more readable - for both humans and machines. Having the structure organized this way makes - associations between the errors more apparent. For example, the fact that - the missing "y" property and the extra "z" property both stem from the same - location in the instance is not immediately obvious in the "Basic" structure. - In a hierarchy, the correlation is more easily identified. + The "Detailed" format is a hierarchical structure based on that of the schema + and can be more readable for both humans and machines by grouping together + output units that apply to the same subschemas. + </t> + <t> + The root output unit contains "valid" for the overall result and "nested" + for the list of specific results. All other information is explicitly + omitted from the root output unit. </t> <t> The following rules govern the construction of the results object: <list> <t> All applicator keywords ("*Of", "$ref", "if"/"then"/"else", etc.) require - a node. + a output unit. </t> <t> - Nodes that have no children are removed. + Output units that have no children are removed. </t> <t> - Nodes that have a single child are replaced by the child. + Output units that have a single child are replaced by the child. </t> </list> - Branch nodes do not require an error message or an annotation. + Branch output units do not require an error message or an annotation. </t> <figure> <artwork> <![CDATA[ +// failing results { "valid": false, - "evaluationPath": "", - "instanceLocation": "", "nested": [ { - "valid": false, - "evaluationPath": "/items/$ref", + "evaluationPath": "/properties/foo", "schemaLocation": - "https://example.com/polygon#/$defs/point", - "instanceLocation": "/1", + "https://json-schema.org/schemas/example#/properties/foo", + "instanceLocation": "/foo", "nested": [ { - "valid": false, - "evaluationPath": "/items/$ref/required", + "evaluationPath": "/properties/foo/allOf/0", "schemaLocation": - "https://example.com/polygon#/$defs/point/required", - "instanceLocation": "/1", - "error": "Required property 'y' not found." + "https://json-schema.org/schemas/example#/properties/foo/allOf/0", + "instanceLocation": "/foo", + "errors": { + "type": "Expected the property \"unspecified-prop\"." + } }, { - "valid": false, - "evaluationPath": "/items/$ref/additionalProperties", + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", "schemaLocation": - "https://example.com/polygon#/$defs/point/additionalProperties", - "instanceLocation": "/1/z", - "error": "Additional property 'z' found but was invalid." + "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "errors": { + "type": "Expected the value \"1\"." + } } ] }, { - "valid": false, - "evaluationPath": "/minItems", - "instanceLocation": "", - "error": "Expected at least 3 items but found 2" + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", + "schemaLocation": + "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "errors": { + "type": "Expected a value of type \"integer\"." + } } ] } @@ -3173,69 +3214,87 @@ https://example.com/schemas/common#/$defs/count/minimum </t> <t> The primary difference between this and the "Detailed" structure is that - all results are returned. This includes sub-schema validation results that - would otherwise be removed (e.g. annotations for failed validations, - successful validations inside a `not` keyword, etc.). Because of this, it - is RECOMMENDED that each node also carry a `valid` property to indicate the - validation result for that node. - </t> - <t> - Because this output structure can be quite large, a smaller example is given - here for brevity. The IRI of the full output structure of the example above is: - <eref target="https://json-schema.org/draft/next/output/verbose-example"/>. + all results are returned. This includes subschema validation results that + would otherwise be removed (e.g. passing subschemas contained within failing + subschemas, etc.). Because of this, each output unit MUST also carry a + "valid" property to indicate its local validation result. </t> <figure> <artwork> <![CDATA[ -// schema -{ - "$id": "https://example.com/polygon", - "$schema": "https://json-schema.org/draft/next/schema", - "type": "object", - "properties": { - "validProp": true, - }, - "additionalProperties": false -} - -// instance +// failing results { - "validProp": 5, - "disallowedProp": "value" -} - -// result -{ - "valid": false, - "evaluationPath": "", - "instanceLocation": "", - "nested": [ - { - "valid": true, - "evaluationPath": "/type", - "instanceLocation": "" - }, - { - "valid": true, - "evaluationPath": "/properties", - "instanceLocation": "" - }, - { - "valid": false, - "evaluationPath": "/additionalProperties", - "instanceLocation": "", - "nested": [ - { - "valid": false, - "evaluationPath": "/additionalProperties", - "instanceLocation": "/disallowedProp", - "error": "Additional property 'disallowedProp' found but was invalid." - } - ] - } - ] -} -]]> + "valid": false, + "nested": [ + { + "valid": false, + "evaluationPath": "/properties/foo", + "schemaLocation": + "https://json-schema.org/schemas/example#/properties/foo", + "instanceLocation": "/foo", + "nested": [ + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/0", + "schemaLocation": + "https://json-schema.org/schemas/example#/properties/foo/allOf/0", + "instanceLocation": "/foo", + "errors": { + "required": "Expected the property \"unspecified-prop\"." + } + }, + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/1", + "schemaLocation": + "https://json-schema.org/schemas/example#/properties/foo/allOf/1", + "instanceLocation": "/foo/foo-prop", + "nested": [ + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": + "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "errors": { + "const": "Expected the value \"1\"." + } + } + ] + } + ] + }, + { + "valid": false, + "evaluationPath": "/properties/bar", + "schemaLocation": + "https://json-schema.org/schemas/example#/properties/bar", + "instanceLocation": "/bar", + "nested": [ + { + "valid": false, + "evaluationPath": "/properties/bar/$ref", + "schemaLocation": + "https://json-schema.org/schemas/example#/$defs/bar", + "instanceLocation": "/bar", + "nested": [ + { + "valid": false, + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", + "schemaLocation": + "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "errors": { + "type": "Expected a value of type \"integer\"." + } + } + ] + } + ] + } + ] + } + ]]> </artwork> </figure> </section> diff --git a/output/verbose-example.json b/output/verbose-example.json deleted file mode 100644 index d74c10ea..00000000 --- a/output/verbose-example.json +++ /dev/null @@ -1,130 +0,0 @@ -{ - "valid": false, - "evaluationPath": "", - "instanceLocation": "", - "nested": [ - { - "valid": true, - "evaluationPath": "/$defs", - "instanceLocation": "" - }, - { - "valid": true, - "evaluationPath": "/type", - "instanceLocation": "" - }, - { - "valid": false, - "evaluationPath": "/items", - "instanceLocation": "", - "nested": [ - { - "valid": true, - "evaluationPath": "/items/$ref", - "schemaLocation": - "https://example.com/polygon#/items/$ref", - "instanceLocation": "/0", - "nested": [ - { - "valid": true, - "evaluationPath": "/items/$ref", - "schemaLocation": - "https://example.com/polygon#/$defs/point", - "instanceLocation": "/0", - "nested": [ - { - "valid": true, - "evaluationPath": "/items/$ref/type", - "schemaLocation": - "https://example.com/polygon#/$defs/point/type", - "instanceLocation": "/0" - }, - { - "valid": true, - "evaluationPath": "/items/$ref/properties", - "schemaLocation": - "https://example.com/polygon#/$defs/point/properties", - "instanceLocation": "/0" - }, - { - "valid": true, - "evaluationPath": "/items/$ref/required", - "schemaLocation": - "https://example.com/polygon#/$defs/point/required", - "instanceLocation": "/0" - }, - { - "valid": true, - "evaluationPath": "/items/$ref/additionalProperties", - "schemaLocation": - "https://example.com/polygon#/$defs/point/additionalProperties", - "instanceLocation": "/0" - } - ] - } - ] - }, - { - "valid": false, - "evaluationPath": "/items/$ref", - "schemaLocation": - "https://example.com/polygon#/items/$ref", - "instanceLocation": "/1", - "nested": [ - { - "valid": false, - "evaluationPath": "/items/$ref", - "schemaLocation": - "https://example.com/polygon#/$defs/point", - "instanceLocation": "/1", - "nested": [ - { - "valid": true, - "evaluationPath": "/items/$ref/type", - "schemaLocation": - "https://example.com/polygon#/$defs/point/type", - "instanceLocation": "/1" - }, - { - "valid": true, - "evaluationPath": "/items/$ref/properties", - "schemaLocation": - "https://example.com/polygon#/$defs/point/properties", - "instanceLocation": "/1" - }, - { - "valid": false, - "evaluationPath": "/items/$ref/required", - "schemaLocation": - "https://example.com/polygon#/$defs/point/required", - "instanceLocation": "/1" - }, - { - "valid": false, - "evaluationPath": "/items/$ref/additionalProperties", - "schemaLocation": - "https://example.com/polygon#/$defs/point/additionalProperties", - "instanceLocation": "/1", - "nested": [ - { - "valid": false, - "evaluationPath": "/items/$ref/additionalProperties", - "schemaLocation": - "https://example.com/polygon#/$defs/point/additionalProperties", - "instanceLocation": "/1/z" - } - ] - } - ] - } - ] - } - ] - }, - { - "valid": false, - "evaluationPath": "/minItems", - "instanceLocation": "" - } - ] -} From b4ff06ecb0a8f2dc02ca165d9a23086357802639 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Tue, 28 Jun 2022 11:36:10 +1200 Subject: [PATCH 358/780] removed 'detailed' format; added annotations examples; some rewording and clarifications --- jsonschema-core.xml | 273 +++++++++++++++++++++++++++++--------------- 1 file changed, 180 insertions(+), 93 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index c413d439..4cabedd3 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2726,18 +2726,18 @@ Basic - Provides validation information in a flat list structure. </t> <t> - Detailed - Provides validation information in a condensed hierarchical - structure based on the structure of the schema. - </t> - <t> - Verbose - Provides validation information in an uncondensed hierarchical - structure that matches the exact structure of the schema. + Hierarchical - Provides validation information in a hierarchical + structure that mimics the structure of the schema. + <cref> + To be precise, this structure follows the paths that a validator + would traverse while processing the schema, including composition + via by-reference keywords. + </cref> </t> </list> - An implementation SHOULD provide at least one of the "flag", "basic", or "detailed" - format and MAY provide the "verbose" format. If it provides one or more of the - "detailed" or "verbose" formats, it MUST also provide the "flag" format. - Implementations SHOULD specify in their documentation which formats they support. + An implementation MUST provide the "flag" format and SHOULD provide at least one + of the "basic" or "hierarchical" formats. Implementations SHOULD specify in + their documentation which formats they support. </t> </section> @@ -2824,7 +2824,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t> Any errors produced by the validation. This property MUST NOT be included if the validation was successful. The value - for this property is an object where the keys are the names of + for this property MUST be an object where the keys are the names of keywords and the values are the error message produced by the associated keyword. If the subschema itself is producing the error, that error MUST be listed with an empty string key. @@ -2842,7 +2842,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t> Any annotations produced by the validation. This property MUST NOT be included if the validation was unsuccessful. The value - for this property is an object where the keys are the names of + for this property MUST be an object where the keys are the names of keywords and the values are the annotations produced by the associated keyword. </t> @@ -2856,13 +2856,20 @@ https://example.com/schemas/common#/$defs/count/minimum </section> <section title="Nested Results"> + <t> + Nested results are generated from applicator keywords: keywords with + subschemas or collections of subschemas as values. Keywords which + have arrays of subschemas (e.g. "anyOf") will generally generate an output + unit for each subschema. In order to accommodate potentially multiple + results, the value of this property MUST be an array of output units. + </t> <t> For "basic", this property will appear only at the root output unit - and will hold all results in a flat list. + and will hold all output units in a flat list. </t> <t> - For "detailed" and "verbose", this property will hold nested results - in a tree structure, mimicking that of the schema. + For "hierarchical", this property will hold nested results in a tree + structure, mimicking that of the schema. </t> <t> The sequence of output units within this list is not specified and @@ -3016,18 +3023,18 @@ https://example.com/schemas/common#/$defs/count/minimum by following the path "/properties/foo/allOf/1" will produce <sourcecode>["foo-prop"]</sourcecode>. </t> - <t> - The keyword "title" - validated at "/properties/foo/allOf/1/properties/foo-prop" - by following the path "/properties/foo/allOf/1/properties/foo-prop" - will produce <sourcecode>"foo-prop-title"</sourcecode>. - </t> <t> The keyword "additionalProperties" validated at "/properties/foo/allOf/1" by following the path "/properties/foo/allOf/1" will produce <sourcecode>["unspecified-prop"]</sourcecode>. </t> + <t> + The keyword "title" + validated at "/properties/foo/allOf/1/properties/foo-prop" + by following the path "/properties/foo/allOf/1/properties/foo-prop" + will produce <sourcecode>"foo-prop-title"</sourcecode>. + </t> <t> The keyword "title" validated at "/$defs/bar" @@ -3085,9 +3092,9 @@ https://example.com/schemas/common#/$defs/count/minimum omitted from the root output unit. </t> <t> - Intermediate output units, which do not themselves produce errors but - represent subschemas that contain error-producing subschemas, MAY be - included. + Output units which do not contain errors or annotations SHOULD be excluded + from this format, however implementations MAY choose to include them for + completeness. </t> <figure> <artwork> @@ -3125,78 +3132,72 @@ https://example.com/schemas/common#/$defs/count/minimum } ] } -]]> - </artwork> - </figure> - </section> - <section title="Detailed"> - <t> - The "Detailed" format is a hierarchical structure based on that of the schema - and can be more readable for both humans and machines by grouping together - output units that apply to the same subschemas. - </t> - <t> - The root output unit contains "valid" for the overall result and "nested" - for the list of specific results. All other information is explicitly - omitted from the root output unit. - </t> - <t> - The following rules govern the construction of the results object: - <list> - <t> - All applicator keywords ("*Of", "$ref", "if"/"then"/"else", etc.) require - a output unit. - </t> - <t> - Output units that have no children are removed. - </t> - <t> - Output units that have a single child are replaced by the child. - </t> - </list> - Branch output units do not require an error message or an annotation. - </t> - <figure> - <artwork> -<![CDATA[ -// failing results +// passing results { - "valid": false, + "valid": true, "nested": [ { + "valid": true, + "evaluationPath": "", + "schemaLocation": + "https://json-schema.org/schemas/example#", + "instanceLocation": "", + "annotations": { + "title": "root", + "properties": [ "foo", "bar" ] + } + }, + { + "valid": true, "evaluationPath": "/properties/foo", "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo", "instanceLocation": "/foo", - "nested": [ - { - "evaluationPath": "/properties/foo/allOf/0", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo/allOf/0", - "instanceLocation": "/foo", - "errors": { - "type": "Expected the property \"unspecified-prop\"." - } - }, - { - "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", - "instanceLocation": "/foo/foo-prop", - "errors": { - "type": "Expected the value \"1\"." - } - } - ] + "annotations": { + "title": "foo-title" + } + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1", + "schemaLocation": + "https://json-schema.org/schemas/example#/properties/foo/allOf/1", + "instanceLocation": "/foo/foo-prop", + "annotations": { + "properties": [ "foo-prop" ], + "additionalProperties": [ "unspecified-prop" ] + } + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": + "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "annotations": { + "title": "foo-prop-title" + } }, { + "valid": true, + "evaluationPath": "/properties/bar/$ref", + "schemaLocation": + "https://json-schema.org/schemas/example#/$defs/bar", + "instanceLocation": "/bar", + "annotations": { + "title": "bar-title", + "properties": [ "bar-prop" ] + } + }, + { + "valid": true, "evaluationPath": "/properties/bar/$ref/properties/bar-prop", "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", "instanceLocation": "/bar/bar-prop", - "errors": { - "type": "Expected a value of type \"integer\"." + "annotations": { + "title": "bar-prop-title" } } ] @@ -3206,23 +3207,24 @@ https://example.com/schemas/common#/$defs/count/minimum </figure> </section> - <section title="Verbose"> + <section title="Hierarchical"> + <t> + The "Hierarchical" structure is a tree structure that follows the + evaluation path during the validation process. Typically, it will + resemble the schema as if all referenced schemas were bundled in place + of their associated by-reference keywords. + </t> <t> - The "Verbose" structure is a fully realized hierarchy that exactly matches - that of the schema. This structure has applications in form generation and - validation where the error's location is important. + All output units are included in this format. </t> <t> - The primary difference between this and the "Detailed" structure is that - all results are returned. This includes subschema validation results that - would otherwise be removed (e.g. passing subschemas contained within failing - subschemas, etc.). Because of this, each output unit MUST also carry a - "valid" property to indicate its local validation result. + The location properties of the output unit MAY be omitted from the + root node. </t> <figure> <artwork> <![CDATA[ -// failing results +// failing results (errors) { "valid": false, "nested": [ @@ -3294,7 +3296,92 @@ https://example.com/schemas/common#/$defs/count/minimum } ] } - ]]> + + // passing results (annotations) + { + "valid": true, + "annotations": { + "title": "root", + "properties": [ "foo", "bar" ] + }, + "nested": [ + { + "valid": true, + "evaluationPath": "/properties/foo", + "schemaLocation": + "https://json-schema.org/schemas/example#/properties/foo", + "instanceLocation": "/foo", + "annotations": { + "title": "foo-title" + }, + "nested": [ + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/0", + "schemaLocation": + "https://json-schema.org/schemas/example#/properties/foo/allOf/0", + "instanceLocation": "/foo" + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1", + "schemaLocation": + "https://json-schema.org/schemas/example#/properties/foo/allOf/1", + "instanceLocation": "/foo/foo-prop", + "annotations": { + "properties": [ "foo-prop" ], + "additionalProperties": [ "unspecified-prop" ] + }, + "nested": [ + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": + "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "annotations": { + "title": "foo-prop-title" + } + } + ] + } + ] + }, + { + "valid": true, + "evaluationPath": "/properties/bar", + "schemaLocation": + "https://json-schema.org/schemas/example#/properties/bar", + "instanceLocation": "/bar", + "nested": [ + { + "valid": true, + "evaluationPath": "/properties/bar/$ref", + "schemaLocation": + "https://json-schema.org/schemas/example#/$defs/bar", + "instanceLocation": "/bar", + "annotations": { + "title": "bar-title", + "properties": [ "bar-prop" ] + }, + "nested": [ + { + "valid": true, + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", + "schemaLocation": + "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "annotations": { + "title": "bar-prop-title" + } + } + ] + } + ] + } + ] +} +]]> </artwork> </figure> </section> From 997bed9b09a918f28dd023d1c16fa14ceadb2a49 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Wed, 29 Jun 2022 12:05:13 +1200 Subject: [PATCH 359/780] updated description of nested results --- jsonschema-core.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 4cabedd3..3dbfe5e4 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2869,11 +2869,12 @@ https://example.com/schemas/common#/$defs/count/minimum </t> <t> For "hierarchical", this property will hold nested results in a tree - structure, mimicking that of the schema. + structure where each output unit may itself have nested results. </t> <t> The sequence of output units within this list is not specified and - may be determined by the implementation. + MAY be determined by the implementation. Sets of output units are + considered equivalent if they contain the same units, in any order. </t> <t> The JSON key for nested results is "nested". From e1344ccff5a4de22fa17f40675600a674c18ba29 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Thu, 30 Jun 2022 18:28:37 +1200 Subject: [PATCH 360/780] use actual generated output for the examples --- jsonschema-core.xml | 282 +++++++++++++++++++++++--------------------- 1 file changed, 147 insertions(+), 135 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 3dbfe5e4..51182184 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3103,32 +3103,35 @@ https://example.com/schemas/common#/$defs/count/minimum // failing results { "valid": false, + "evaluationPath": "", + "schemaLocation": "https://json-schema.org/schemas/example#", + "instanceLocation": "", "nested": [ { - "evaluationPath": "/properties/foo/allOf/0", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo/allOf/0", + "valid": false, + "evaluationPath": "/properties/foo/0", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/0", "instanceLocation": "/foo", "errors": { - "type": "Expected the property \"unspecified-prop\"." + "required": "Required properties [\"unspecified-prop\"] were not present" } }, { - "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "valid": false, + "evaluationPath": "/properties/foo/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1/properties/foo-prop", "instanceLocation": "/foo/foo-prop", "errors": { - "type": "Expected the value \"1\"." + "const": "Expected \"1\"" } }, { + "valid": false, "evaluationPath": "/properties/bar/$ref/properties/bar-prop", - "schemaLocation": - "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", "instanceLocation": "/bar/bar-prop", "errors": { - "type": "Expected a value of type \"integer\"." + "minimum": "2 is less than or equal to 10" } } ] @@ -3137,65 +3140,63 @@ https://example.com/schemas/common#/$defs/count/minimum // passing results { "valid": true, + "evaluationPath": "", + "schemaLocation": "https://json-schema.org/schemas/example#", + "instanceLocation": "", "nested": [ { "valid": true, "evaluationPath": "", - "schemaLocation": - "https://json-schema.org/schemas/example#", + "schemaLocation": "https://json-schema.org/schemas/example#", "instanceLocation": "", "annotations": { "title": "root", - "properties": [ "foo", "bar" ] + "properties": [ + "foo", + "bar" + ] } }, { "valid": true, - "evaluationPath": "/properties/foo", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo", + "evaluationPath": "/properties/foo/1", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1", "instanceLocation": "/foo", "annotations": { - "title": "foo-title" + "title": "foo-title", + "properties": [ + "foo-prop" + ], + "additionalProperties": [ + "unspecified-prop" + ] } }, { "valid": true, - "evaluationPath": "/properties/foo/allOf/1", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo/allOf/1", - "instanceLocation": "/foo/foo-prop", + "evaluationPath": "/properties/bar/$ref", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar", + "instanceLocation": "/bar", "annotations": { - "properties": [ "foo-prop" ], - "additionalProperties": [ "unspecified-prop" ] + "title": "bar-title", + "properties": [ + "bar-prop" + ] } }, { "valid": true, - "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "evaluationPath": "/properties/foo/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1/properties/foo-prop", "instanceLocation": "/foo/foo-prop", "annotations": { "title": "foo-prop-title" } }, - { - "valid": true, - "evaluationPath": "/properties/bar/$ref", - "schemaLocation": - "https://json-schema.org/schemas/example#/$defs/bar", - "instanceLocation": "/bar", - "annotations": { - "title": "bar-title", - "properties": [ "bar-prop" ] - } - }, { "valid": true, "evaluationPath": "/properties/bar/$ref/properties/bar-prop", - "schemaLocation": - "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", "instanceLocation": "/bar/bar-prop", "annotations": { "title": "bar-prop-title" @@ -3227,122 +3228,134 @@ https://example.com/schemas/common#/$defs/count/minimum <![CDATA[ // failing results (errors) { - "valid": false, - "nested": [ - { - "valid": false, - "evaluationPath": "/properties/foo", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo", - "instanceLocation": "/foo", - "nested": [ - { - "valid": false, - "evaluationPath": "/properties/foo/allOf/0", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo/allOf/0", - "instanceLocation": "/foo", - "errors": { - "required": "Expected the property \"unspecified-prop\"." - } - }, - { - "valid": false, - "evaluationPath": "/properties/foo/allOf/1", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo/allOf/1", - "instanceLocation": "/foo/foo-prop", - "nested": [ - { - "valid": false, - "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", - "instanceLocation": "/foo/foo-prop", - "errors": { - "const": "Expected the value \"1\"." - } - } - ] + "valid": false, + "evaluationPath": "", + "schemaLocation": "https://json-schema.org/schemas/example#", + "instanceLocation": "", + "nested": [ + { + "valid": false, + "evaluationPath": "/properties/foo", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo", + "instanceLocation": "/foo", + "nested": [ + { + "valid": false, + "evaluationPath": "/properties/foo/0", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/0", + "instanceLocation": "/foo", + "errors": { + "required": "Required properties [\"unspecified-prop\"] were not present" } - ] - }, - { - "valid": false, - "evaluationPath": "/properties/bar", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/bar", - "instanceLocation": "/bar", - "nested": [ - { - "valid": false, - "evaluationPath": "/properties/bar/$ref", - "schemaLocation": - "https://json-schema.org/schemas/example#/$defs/bar", - "instanceLocation": "/bar", - "nested": [ - { - "valid": false, - "evaluationPath": "/properties/bar/$ref/properties/bar-prop", - "schemaLocation": - "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", - "instanceLocation": "/bar/bar-prop", - "errors": { - "type": "Expected a value of type \"integer\"." - } + }, + { + "valid": false, + "evaluationPath": "/properties/foo/1", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1", + "instanceLocation": "/foo", + "nested": [ + { + "valid": false, + "evaluationPath": "/properties/foo/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "errors": { + "const": "Expected \"1\"" } - ] - } - ] - } - ] - } + }, + { + "valid": true, + "evaluationPath": "/properties/foo/1/additionalProperties/other-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1/additionalProperties/other-prop", + "instanceLocation": "/foo/other-prop" + } + ] + } + ] + }, + { + "valid": false, + "evaluationPath": "/properties/bar", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/bar", + "instanceLocation": "/bar", + "nested": [ + { + "valid": false, + "evaluationPath": "/properties/bar/$ref", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar", + "instanceLocation": "/bar", + "nested": [ + { + "valid": false, + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "errors": { + "minimum": "2 is less than or equal to 10" + } + } + ] + } + ] + } + ] +} - // passing results (annotations) - { +// passing results (annotations) +{ "valid": true, + "evaluationPath": "", + "schemaLocation": "https://json-schema.org/schemas/example#", + "instanceLocation": "", "annotations": { "title": "root", - "properties": [ "foo", "bar" ] + "properties": [ + "foo", + "bar" + ] }, "nested": [ { "valid": true, "evaluationPath": "/properties/foo", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo", "instanceLocation": "/foo", - "annotations": { - "title": "foo-title" - }, "nested": [ { "valid": true, - "evaluationPath": "/properties/foo/allOf/0", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo/allOf/0", + "evaluationPath": "/properties/foo/0", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/0", "instanceLocation": "/foo" }, { "valid": true, - "evaluationPath": "/properties/foo/allOf/1", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo/allOf/1", - "instanceLocation": "/foo/foo-prop", + "evaluationPath": "/properties/foo/1", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1", + "instanceLocation": "/foo", "annotations": { - "properties": [ "foo-prop" ], - "additionalProperties": [ "unspecified-prop" ] + "title": "foo-title", + "properties": [ + "foo-prop" + ], + "additionalProperties": [ + "unspecified-prop" + ] }, "nested": [ { "valid": true, - "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "evaluationPath": "/properties/foo/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1/properties/foo-prop", "instanceLocation": "/foo/foo-prop", "annotations": { "title": "foo-prop-title" } + }, + { + "valid": true, + "evaluationPath": "/properties/foo/1/additionalProperties/unspecified-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1/additionalProperties/unspecified-prop", + "instanceLocation": "/foo/unspecified-prop" } ] } @@ -3351,26 +3364,25 @@ https://example.com/schemas/common#/$defs/count/minimum { "valid": true, "evaluationPath": "/properties/bar", - "schemaLocation": - "https://json-schema.org/schemas/example#/properties/bar", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/bar", "instanceLocation": "/bar", "nested": [ { "valid": true, "evaluationPath": "/properties/bar/$ref", - "schemaLocation": - "https://json-schema.org/schemas/example#/$defs/bar", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar", "instanceLocation": "/bar", "annotations": { "title": "bar-title", - "properties": [ "bar-prop" ] + "properties": [ + "bar-prop" + ] }, "nested": [ { "valid": true, "evaluationPath": "/properties/bar/$ref/properties/bar-prop", - "schemaLocation": - "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", "instanceLocation": "/bar/bar-prop", "annotations": { "title": "bar-prop-title" From 742221a9c2a0d6520a3539f3e82aa483483d9bcf Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Fri, 1 Jul 2022 20:55:30 +1200 Subject: [PATCH 361/780] fix URIs and remove location props from root node on basic --- jsonschema-core.xml | 61 +++++++++++++++++++++------------------------ 1 file changed, 28 insertions(+), 33 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 51182184..2c93e40d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3090,7 +3090,9 @@ https://example.com/schemas/common#/$defs/count/minimum <t> The root output unit contains "valid" for the overall result and "nested" for the list of specific results. All other information is explicitly - omitted from the root output unit. + omitted from the root output unit. If the root schema produces errors or + annotations, then the output node for the root MUST be present within the + root output unit's "nested" list with those errors or annotations. </t> <t> Output units which do not contain errors or annotations SHOULD be excluded @@ -3103,14 +3105,11 @@ https://example.com/schemas/common#/$defs/count/minimum // failing results { "valid": false, - "evaluationPath": "", - "schemaLocation": "https://json-schema.org/schemas/example#", - "instanceLocation": "", "nested": [ { "valid": false, - "evaluationPath": "/properties/foo/0", - "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/0", + "evaluationPath": "/properties/foo/allOf/0", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/0", "instanceLocation": "/foo", "errors": { "required": "Required properties [\"unspecified-prop\"] were not present" @@ -3118,8 +3117,8 @@ https://example.com/schemas/common#/$defs/count/minimum }, { "valid": false, - "evaluationPath": "/properties/foo/1/properties/foo-prop", - "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1/properties/foo-prop", + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", "instanceLocation": "/foo/foo-prop", "errors": { "const": "Expected \"1\"" @@ -3140,9 +3139,6 @@ https://example.com/schemas/common#/$defs/count/minimum // passing results { "valid": true, - "evaluationPath": "", - "schemaLocation": "https://json-schema.org/schemas/example#", - "instanceLocation": "", "nested": [ { "valid": true, @@ -3159,8 +3155,8 @@ https://example.com/schemas/common#/$defs/count/minimum }, { "valid": true, - "evaluationPath": "/properties/foo/1", - "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1", + "evaluationPath": "/properties/foo/allOf/1", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1", "instanceLocation": "/foo", "annotations": { "title": "foo-title", @@ -3186,8 +3182,8 @@ https://example.com/schemas/common#/$defs/count/minimum }, { "valid": true, - "evaluationPath": "/properties/foo/1/properties/foo-prop", - "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1/properties/foo-prop", + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", "instanceLocation": "/foo/foo-prop", "annotations": { "title": "foo-prop-title" @@ -3220,8 +3216,7 @@ https://example.com/schemas/common#/$defs/count/minimum All output units are included in this format. </t> <t> - The location properties of the output unit MAY be omitted from the - root node. + The location properties of the root output unit MAY be omitted. </t> <figure> <artwork> @@ -3241,8 +3236,8 @@ https://example.com/schemas/common#/$defs/count/minimum "nested": [ { "valid": false, - "evaluationPath": "/properties/foo/0", - "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/0", + "evaluationPath": "/properties/foo/allOf/0", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/0", "instanceLocation": "/foo", "errors": { "required": "Required properties [\"unspecified-prop\"] were not present" @@ -3250,14 +3245,14 @@ https://example.com/schemas/common#/$defs/count/minimum }, { "valid": false, - "evaluationPath": "/properties/foo/1", - "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1", + "evaluationPath": "/properties/foo/allOf/1", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1", "instanceLocation": "/foo", "nested": [ { "valid": false, - "evaluationPath": "/properties/foo/1/properties/foo-prop", - "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1/properties/foo-prop", + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", "instanceLocation": "/foo/foo-prop", "errors": { "const": "Expected \"1\"" @@ -3265,8 +3260,8 @@ https://example.com/schemas/common#/$defs/count/minimum }, { "valid": true, - "evaluationPath": "/properties/foo/1/additionalProperties/other-prop", - "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1/additionalProperties/other-prop", + "evaluationPath": "/properties/foo/allOf/1/additionalProperties", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/additionalProperties", "instanceLocation": "/foo/other-prop" } ] @@ -3323,14 +3318,14 @@ https://example.com/schemas/common#/$defs/count/minimum "nested": [ { "valid": true, - "evaluationPath": "/properties/foo/0", - "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/0", + "evaluationPath": "/properties/foo/allOf/0", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/0", "instanceLocation": "/foo" }, { "valid": true, - "evaluationPath": "/properties/foo/1", - "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1", + "evaluationPath": "/properties/foo/allOf/1", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1", "instanceLocation": "/foo", "annotations": { "title": "foo-title", @@ -3344,8 +3339,8 @@ https://example.com/schemas/common#/$defs/count/minimum "nested": [ { "valid": true, - "evaluationPath": "/properties/foo/1/properties/foo-prop", - "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1/properties/foo-prop", + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", "instanceLocation": "/foo/foo-prop", "annotations": { "title": "foo-prop-title" @@ -3353,8 +3348,8 @@ https://example.com/schemas/common#/$defs/count/minimum }, { "valid": true, - "evaluationPath": "/properties/foo/1/additionalProperties/unspecified-prop", - "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/1/additionalProperties/unspecified-prop", + "evaluationPath": "/properties/foo/allOf/1/additionalProperties", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/additionalProperties", "instanceLocation": "/foo/unspecified-prop" } ] From 46c598db27b0c45dfcf1a4ffac7e04cff545e562 Mon Sep 17 00:00:00 2001 From: Juan Cruz Viotti <jv@jviotti.com> Date: Wed, 20 Jul 2022 13:34:10 -0400 Subject: [PATCH 362/780] Track the xml2rfc dependency using a requirements.txt file The standard practice for tracking dependencies on Python projects is to declare the dependencies and the expected versions on a `requirements.txt` file that is read by `pip`. Right now, we request people to manually install the latest version of `xml2rfc`. After this commit, we properly track `xml2rfc` on `requirements.txt` and tweak the documentation a bit to show users how to install it from there instead. Signed-off-by: Juan Cruz Viotti <jv@jviotti.com> --- README.md | 9 +++++++- requirements.in | 1 + requirements.txt | 55 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 64 insertions(+), 1 deletion(-) create mode 100644 requirements.in create mode 100644 requirements.txt diff --git a/README.md b/README.md index 5dd3478d..efc5a058 100644 --- a/README.md +++ b/README.md @@ -35,7 +35,14 @@ Labels are assigned based on [Sensible Github Labels](https://github.com/Releque * links.json - JSON Hyper-Schema's Link Description Object meta-schema * hyper-schema-output.json - The recommended output format for JSON Hyper-Schema links -Install "xml2rfc" using "pip" (https://pypi.org/project/xml2rfc/) and type "make" at a shell to build the .txt and .html spec files. +Install "xml2rfc" using "pip" (https://pypi.org/project/xml2rfc/) and type "make" at a shell to build the .txt and .html spec files: + +```sh +pip install --requirement requirements.txt +make +``` + +The version of "xml2rfc" that this project uses is updated by modifying `requirements.in` and running `pip-compile requirements.in`. Descriptions of the xml2rfc, I-D documents, and RFC processes: diff --git a/requirements.in b/requirements.in new file mode 100644 index 00000000..f5cf3e08 --- /dev/null +++ b/requirements.in @@ -0,0 +1 @@ +xml2rfc>=3.12.0 diff --git a/requirements.txt b/requirements.txt new file mode 100644 index 00000000..99992e4c --- /dev/null +++ b/requirements.txt @@ -0,0 +1,55 @@ +# +# This file is autogenerated by pip-compile with python 3.9 +# To update, run: +# +# pip-compile requirements.in +# +appdirs==1.4.4 + # via xml2rfc +certifi==2022.6.15 + # via requests +charset-normalizer==2.1.0 + # via requests +configargparse==1.5.3 + # via xml2rfc +google-i18n-address==2.5.2 + # via xml2rfc +html5lib==1.1 + # via xml2rfc +idna==3.3 + # via requests +intervaltree==3.1.0 + # via xml2rfc +jinja2==2.11.3 + # via xml2rfc +kitchen==1.2.6 + # via xml2rfc +lxml==4.9.1 + # via xml2rfc +markupsafe==2.1.1 + # via jinja2 +pycountry==22.3.5 + # via xml2rfc +pyflakes==2.4.0 + # via xml2rfc +pyyaml==6.0 + # via xml2rfc +requests==2.28.1 + # via + # google-i18n-address + # xml2rfc +six==1.16.0 + # via + # html5lib + # xml2rfc +sortedcontainers==2.4.0 + # via intervaltree +urllib3==1.26.10 + # via requests +webencodings==0.5.1 + # via html5lib +xml2rfc==3.12.0 + # via -r requirements.in + +# The following packages are considered to be unsafe in a requirements file: +# setuptools From 0bb6490646df4c140b68b05dcb298f065c5a7561 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Fri, 22 Jul 2022 04:20:26 +0000 Subject: [PATCH 363/780] Bump xml2rfc from 3.12.0 to 3.12.4 Bumps [xml2rfc](https://github.com/ietf-tools/xml2rfc) from 3.12.0 to 3.12.4. - [Release notes](https://github.com/ietf-tools/xml2rfc/releases) - [Changelog](https://github.com/ietf-tools/xml2rfc/blob/main/CHANGELOG.md) - [Commits](https://github.com/ietf-tools/xml2rfc/compare/cli/3.12.0...v3.12.4) --- updated-dependencies: - dependency-name: xml2rfc dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> --- requirements.txt | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/requirements.txt b/requirements.txt index 99992e4c..934c7d59 100644 --- a/requirements.txt +++ b/requirements.txt @@ -26,8 +26,10 @@ kitchen==1.2.6 # via xml2rfc lxml==4.9.1 # via xml2rfc -markupsafe==2.1.1 - # via jinja2 +markupsafe==2.0.1 + # via + # jinja2 + # xml2rfc pycountry==22.3.5 # via xml2rfc pyflakes==2.4.0 @@ -48,7 +50,7 @@ urllib3==1.26.10 # via requests webencodings==0.5.1 # via html5lib -xml2rfc==3.12.0 +xml2rfc==3.12.4 # via -r requirements.in # The following packages are considered to be unsafe in a requirements file: From 0d7b83659e97c8664ca30be2ae4022e1244fb062 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Wed, 27 Jul 2022 13:31:25 +1200 Subject: [PATCH 364/780] edits suggested by @handrews --- jsonschema-core.xml | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 2c93e40d..2169bc2a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2756,11 +2756,11 @@ Implementations MAY elect to provide additional information. </t> - <section title="Subschema Relative Location"> + <section title="Evaluation path"> <t> - The relative location of the validating subschema that follows the path - traversed through the schema. The value MUST be expressed as a JSON - Pointer, and it MUST include any by-reference applicators such as + The location of the schema resource that produced the output unit, represented + by the path traversed during evaluation. The value MUST be expressed as a + JSON Pointer, and it MUST include any by-reference applicators such as "$ref" or "$dynamicRef". <cref> The schema may not actually have a value at the location indicated @@ -2784,12 +2784,13 @@ </t> </section> - <section title="Subschema Absolute Location"> + <section title="Subschema Location"> <t> - The absolute, dereferenced location of the validating subschema. The value MUST - be expressed as a full IRI using the canonical IRI of the relevant - schema object, and it MUST NOT include by-reference applicators - such as "$ref" or "$dynamicRef" as path components. + The absolute, dereferenced location of the schema resource that produced + the output unit. The value MUST be expressed using the canonical IRI of the + relevant schema resource plus a JSON Pointer fragment that indicates the contained + subschema that produced the output. It MUST NOT include by-reference applicators + such as "$ref" or "$dynamicRef". <cref> Note that "absolute" here is in the sense of "absolute filesystem path" (meaning the complete location) rather than the "absolute-IRI" @@ -2857,11 +2858,12 @@ https://example.com/schemas/common#/$defs/count/minimum <section title="Nested Results"> <t> - Nested results are generated from applicator keywords: keywords with - subschemas or collections of subschemas as values. Keywords which - have arrays of subschemas (e.g. "anyOf") will generally generate an output - unit for each subschema. In order to accommodate potentially multiple - results, the value of this property MUST be an array of output units. + Nested results are generated from keywords which create a new dynamic + scope by applying a subschema to the instance or a child of the instance. + Keywords which have multiple subschemas (e.g. "anyOf") will generally + generate an output unit for each subschema. In order to accommodate + potentially multiple results, the value of this property MUST be an + array of output units, even if only a single output unit is produced. </t> <t> For "basic", this property will appear only at the root output unit From 8e74544295bc87dd60e48983b0a96537c561de91 Mon Sep 17 00:00:00 2001 From: Juan Cruz Viotti <jv@jviotti.com> Date: Wed, 20 Jul 2022 13:26:15 -0400 Subject: [PATCH 365/780] Add month to Relative JSON Pointer's spec <date/> It is currently not possible to build the Relative JSON Pointer's spec. `xml2rfc` will complain about the date tag not being the current year while not having a month set either. This is the error I get: ``` xml2rfc --html relative-json-pointer.xml -o relative-json-pointer.html json-schema-spec/relative-json-pointer.xml(16): Error: Expected <date> to have the current year when month is missing, but found '2021' Unable to complete processing relative-json-pointer.xml ``` This PR changes the `<date/>` year to the current year. Signed-off-by: Juan Cruz Viotti <jv@jviotti.com> --- relative-json-pointer.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 03654ef3..6fe6c485 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -40,7 +40,7 @@ </address> </author> - <date year="2021"/> + <date year="2022"/> <workgroup>Internet Engineering Task Force</workgroup> <keyword>JSON</keyword> <keyword>JavaScript</keyword> From fe67355341613c4f2ad60c33064e56489da3956b Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Thu, 4 Aug 2022 15:47:31 +1200 Subject: [PATCH 366/780] using 'dereferenced evaluation structure --- jsonschema-core.xml | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 2169bc2a..f0532031 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2727,12 +2727,7 @@ </t> <t> Hierarchical - Provides validation information in a hierarchical - structure that mimics the structure of the schema. - <cref> - To be precise, this structure follows the paths that a validator - would traverse while processing the schema, including composition - via by-reference keywords. - </cref> + structure that mimics the dereferenced evaluation structure of the schema. </t> </list> An implementation MUST provide the "flag" format and SHOULD provide at least one From 9673fb8318a0924287f925d57e5a4fa0aa641eb0 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Thu, 4 Aug 2022 15:53:15 +1200 Subject: [PATCH 367/780] align path terminology in the text with the renamings made for the output --- jsonschema-core.xml | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f580d50c..345629b5 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -679,7 +679,7 @@ which processing begins, even if it is not a schema resource root. The path from this root schema to any particular keyword (that includes any "$ref" and "$dynamicRef" keywords that may have - been resolved) is considered the keyword's "validation path." + been resolved) is considered the keyword's "evaluation path." </t> <t> Lexical and dynamic scopes align until a reference keyword @@ -698,7 +698,7 @@ when reporting errors and collected annotations, as it may be possible to revisit the same lexical scope repeatedly with different dynamic scopes. In such cases, it is important to inform the user of the - dynamic path that produced the error or annotation. + evaluation path that produced the error or annotation. </t> </section> <section title="Keyword Interactions"> @@ -930,12 +930,12 @@ The instance location to which it is attached, as a JSON Pointer </t> <t> - The schema location path, indicating how reference keywords + The evaluation path, indicating how reference keywords such as "$ref" were followed to reach the absolute schema location. </t> <t> The absolute schema location of the attaching keyword, as a IRI. - This MAY be omitted if it is the same as the schema location path + This MAY be omitted if it is the same as the evaluation path from above. </t> <t> @@ -1016,11 +1016,11 @@ author to write descriptions that work when combined in this way. </t> <t> - The application can use the schema location path to determine which + The application can use the evaluation path to determine which values are which. The values in the feature's immediate "enabled" property schema are more specific, while the values under the re-usable - schema that is referenced to with "$ref" are more generic. The schema - location path will show whether each value was found by crossing a + schema that is referenced to with "$ref" are more generic. The evaluation + path will show whether each value was found by crossing a "$ref" or not. </t> <t> @@ -3605,7 +3605,7 @@ https://example.com/schemas/common#/$defs/count/minimum scope before following the reference. </t> <t> - At this point, the dynamic path is + At this point, the evaluation path is "#/$ref/properties/children/items/$dynamicRef", with a dynamic scope containing (from the outermost scope to the innermost): <list style="numbers"> From 509ed28de2b15e3c7bdcff8444a6358cd580fd06 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Fri, 5 Aug 2022 07:50:40 +1200 Subject: [PATCH 368/780] more verbiage tweaks to output --- jsonschema-core.xml | 57 ++++++++++++++++++++++----------------------- 1 file changed, 28 insertions(+), 29 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f0532031..5d2ec745 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2727,7 +2727,8 @@ </t> <t> Hierarchical - Provides validation information in a hierarchical - structure that mimics the dereferenced evaluation structure of the schema. + structure that follows the evaluation paths generated while processing + the schema. </t> </list> An implementation MUST provide the "flag" format and SHOULD provide at least one @@ -2753,10 +2754,9 @@ <section title="Evaluation path"> <t> - The location of the schema resource that produced the output unit, represented - by the path traversed during evaluation. The value MUST be expressed as a - JSON Pointer, and it MUST include any by-reference applicators such as - "$ref" or "$dynamicRef". + The evalutaion path to the schema object that produced the output unit. + The value MUST be expressed as a JSON Pointer, and it MUST include any + by-reference applicators such as "$ref" or "$dynamicRef". <cref> The schema may not actually have a value at the location indicated by this pointer. It is provided as an indication of the traversal @@ -2779,19 +2779,19 @@ </t> </section> - <section title="Subschema Location"> + <section title="Schema Location"> <t> - The absolute, dereferenced location of the schema resource that produced + The absolute, dereferenced location of the schema object that produced the output unit. The value MUST be expressed using the canonical IRI of the - relevant schema resource plus a JSON Pointer fragment that indicates the contained - subschema that produced the output. It MUST NOT include by-reference applicators + relevant schema resource plus a JSON Pointer fragment that indicates the schema + object that produced the output. It MUST NOT include by-reference applicators such as "$ref" or "$dynamicRef". <cref> Note that "absolute" here is in the sense of "absolute filesystem path" (meaning the complete location) rather than the "absolute-IRI" - terminology from RFC 3987 (meaning with scheme but without fragment). - Keyword absolute locations will have a fragment in order to - identify the keyword. + terminology from RFC 3987 (meaning with scheme and without fragment). + Schema locations will have a fragment in order to identify the specific + schema object. </cref> </t> <figure> @@ -2844,7 +2844,7 @@ https://example.com/schemas/common#/$defs/count/minimum </t> <t> Each keyword defines its own annotation data type (e.g. "properties" - produces a list of keywords, whereas "$title" produces a string). + produces a list of keywords, whereas "title" produces a string). </t> <t> The JSON key for this information is "annotations". @@ -2887,11 +2887,10 @@ https://example.com/schemas/common#/$defs/count/minimum "nested" as described below. <list> <t> - "valid" - a boolean value indicating the overall validation success or - failure + "valid" - a boolean value indicating the overall validation success or failure </t> <t> - "nested" - the collection of errors or annotations produced by a subschema + "nested" - the collection of results produced by subschemas </t> </list> For these examples, the following schema and instances will be used. @@ -2963,21 +2962,21 @@ https://example.com/schemas/common#/$defs/count/minimum <list> <t> The value at "/foo" - validated at "/properties/foo/allOf/0" + evaluated at "/properties/foo/allOf/0" by following the path "/properties/foo/allOf/0" by the "required" keyword is missing the property "unspecified-prop". </t> <t> The value at "/foo/foo-prop" - validated at "/properties/foo/allOf/1/properties/foo-prop" + evaluated at "/properties/foo/allOf/1/properties/foo-prop" by following the path "/properties/foo/allOf/1/properties/foo-prop" by the "const" keyword is not the constant value 1. </t> <t> The value at "/bar/bar-prop" - validated at "/$defs/bar/properties/bar-prop" + evaluated at "/$defs/bar/properties/bar-prop" by following the path "/properties/bar/$ref/properties/bar-prop" by the "type" keyword is not a number. @@ -2999,55 +2998,55 @@ https://example.com/schemas/common#/$defs/count/minimum <list> <t> The keyword "title" - validated at "" + evaluated at "" by following the path "" will produce <sourcecode>"root"</sourcecode>. </t> <t> The keyword "properties" - validated at "" + evaluated at "" by following the path "" will produce <sourcecode>["foo", "bar"]</sourcecode>. </t> <t> The keyword "title" - validated at "/properties/foo" + evaluated at "/properties/foo" by following the path "/properties/foo" will produce <sourcecode>"foo-title"</sourcecode>. </t> <t> The keyword "properties" - validated at "/properties/foo/allOf/1" + evaluated at "/properties/foo/allOf/1" by following the path "/properties/foo/allOf/1" will produce <sourcecode>["foo-prop"]</sourcecode>. </t> <t> The keyword "additionalProperties" - validated at "/properties/foo/allOf/1" + evaluated at "/properties/foo/allOf/1" by following the path "/properties/foo/allOf/1" will produce <sourcecode>["unspecified-prop"]</sourcecode>. </t> <t> The keyword "title" - validated at "/properties/foo/allOf/1/properties/foo-prop" + evaluated at "/properties/foo/allOf/1/properties/foo-prop" by following the path "/properties/foo/allOf/1/properties/foo-prop" will produce <sourcecode>"foo-prop-title"</sourcecode>. </t> <t> The keyword "title" - validated at "/$defs/bar" + evaluated at "/$defs/bar" by following the path "/properties/bar/$ref" will produce <sourcecode>"bar-title"</sourcecode>. </t> <t> The keyword "properties" - validated at "/$defs/bar" + evaluated at "/$defs/bar" by following the path "/properties/var/$ref" will produce <sourcecode>["bar-prop"]</sourcecode>. </t> <t> The keyword "title" - validated at "/$defs/bar/properties/bar-prop" + evaluated at "/$defs/bar/properties/bar-prop" by following the path "/properties/bar/$ref/properties/bar-prop" will produce <sourcecode>"bar-prop-title"</sourcecode>. </t> @@ -3206,7 +3205,7 @@ https://example.com/schemas/common#/$defs/count/minimum <t> The "Hierarchical" structure is a tree structure that follows the evaluation path during the validation process. Typically, it will - resemble the schema as if all referenced schemas were bundled in place + resemble the schema as if all referenced schemas were inlined in place of their associated by-reference keywords. </t> <t> From b6799cd4ff8336318d74cfc80b09d43c2042710a Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Fri, 5 Aug 2022 09:45:55 +1200 Subject: [PATCH 369/780] correcting the number of output formats --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 5d2ec745..5970e166 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2715,7 +2715,7 @@ <section title="Output Formats"> <t> - This specification defines four output formats. See the "Output Structure" + This specification defines three output formats. See the "Output Structure" section for the requirements of each format. <list> <t> From 843a6833a4393d1292820fdeed4ee7b3d4e77b24 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Fri, 5 Aug 2022 13:32:34 +1200 Subject: [PATCH 370/780] update example locations for evaluationPath and schemaLocation --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 5970e166..1693e9d4 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2766,7 +2766,7 @@ <figure> <artwork> <![CDATA[ -/properties/width/$ref/minimum +/properties/width/$ref/allOf/1 ]]> </artwork> </figure> @@ -2797,7 +2797,7 @@ <figure> <artwork> <![CDATA[ -https://example.com/schemas/common#/$defs/count/minimum +https://example.com/schemas/common#/$defs/allOf/1 ]]> </artwork> </figure> From 71085efa0a1cd1e7e943c118d78b8aed8155b579 Mon Sep 17 00:00:00 2001 From: Julian Berman <Julian@GrayVines.com> Date: Wed, 10 Aug 2022 21:30:47 +0300 Subject: [PATCH 371/780] Update the xrefs, which appear now to have underscores? --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f580d50c..5343194f 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -511,7 +511,7 @@ </t> <t> Per the W3C's - <xref target="W3C.WD-fragid-best-practices-20121025">best practices for fragment identifiers</xref>, + <xref target="W3C_WD_fragid_best_practices_20121025">best practices for fragment identifiers</xref>, plain name fragment identifiers in "application/schema+json" are reserved for referencing locally named schemas. All fragment identifiers that do not match the JSON Pointer syntax MUST be interpreted as @@ -2030,7 +2030,7 @@ <t> It is RECOMMENDED that instances described by a schema provide a link to a downloadable JSON Schema using the link relation "describedby", as defined by - <xref target="W3C.REC-ldp-20150226">Linked Data Protocol 1.0, section 8.1</xref>. + <xref target="W3C_REC_ldp_20150226">Linked Data Protocol 1.0, section 8.1</xref>. </t> <t> From 148cb4fea2c5c3f7bfe01be238ecd107e39a1e63 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Wed, 10 Aug 2022 14:28:28 -0700 Subject: [PATCH 372/780] Ignore unknown keywords or treat as annotations When we added the "SHOULD collect as annotations" behavior for unknown keywords, we forgot to retain the MUST directive to ignore them if the SHOULD is not followed. Which also ensures that no other behavior than collecting as a annotations is performed. This also consolidates the behavioral specification in one place as it appeared in two places before. --- jsonschema-core.xml | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 5343194f..b3ea04e0 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -350,9 +350,9 @@ and its companions, are free to define other behaviors as well. </t> <t> - A JSON Schema MAY contain properties which are not schema keywords. - Unknown keywords SHOULD be treated as annotations, where the value - of the keyword is the value of the annotation. + A JSON Schema MAY contain properties which are not, or are not recognized as, schema keywords. + The behavior of such keywords is governed by section + <xref target="unrecognized" format="counter"></xref>. </t> <t> An empty schema is a JSON Schema with no properties, or only unknown @@ -600,14 +600,21 @@ by any entity. Save for explicit agreement, schema authors SHALL NOT expect these additional keywords and vocabularies to be supported by implementations that do not explicitly document such support. - Implementations SHOULD treat keywords they do not support as annotations, - where the value of the keyword is the value of the annotation. </t> <t> Implementations MAY provide the ability to register or load handlers for vocabularies that they do not support directly. The exact mechanism for registering and implementing such handlers is implementation-dependent. </t> + + <section title="Handling of unrecognized or unsupported keywords" anchor="unrecognized"> + <t> + Implementations SHOULD treat keywords they do not recognize, or that + they recognize but do not support, as annotations, where the value of + the keyword is the value of the annotation. Whether an implementation + collects these annotations or not, they MUST otherwise ignore the keywords. + </t> + </section> </section> </section> From 284a09abc387f85a1f451d9d270682bd75014c84 Mon Sep 17 00:00:00 2001 From: Henry Andrews <andrews_henry@yahoo.com> Date: Thu, 11 Aug 2022 21:11:25 -0700 Subject: [PATCH 373/780] Better phrasing / grammar from review feedback. Co-authored-by: Jason Desrosiers <jdesrosi@gmail.com> --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b3ea04e0..8fde61dc 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -350,7 +350,7 @@ and its companions, are free to define other behaviors as well. </t> <t> - A JSON Schema MAY contain properties which are not, or are not recognized as, schema keywords. + A JSON Schema MAY contain properties which are not schema keywords or are not recognized as schema keywords. The behavior of such keywords is governed by section <xref target="unrecognized" format="counter"></xref>. </t> From 29f4a121c1207b3134289c0b2f2a9f90be702364 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Sat, 13 Aug 2022 16:12:13 -0700 Subject: [PATCH 374/780] Disallow "#" as an $id. In a document root schema, "$id": "#" is a no-op, and in an embedded schema resource root, it results in the embeddded resource having the same URI as its context resource. Given that the specificaiton says implementations SHOULD raise an error for duplicate IRIs, there is no reason to allow this form. --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 5343194f..5b1153ad 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1353,8 +1353,8 @@ </t> <t> If present, the value for this keyword MUST be a string, and MUST represent a - valid <xref target="RFC3987">IRI-reference</xref>. This IRI-reference - SHOULD be normalized, and MUST resolve to an + valid <xref target="RFC3987">IRI-reference</xref> with a non-empty non-fragment + component. This IRI-reference SHOULD be normalized, and MUST resolve to an <xref target="RFC3987">absolute-IRI</xref> (without a fragment), or to a IRI with an empty fragment. </t> From bdbf918ee8a061523189d9061c8b0234756c7cdf Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Sat, 13 Aug 2022 16:24:08 -0700 Subject: [PATCH 375/780] Consolidate and clarify duplicate IRI behavior --- jsonschema-core.xml | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 5b1153ad..9a79eb25 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1456,11 +1456,16 @@ fragment "#foo" when used in a IRI. See below for full examples. </cref> </t> + </section> + + <section title="Duplicate schema identifiers"> <t> - The effect of specifying the same fragment name multiple times within - the same resource, using any combination of "$anchor" and/or - "$dynamicAnchor", is undefined. Implementations MAY - raise an error if such usage is detected. + A schema MAY (and likely will) have multiple IRIs, but there is no way + for an IRI to identify more than one schema. When multiple schemas + attempt to identify as the same IRI through the use of "$id", "$anchor", + "$dynamicAnchor", or any other mechanism, implementations SHOULD raise + an error condition. Otherwise the result is undefined, and even if + documented will not be interoperable. </t> </section> @@ -1671,11 +1676,6 @@ be noted within a schema document as it is processed, producing associations as shown in appendix <xref target="idExamples" format="counter"></xref>. </t> - <t> - A schema MAY (and likely will) have multiple IRIs, but there is no way for a - IRI to identify more than one schema. When multiple schemas try to identify - as the same IRI, validators SHOULD raise an error condition. - </t> </section> <section title="Detecting a Meta-Schema"> From 170ba3b65e2bd76201725bfff5268fb7edbd543e Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Sat, 13 Aug 2022 16:37:26 -0700 Subject: [PATCH 376/780] Note that empty fragments produce duplicates --- jsonschema-core.xml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 9a79eb25..c5438b38 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1467,6 +1467,11 @@ an error condition. Otherwise the result is undefined, and even if documented will not be interoperable. </t> + <t> + Note that due to the semantics of JSON Pointer fragments, schema IRIs + that differ only by the presence or absence of an empty fragment MUST + be considered duplicates. + </t> </section> <section title="Schema References" anchor="references"> From b6ea8a341e775c749254b8e00e46e2a7ef951a6a Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Mon, 15 Aug 2022 08:47:13 +1200 Subject: [PATCH 377/780] add clarification around empty-string error messages --- jsonschema-core.xml | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 1693e9d4..d6e58dad 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2822,8 +2822,18 @@ https://example.com/schemas/common#/$defs/allOf/1 be included if the validation was successful. The value for this property MUST be an object where the keys are the names of keywords and the values are the error message produced by the - associated keyword. If the subschema itself is producing the - error, that error MUST be listed with an empty string key. + associated keyword. + </t> + <t> + If the subschema itself is producing the error, that error MUST be + listed with an empty string key. + <cref> + Although there may be other cases where a subschema can produce + an error, the most common case is the "false" schema. In + cases like these, there is no keyword that produces the error, + so there is nothing to use as a key. Thus the empty string + is used instead. + </cref> </t> <t> The specific wording for the message is not defined by this From 70ba572c197e223c0484a1a7af555744d206a1ef Mon Sep 17 00:00:00 2001 From: Roberto Polli <robipolli@gmail.com> Date: Sun, 14 Aug 2022 23:17:19 +0200 Subject: [PATCH 378/780] Add data-model anchor. --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 5343194f..fbfdfd7a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -187,7 +187,7 @@ </t> <t> In JSON Schema, the terms "JSON document", "JSON text", and "JSON value" are - interchangeable because of the data model it defines. + interchangeable because of the data model it defines in <xref target="data-model" />. </t> <t> JSON Schema is only defined over JSON documents. However, any document or memory @@ -210,7 +210,7 @@ media type which defines handling for fragments in the IRI. </t> - <section title="Instance Data Model"> + <section title="Instance Data Model" anchor="data-model"> <t> JSON Schema interprets documents according to a data model. A JSON value interpreted according to this data model is called an "instance". From b4a2003f88df8deea33e9d4610fb9ed8986d87df Mon Sep 17 00:00:00 2001 From: Juan Cruz Viotti <jv@jviotti.com> Date: Fri, 5 Aug 2022 08:35:54 -0400 Subject: [PATCH 379/780] Replace defunct Travis CI integration with GitHub Actions The GitHub Actions setup is equivalent to the Travis CI configuration with two differences: - The GitHub Action setup does not set the `TAG` environment variable, as it didn't seem like `xml2rfc` would consume that at all (unless I'm missing something) - The GitHub Action preserves the spec output (txt and html) as artifacts that can be downloaded after a successful run (to see the changes without having to locally render the specs) Fixes: https://github.com/json-schema-org/json-schema-spec/issues/1262 Signed-off-by: Juan Cruz Viotti <jv@jviotti.com> --- .github/workflows/ci.yml | 14 ++++++++++++++ .travis.yml | 8 -------- 2 files changed, 14 insertions(+), 8 deletions(-) create mode 100644 .github/workflows/ci.yml delete mode 100644 .travis.yml diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml new file mode 100644 index 00000000..6b03b6bf --- /dev/null +++ b/.github/workflows/ci.yml @@ -0,0 +1,14 @@ +name: JSON Schema +on: + - push +jobs: + specs: + runs-on: ubuntu-22.04 + steps: + - uses: actions/checkout@v3 + - run: pip install --requirement requirements.txt + - run: xml2rfc --version + - run: make all + - uses: actions/upload-artifact@v2 + with: + path: *.(html|txt) diff --git a/.travis.yml b/.travis.yml deleted file mode 100644 index 00e794b4..00000000 --- a/.travis.yml +++ /dev/null @@ -1,8 +0,0 @@ -language: python -install: -- pip install "xml2rfc~=2.20" -before_script: -- TAG=$(git tag -l --points-at HEAD) -script: -- xml2rfc -V -- make all From d4a16e5b8699afd62a62a32b0454c55d334f5976 Mon Sep 17 00:00:00 2001 From: Juan Cruz Viotti <jv@jviotti.com> Date: Mon, 15 Aug 2022 09:03:47 -0400 Subject: [PATCH 380/780] Update .github/workflows/ci.yml Co-authored-by: Ben Hutton <relequestual@gmail.com> --- .github/workflows/ci.yml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 6b03b6bf..ddfeb25f 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -11,4 +11,6 @@ jobs: - run: make all - uses: actions/upload-artifact@v2 with: - path: *.(html|txt) + path: | + *.(html|txt) + !requirements.txt From 5a8ac4bd63b1723be3da1a648266084677f20fd6 Mon Sep 17 00:00:00 2001 From: Julian Berman <Julian@GrayVines.com> Date: Fri, 19 Aug 2022 13:01:05 +0300 Subject: [PATCH 381/780] Fix artifact upload patterns. actions/glob doesn't appear to support |. See https://github.com/actions/toolkit/tree/main/packages/glob#glob-behavior --- .github/workflows/ci.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index ddfeb25f..ac611e39 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -12,5 +12,6 @@ jobs: - uses: actions/upload-artifact@v2 with: path: | - *.(html|txt) + *.html + *.txt !requirements.txt From 839b86bc56203f7bfe153a8034748e9064168325 Mon Sep 17 00:00:00 2001 From: Julian Berman <Julian@GrayVines.com> Date: Fri, 19 Aug 2022 13:02:47 +0300 Subject: [PATCH 382/780] Install a specific Python version rather than relying on PATH. And bump the upload-artifact version to the latest. --- .github/workflows/ci.yml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index ac611e39..cdac269b 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -6,10 +6,13 @@ jobs: runs-on: ubuntu-22.04 steps: - uses: actions/checkout@v3 + - uses: actions/setup-python@v4 + with: + python-version: "3.10" - run: pip install --requirement requirements.txt - run: xml2rfc --version - run: make all - - uses: actions/upload-artifact@v2 + - uses: actions/upload-artifact@v3 with: path: | *.html From ea9f5dc212c107cbb77cb72a8f4028863e2e1186 Mon Sep 17 00:00:00 2001 From: Julian Berman <Julian@GrayVines.com> Date: Fri, 19 Aug 2022 13:06:05 +0300 Subject: [PATCH 383/780] Name the resulting artifact. --- .github/workflows/ci.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index cdac269b..808aff16 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -14,6 +14,7 @@ jobs: - run: make all - uses: actions/upload-artifact@v3 with: + name: specification-docs path: | *.html *.txt From 853c82bd9e4a1a33fa28950e977a2ab8bd6144d4 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Sun, 21 Aug 2022 14:07:14 -0700 Subject: [PATCH 384/780] Don't forbid cases already noted as errors But do highlight that they are errors in the section where that is likely to be the most relevant. --- jsonschema-core.xml | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index c5438b38..dfdafe13 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1353,8 +1353,8 @@ </t> <t> If present, the value for this keyword MUST be a string, and MUST represent a - valid <xref target="RFC3987">IRI-reference</xref> with a non-empty non-fragment - component. This IRI-reference SHOULD be normalized, and MUST resolve to an + valid <xref target="RFC3987">IRI-reference</xref>. This IRI-reference + SHOULD be normalized, and MUST resolve to an <xref target="RFC3987">absolute-IRI</xref> (without a fragment), or to a IRI with an empty fragment. </t> @@ -1392,7 +1392,10 @@ <xref target="RFC3986">RFC 3986 section 5.1.2</xref> regarding encapsulating entities, if an "$id" in a subschema is a relative IRI-reference, the base IRI for resolving that reference is the IRI of - the parent schema resource. + the parent schema resource. Note that an "$id" consisting of an empty IRI or + of the empty fragment only will result in the embedded resource having + the same IRI as the encapsulating resource, which SHOULD be considered + an error per section <xref target="duplicate-iris" format="counter"></xref>. </t> <t> If no parent schema object explicitly identifies itself as a resource @@ -1458,7 +1461,7 @@ </t> </section> - <section title="Duplicate schema identifiers"> + <section title="Duplicate schema identifiers" anchor="duplicate-iris"> <t> A schema MAY (and likely will) have multiple IRIs, but there is no way for an IRI to identify more than one schema. When multiple schemas From 936b85df37bb4982f24e01630584c3cec8a634a7 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Thu, 8 Sep 2022 23:44:49 -0700 Subject: [PATCH 385/780] xref format changed again Now there's a dot between W3C and the rest, and the underscores are back to hyphens. Apparently. --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0ba8ad74..0181a388 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -511,7 +511,7 @@ </t> <t> Per the W3C's - <xref target="W3C_WD_fragid_best_practices_20121025">best practices for fragment identifiers</xref>, + <xref target="W3C.WD-fragid-best-practices-20121025">best practices for fragment identifiers</xref>, plain name fragment identifiers in "application/schema+json" are reserved for referencing locally named schemas. All fragment identifiers that do not match the JSON Pointer syntax MUST be interpreted as @@ -2045,7 +2045,7 @@ <t> It is RECOMMENDED that instances described by a schema provide a link to a downloadable JSON Schema using the link relation "describedby", as defined by - <xref target="W3C_REC_ldp_20150226">Linked Data Protocol 1.0, section 8.1</xref>. + <xref target="W3C.REC-ldp-20150226">Linked Data Protocol 1.0, section 8.1</xref>. </t> <t> From b3f4f14a470c77c902c39c0f430900b4d61defd7 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Sun, 18 Sep 2022 14:53:03 -0700 Subject: [PATCH 386/780] Clarify prefixItems wording about array length --- jsonschema-core.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0181a388..9e07c7b6 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2350,9 +2350,9 @@ <t> Validation succeeds if each element of the instance validates against the schema at the same position, if any. This keyword - does not constrain the length of the array. If the array is longer - than this keyword's value, this keyword validates only the - prefix of matching length. + does not constrain the length of the array. Only array positions + present in both the keyword's value and the instance value are + affected by this keyword. </t> <t> This keyword produces an annotation value which is the largest From cf618cdbbc46e17469560aef5fdcde77d862c313 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Sun, 18 Sep 2022 15:09:14 -0700 Subject: [PATCH 387/780] Disallow fragments in "$id" --- jsonschema-core.xml | 30 ++---------------------------- meta/core.json | 4 ++-- 2 files changed, 4 insertions(+), 30 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0181a388..d529424f 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1362,31 +1362,10 @@ If present, the value for this keyword MUST be a string, and MUST represent a valid <xref target="RFC3987">IRI-reference</xref>. This IRI-reference SHOULD be normalized, and MUST resolve to an - <xref target="RFC3987">absolute-IRI</xref> (without a fragment), - or to a IRI with an empty fragment. + <xref target="RFC3987">absolute-IRI</xref> (without a fragment). </t> <t> - The empty fragment form is NOT RECOMMENDED and is retained only - for backwards compatibility, and because the - application/schema+json media type defines that a IRI with an - empty fragment identifies the same resource as the same IRI - with the fragment removed. However, since this equivalence is not - part of the <xref target="RFC3986">RFC 3986 normalization process</xref>, - implementers and schema authors cannot rely on generic IRI libraries - understanding it. - </t> - <t> - Therefore, "$id" MUST NOT contain a non-empty fragment, and SHOULD NOT - contain an empty fragment. The absolute-IRI form MUST be considered - the canonical IRI, regardless of the presence or absence of an empty fragment. - <cref> - An empty fragment is currently allowed because older meta-schemas have - an empty fragment in their $id (or previously, id). - A future draft may outright forbid even empty fragments in "$id". - </cref> - </t> - <t> - The absolute-IRI also serves as the base IRI for relative IRI-references + The resulting absolute-IRI serves as the base IRI for relative IRI-references in keywords within the schema resource, in accordance with <xref target="RFC3987">RFC 3987 section 6.5</xref> and <xref target="RFC3986">RFC 3986 section 5.1.1</xref> regarding base IRIs @@ -1477,11 +1456,6 @@ an error condition. Otherwise the result is undefined, and even if documented will not be interoperable. </t> - <t> - Note that due to the semantics of JSON Pointer fragments, schema IRIs - that differ only by the presence or absence of an empty fragment MUST - be considered duplicates. - </t> </section> <section title="Schema References" anchor="references"> diff --git a/meta/core.json b/meta/core.json index 087ebd37..5c550ccb 100644 --- a/meta/core.json +++ b/meta/core.json @@ -11,8 +11,8 @@ "properties": { "$id": { "$ref": "#/$defs/iriReferenceString", - "$comment": "Non-empty fragments not allowed.", - "pattern": "^[^#]*#?$" + "$comment": "Fragments not allowed.", + "pattern": "^[^#]*$" }, "$schema": { "$ref": "#/$defs/iriString" }, "$ref": { "$ref": "#/$defs/iriReferenceString" }, From 169c5c29055675220b8375cba3cee284fb6db1e3 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Sun, 18 Sep 2022 15:41:02 -0700 Subject: [PATCH 388/780] Fix schema->subschema in prefixItems description --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 9e07c7b6..f1ac7b7d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2349,7 +2349,7 @@ </t> <t> Validation succeeds if each element of the instance validates - against the schema at the same position, if any. This keyword + against the subschema at the same position, if any. This keyword does not constrain the length of the array. Only array positions present in both the keyword's value and the instance value are affected by this keyword. From 240504439071a268631cddba2a29424a42f3a3cd Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Sun, 18 Sep 2022 14:57:00 -0700 Subject: [PATCH 389/780] Missed a "schema document" -> "schema resource" This was just an oversight regarding where $vocabualry is legal. It should have always been "schema resource root." --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0181a388..1001eb83 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1273,10 +1273,10 @@ </t> <t> The "$vocabulary" keyword SHOULD be used in the root schema of any schema - document intended for use as a meta-schema. It MUST NOT appear in subschemas. + resource intended for use as a meta-schema. It MUST NOT appear in subschemas. </t> <t> - The "$vocabulary" keyword MUST be ignored in schema documents that + The "$vocabulary" keyword MUST be ignored in schema resources that are not being processed as a meta-schema. This allows validating a meta-schema M against its own meta-schema M' without requiring the validator to understand the vocabularies declared by M. From e59dc7a4a018557560ddde5a18b97ead385a843c Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Sun, 18 Sep 2022 19:07:52 -0700 Subject: [PATCH 390/780] Disallow even optional "content*" processing This added substantial complexity for essentially no benefit. The functionality could be trivially implemented as a library on top of a JSON Schema implementation that supports annotation collection. --- jsonschema-validation.xml | 33 +++++++-------------------------- 1 file changed, 7 insertions(+), 26 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index a8426471..a95905b0 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -936,42 +936,22 @@ <t> Due to security and performance concerns, as well as the open-ended nature of possible content types, implementations MUST NOT automatically decode, parse, - and/or validate the string contents by default. This additionally supports - the use case of embedded documents intended for processing by a different - consumer than that which processed the containing document. + and/or validate the string contents. Applications are expected to use these + annotations to invoke the appropriate libraries (including JSON Schema for + any further schema-based validation) separately. </t> <t> All keywords in this section apply only to strings, and have no effect on other data types. </t> - <t> - Implementations MAY offer the ability to decode, parse, and/or validate - the string contents automatically. However, it MUST NOT perform these - operations by default, and MUST provide the validation result of each - string-encoded document separately from the enclosing document. This - process SHOULD be equivalent to fully evaluating the instance against - the original schema, followed by using the annotations to decode, parse, - and/or validate each string-encoded document. - <cref> - For now, the exact mechanism of performing and returning parsed - data and/or validation results from such an automatic decoding, parsing, - and validating feature is left unspecified. Should such a feature - prove popular, it may be specified more thoroughly in a future draft. - </cref> - </t> - <t> - See also the <xref target="security">Security Considerations</xref> - sections for possible vulnerabilities introduced by automatically - processing the instance string according to these keywords. - </t> </section> <section title="contentEncoding"> <t> If the instance value is a string, this property defines that the string - SHOULD be interpreted as encoded binary data and decoded using the encoding - named by this property. + SHOULD be interpreted as encoded binary data and, and applications wishing + to decode it SHOULD do so using the encoding named by this property. </t> <t> @@ -1023,7 +1003,8 @@ </t> <t> This keyword MAY be used with any media type that can be mapped into - JSON Schema's data model. + JSON Schema's data model. Specifying such mappings is outside of the + scope of this specification. </t> <t> The value of this property MUST be a valid JSON schema. It SHOULD be ignored if From c9038e8c4a447e5a42b279e27b0953b07a9e9ae0 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Sun, 18 Sep 2022 19:22:16 -0700 Subject: [PATCH 391/780] Note non-anchoring of regexes in the regex section. --- jsonschema-core.xml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0181a388..888c226a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -563,6 +563,11 @@ These regular expressions SHOULD be valid according to the regular expression dialect described in <xref target="ecma262">ECMA-262, section 21.2.1</xref>. </t> + <t> + Unless otherwise specified by a keyword, regular expressions MUST NOT be + considered to be implicitly anchored at either end. All regular expression + keywords in this specification and its companion documents are un-anchored. + </t> <t> Regular expressions SHOULD be built with the "u" flag (or equivalent) to provide Unicode support, or processed in such a way which provides Unicode support as From f557cc769ad4ccc55e26db2ebcbe4372cfdd9d70 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Sun, 18 Sep 2022 20:11:44 -0700 Subject: [PATCH 392/780] Empty schemas are really empty --- jsonschema-core.xml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0181a388..85419398 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -355,8 +355,7 @@ <xref target="unrecognized" format="counter"></xref>. </t> <t> - An empty schema is a JSON Schema with no properties, or only unknown - properties. + An empty schema is a JSON Schema with no properties. </t> </section> <section title="Boolean JSON Schemas"> From bab5a093298988d32d52524636fb16a741f65e4e Mon Sep 17 00:00:00 2001 From: Ethan <ethan@unth.net> Date: Wed, 21 Sep 2022 02:10:32 -0700 Subject: [PATCH 393/780] Core#Dereferencing example schema: remove second dimension of array --- jsonschema-core.xml | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 0181a388..f645b174 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1741,10 +1741,8 @@ <![CDATA[ { "$id": "https://example.net/root.json", - "items": { - "type": "array", - "items": { "$ref": "#item" } - }, + "type": "array", + "items": { "$ref": "#item" }, "$defs": { "single": { "$anchor": "item", From afbbb7d3570185d8fe6e8dc39b1fc61c1e73b0b1 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Thu, 22 Sep 2022 09:33:53 +1200 Subject: [PATCH 394/780] add pr-dependencies-check workflow --- .github/workflows/pr-dependencies.yml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 .github/workflows/pr-dependencies.yml diff --git a/.github/workflows/pr-dependencies.yml b/.github/workflows/pr-dependencies.yml new file mode 100644 index 00000000..2cf0fcaa --- /dev/null +++ b/.github/workflows/pr-dependencies.yml @@ -0,0 +1,14 @@ +name: Check PR Dependencies + +on: + pull_request: + workflow_dispatch: + +jobs: + check_dependencies: + runs-on: ubuntu-latest + name: Check Dependencies + steps: + - uses: gregsdennis/dependencies-action@main + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} \ No newline at end of file From 2a2f9838fcba67aa3cc006508332e8b3d5ccdf55 Mon Sep 17 00:00:00 2001 From: Henry Andrews <andrews_henry@yahoo.com> Date: Wed, 21 Sep 2022 20:06:42 -0700 Subject: [PATCH 395/780] Fix duplicated word Co-authored-by: Jason Desrosiers <jdesrosi@gmail.com> --- jsonschema-validation.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index a95905b0..119198f7 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -950,7 +950,7 @@ <t> If the instance value is a string, this property defines that the string - SHOULD be interpreted as encoded binary data and, and applications wishing + SHOULD be interpreted as encoded binary data and applications wishing to decode it SHOULD do so using the encoding named by this property. </t> From 9e81619ed8f518296537b56e3dbabd4b8cd92c83 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Sun, 18 Sep 2022 15:34:51 -0700 Subject: [PATCH 396/780] Explain why plain name fragments are as they are Because XML is/was the most likely need for cross-media-type fragment identifiers. --- jsonschema-core.xml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 1001eb83..767ab305 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1458,8 +1458,11 @@ If present, the value of this keyword MUST be a string and MUST start with a letter ([A-Za-z]) or underscore ("_"), followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), and periods ("."). - This matches the US-ASCII part of XML's - <xref target="xml-names">NCName production</xref>. + Due to the once-common practice of providing resource representations in + both JSON and XML, this matches the US-ASCII part of XML's + <xref target="xml-names">NCName production</xref>, which is noted in the + <xref target="W3C.WD-fragid-best-practices-20121025">WC3's best practices for fragment identifiers</xref> + as the typical plain name syntax for XML-based formats. <cref> Note that the anchor string does not include the "#" character, as it is not a IRI-reference. An "$anchor": "foo" becomes the From f367d474a9b531978a783a1de22cebf77132ac02 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" <hha1@cornell.edu> Date: Thu, 22 Sep 2022 19:36:21 -0700 Subject: [PATCH 397/780] Reorganize plain name fragment requirements In response to PR review feedback, remove the editorial explanation and instead consolidate the fragment syntax in the section on fragments. The context and reason for the syntax is more clear there with the existing text, and one additional line further clarifies it by not just seeming to reference a random XML syntax rule for no clear reason. --- jsonschema-core.xml | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 767ab305..037bcfc7 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -12,6 +12,7 @@ <!ENTITY RFC8288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8288.xml"> <!ENTITY ldp SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.REC-ldp-20150226.xml"> <!ENTITY fragid-best-practices SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml4/reference.W3C.WD-fragid-best-practices-20121025.xml"> +<!ENTITY xptr-framework SYSTEM "https://bib.ietf.org/public/rfc/bibxml4/reference.W3C.REC-xptr-framework-20030325.xml"> ]> <?rfc toc="yes"?> <?rfc symrefs="yes"?> @@ -513,7 +514,18 @@ Per the W3C's <xref target="W3C.WD-fragid-best-practices-20121025">best practices for fragment identifiers</xref>, plain name fragment identifiers in "application/schema+json" are reserved for referencing - locally named schemas. All fragment identifiers that do + locally named schemas. + </t> + <t> + Plain name fragments MUST start with a letter ([A-Za-z]) or underscore ("_"), + followed by any number of letters, digits ([0-9]), hyphens ("-"), + underscores ("_"), and periods ("."). This matches the US-ASCII part of XML's + <xref target="xml-names">NCName production</xref>, which allows for compatibility + with the recommended plain name <xref target="W3C.REC-xptr-framework-20030325">syntax</xref> for + XML-based media types. + </t> + <t> + All fragment identifiers that do not match the JSON Pointer syntax MUST be interpreted as plain name fragment identifiers. </t> @@ -1455,14 +1467,9 @@ need for "$dynamicAnchor". </t> <t> - If present, the value of this keyword MUST be a string and MUST start with - a letter ([A-Za-z]) or underscore ("_"), followed by any number of letters, - digits ([0-9]), hyphens ("-"), underscores ("_"), and periods ("."). - Due to the once-common practice of providing resource representations in - both JSON and XML, this matches the US-ASCII part of XML's - <xref target="xml-names">NCName production</xref>, which is noted in the - <xref target="W3C.WD-fragid-best-practices-20121025">WC3's best practices for fragment identifiers</xref> - as the typical plain name syntax for XML-based formats. + If present, the value of this keyword MUST be a string and MUST conform + to the plain name fragment identifier syntax defined in section + <xref target="fragments" format="counter"></xref>. <cref> Note that the anchor string does not include the "#" character, as it is not a IRI-reference. An "$anchor": "foo" becomes the @@ -3558,6 +3565,7 @@ https://example.com/schemas/common#/$defs/allOf/1 &RFC7231; &RFC8288; &fragid-best-practices; + &xptr-framework; <reference anchor="json-schema-validation"> <front> <title>JSON Schema Validation: A Vocabulary for Structural Validation of JSON From 903240e5a7cf30d58b83c53829a14232dd904562 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Thu, 22 Sep 2022 19:41:14 -0700 Subject: [PATCH 398/780] Fix singular to plural "these keywords" for both "$anchor" and "$dynamicAnchor" --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 037bcfc7..e5be8bbe 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1467,7 +1467,7 @@ need for "$dynamicAnchor". - If present, the value of this keyword MUST be a string and MUST conform + If present, the value of these keywords MUST be a string and MUST conform to the plain name fragment identifier syntax defined in section . From 8300dbd4779091ffbe900b0fb990306554e62fe3 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Fri, 23 Sep 2022 18:15:08 -0700 Subject: [PATCH 399/780] pattern regex anchor text to patternProperties Copied the text about regexes not being anchored from "pattern" to the analogous location in "patternProperties". --- jsonschema-core.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 888c226a..1a3f3493 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2446,7 +2446,8 @@ Validation succeeds if, for each instance name that matches any regular expressions that appear as a property name in this keyword's value, the child instance for that name successfully validates against each - schema that corresponds to a matching regular expression. + schema that corresponds to a matching regular expression. Recall: regular + expressions are not implicitly anchored. The annotation result of this keyword is the set of instance From e7d36b22c060285ee2ae36c315435a44a30582dd Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Mon, 26 Sep 2022 15:34:10 -0700 Subject: [PATCH 400/780] Remove confusing parenthetical aside based on review feedback. --- jsonschema-validation.xml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 119198f7..25cab621 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -937,8 +937,7 @@ Due to security and performance concerns, as well as the open-ended nature of possible content types, implementations MUST NOT automatically decode, parse, and/or validate the string contents. Applications are expected to use these - annotations to invoke the appropriate libraries (including JSON Schema for - any further schema-based validation) separately. + annotations to invoke the appropriate libraries separately. All keywords in this section apply only to strings, and have no From f853c055d21512a053422171bb2adfb2e14cb3ef Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 27 Sep 2022 13:17:51 +1300 Subject: [PATCH 401/780] workflow-dispatch not needed; can re-run manually through actions page --- .github/workflows/pr-dependencies.yml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/.github/workflows/pr-dependencies.yml b/.github/workflows/pr-dependencies.yml index 2cf0fcaa..34a231dc 100644 --- a/.github/workflows/pr-dependencies.yml +++ b/.github/workflows/pr-dependencies.yml @@ -1,8 +1,6 @@ name: Check PR Dependencies -on: - pull_request: - workflow_dispatch: +on: pull_request jobs: check_dependencies: From 9c3c31787619aa8e1b09930e8dd6b61f2e59d719 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Wed, 17 Aug 2022 13:37:52 -0700 Subject: [PATCH 402/780] Add ADR for decoupling from IETF --- adr/2022-08-decouple-from-ietf.md | 82 +++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 adr/2022-08-decouple-from-ietf.md diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md new file mode 100644 index 00000000..334b7eb6 --- /dev/null +++ b/adr/2022-08-decouple-from-ietf.md @@ -0,0 +1,82 @@ +# Decoupling from IETF + +* Status: accepted +* Deciders: @jdesrosiers @relequestual @awwright +* Date: 2022-08-17 + +Related Issues: +* https://github.com/orgs/json-schema-org/discussions/69 - This issue is about + dropping the "draft" prefix from our releases. This ADR doesn't cover that, + but much of the discussion about whether or not to decouple from IETF is in + that discussion. +* This topic has been discussed in many other places as well that are difficult + to link to here including Slack, Twitter, OCWMs, and conference discussions. + +## Context and Problem Statement + +Currently JSON Schema follows the IETF Internet-Draft (I-D) process for spec +development and releases but aren't associated with IETF in any way. Our +perceived involvement with IETF causes confusion and misunderstanding within our +community in the cases were our needs and the realities of our situation deviate +from the IETF process. + +## Decision Drivers + +* IETF's draft versioning system doesn't work for JSON Schema and we stopped + using it to version our releases a while ago. We now use a date based version + and even have more than one draft submission per release (the initial release + and the patch release). +* The IETF process is optimized for working on a draft until it's done and then + disbanding. In some cases, the RFC may be revisited and revised in the future, + but this is rare and generally contains little more than clarifications and + reference updates. JSON Schema is not like that. JSON Schema is more like a + programming language. When it stops evolving, it will loose it's relevance. + When we finish a release of JSON Schema, we don't disband, we start work on + the next release. +* Every one of our releases is expected to be used in production and will be + depended on for many years forward. This is not consistent with normal IETF + drafts. Even if we don't publicly use the term "draft", we're still using the + IETF I-D system in a way that's not intended. +* Under IETF, JSON Schema fits under the category of "draft". The community has + repeatedly told us that they perceive this to meant that JSON Schema + "incomplete" and not "not ready for production use". This is the wrong message + for us to be sending as all of our releases are intended to be used in + production. This ADR doesn't decide whether or not to drop the "draft" from + our releases, but decoupling from IETF gives us that option. +* Several members of the JSON Schema team have had poor interactions with IETF + and don't feel that working with them would be productive. This is a + relatively minor consideration. If we thought IETF was right for JSON Schema, + we could find ways to make those relationships work. + +## Considered Options + +1. Continue to submit I-Ds, while using our customized process with no intention + of pursing standards track RFC status. +2. Get JSON Schema to a stable place and pursue a standards track RFC with the + IETF. +3. Decouple from IETF completely and come up with our own governance model. + +## Decision Outcome + +Our decision is to go with Option 3 and decouple from IETF completely and come +up with our own governance model. The idea of having the come up with our own +governance model is daunting, but when the alternatives are to continue to abuse +the I-D process or to conform to the IETF process that doesn't fit our needs, +going our own way seems the bast option. + +### Positive Consequences + +* Decoupling from IETF allows us to distance ourselves from the assumptions that + people make about JSON Schema because they assume it works like a typical I-D. +* Decoupling from IETF allows us to customize our governance model to what works + best for JSON Schema. + +### Negative Consequences + +* Choosing our own governance model means we aren't associated with a recognized + standard body which could reduce to credibility of JSON Schema in the eyes of + some. +* If we don't go the standardization route with IETF, we lose access to their + expert review process. +* Defining our own process will be a lot of work and none of use have expertise + in defining such a process. From 0cbc716b8658dbb814708ca93b18aa5c475b87cf Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 18 Aug 2022 10:57:12 -0700 Subject: [PATCH 403/780] Update adr/2022-08-decouple-from-ietf.md Co-authored-by: Ethan <133719+notEthan@users.noreply.github.com> --- adr/2022-08-decouple-from-ietf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index 334b7eb6..f6c616bf 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -30,7 +30,7 @@ from the IETF process. disbanding. In some cases, the RFC may be revisited and revised in the future, but this is rare and generally contains little more than clarifications and reference updates. JSON Schema is not like that. JSON Schema is more like a - programming language. When it stops evolving, it will loose it's relevance. + programming language. When it stops evolving, it will lose its relevance. When we finish a release of JSON Schema, we don't disband, we start work on the next release. * Every one of our releases is expected to be used in production and will be From f485015d6f32722c4193333b94f7d2c64203dba9 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 18 Aug 2022 10:57:59 -0700 Subject: [PATCH 404/780] Update adr/2022-08-decouple-from-ietf.md Co-authored-by: Ethan <133719+notEthan@users.noreply.github.com> --- adr/2022-08-decouple-from-ietf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index f6c616bf..dfef110a 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -59,7 +59,7 @@ from the IETF process. ## Decision Outcome Our decision is to go with Option 3 and decouple from IETF completely and come -up with our own governance model. The idea of having the come up with our own +up with our own governance model. The idea of having to come up with our own governance model is daunting, but when the alternatives are to continue to abuse the I-D process or to conform to the IETF process that doesn't fit our needs, going our own way seems the bast option. From 12cbd86fbd2870e67043ac65158fc12ab1899cd5 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 18 Aug 2022 10:58:30 -0700 Subject: [PATCH 405/780] Update adr/2022-08-decouple-from-ietf.md Co-authored-by: Ethan <133719+notEthan@users.noreply.github.com> --- adr/2022-08-decouple-from-ietf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index dfef110a..52934d5f 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -62,7 +62,7 @@ Our decision is to go with Option 3 and decouple from IETF completely and come up with our own governance model. The idea of having to come up with our own governance model is daunting, but when the alternatives are to continue to abuse the I-D process or to conform to the IETF process that doesn't fit our needs, -going our own way seems the bast option. +going our own way seems the best option. ### Positive Consequences From fd4f83cdf6cf889a77cfb470c2ed38c46f62f4e8 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 18 Aug 2022 13:52:59 -0700 Subject: [PATCH 406/780] ADR decouple from IETF draft 2 --- adr/2022-08-decouple-from-ietf.md | 49 +++++++++++++++++-------------- 1 file changed, 27 insertions(+), 22 deletions(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index 52934d5f..3ab9eebe 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -14,16 +14,16 @@ Related Issues: ## Context and Problem Statement -Currently JSON Schema follows the IETF Internet-Draft (I-D) process for spec -development and releases but aren't associated with IETF in any way. Our +Currently JSON Schema loosely follows the IETF Internet-Draft (I-D) process for +spec development and releases but isn't associated with IETF in any way. Our perceived involvement with IETF causes confusion and misunderstanding within our -community in the cases were our needs and the realities of our situation deviate -from the IETF process. +community in the cases were our practices and the realities of our situation +deviate from the typical IETF I-D process. ## Decision Drivers * IETF's draft versioning system doesn't work for JSON Schema and we stopped - using it to version our releases a while ago. We now use a date based version + using it to version our releases a while ago. We now use date based versioning and even have more than one draft submission per release (the initial release and the patch release). * The IETF process is optimized for working on a draft until it's done and then @@ -52,31 +52,36 @@ from the IETF process. 1. Continue to submit I-Ds, while using our customized process with no intention of pursing standards track RFC status. -2. Get JSON Schema to a stable place and pursue a standards track RFC with the - IETF. -3. Decouple from IETF completely and come up with our own governance model. +2. Go all-in with IETF and pursue a standards track RFC with the IETF. +3. Join W3C and pursue a standards track with them using their process. +4. Decouple completely from any standards organization and come up with our own + specification development lifecycle (SDLC) model inspired by well established + projects with an SDLC that more closely meets or needs. ## Decision Outcome -Our decision is to go with Option 3 and decouple from IETF completely and come -up with our own governance model. The idea of having to come up with our own -governance model is daunting, but when the alternatives are to continue to abuse -the I-D process or to conform to the IETF process that doesn't fit our needs, -going our own way seems the best option. +Our decision is to go with Option 4 and decouple from standards organizations +that don't fit our needs. We don't currently have a plan for what to replace +IETF with. We are currently investigating how other established projects do +their SDLC and will likely choose one to emulate and adapt to our needs. +Although we don't have a replacement solution in place yet, we are confident +that continuing to abuse the IETF I-D process or conforming to a standards +organization process that doesn't fit our needs is not the way to go. ### Positive Consequences * Decoupling from IETF allows us to distance ourselves from the assumptions that people make about JSON Schema because they assume it works like a typical I-D. -* Decoupling from IETF allows us to customize our governance model to what works - best for JSON Schema. +* Decoupling from IETF allows us to customize our SDLC model to what works best + for JSON Schema. ### Negative Consequences -* Choosing our own governance model means we aren't associated with a recognized - standard body which could reduce to credibility of JSON Schema in the eyes of - some. -* If we don't go the standardization route with IETF, we lose access to their - expert review process. -* Defining our own process will be a lot of work and none of use have expertise - in defining such a process. +* Not being associated with a recognized standards organization such as IETF, + W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. +* If we don't go the standardization route with IETF or W3C, we lose access to + their expert review process. +* Defining our own SLDC process will be a lot of work and none of us have + expertise in defining such a process. However, we can take inspiration from + existing well established projects and we would have the freedom to update our + process as we learn what works and what doesn't. From b538730aa0a5e529ae6122aeabf54d0f58f3b883 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Tue, 23 Aug 2022 14:11:36 -0700 Subject: [PATCH 407/780] ADR decouping from IETF draft 3 Incorporating feedback from Henry and Austin. --- adr/2022-08-decouple-from-ietf.md | 65 +++++++++++++++++++++++++++---- 1 file changed, 57 insertions(+), 8 deletions(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index 3ab9eebe..48499d39 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -15,10 +15,14 @@ Related Issues: ## Context and Problem Statement Currently JSON Schema loosely follows the IETF Internet-Draft (I-D) process for -spec development and releases but isn't associated with IETF in any way. Our -perceived involvement with IETF causes confusion and misunderstanding within our -community in the cases were our practices and the realities of our situation -deviate from the typical IETF I-D process. +spec development and releases but isn't associated with any IETF working group. +JSON Schema is an individual draft. That means it isn't on a standards track +with IETF and IETF is not involved nor supports the spec in any way other than +hosting the canonical version of our I-Ds. Our perceived involvement with IETF +causes confusion and misunderstanding within our community in the cases were our +practices and the realities of our situation deviate from a typical IETF I-D +lifecycle. The thing that makes our situation different than a typical I-D is +that our "drafts" are intended for use in production. ## Decision Drivers @@ -46,13 +50,19 @@ deviate from the typical IETF I-D process. * Several members of the JSON Schema team have had poor interactions with IETF and don't feel that working with them would be productive. This is a relatively minor consideration. If we thought IETF was right for JSON Schema, - we could find ways to make those relationships work. + we could find ways to make those relationships work. We have a good + relationship with the relatively new HTTPAPIs working group and working with + them would be far more likely to be productive than the people/WG we were + previously in communication with. ## Considered Options 1. Continue to submit I-Ds, while using our customized process with no intention - of pursing standards track RFC status. -2. Go all-in with IETF and pursue a standards track RFC with the IETF. + of pursing standards track RFC status. +2. Go all-in with IETF and pursue a standards track RFC with the IETF. The + approach would be to describe the essential characteristics of evaluating a + JSON Schema: the keywords that everybody is guaranteed to support, and any + extension mechanisms. 3. Join W3C and pursue a standards track with them using their process. 4. Decouple completely from any standards organization and come up with our own specification development lifecycle (SDLC) model inspired by well established @@ -62,12 +72,45 @@ deviate from the typical IETF I-D process. Our decision is to go with Option 4 and decouple from standards organizations that don't fit our needs. We don't currently have a plan for what to replace -IETF with. We are currently investigating how other established projects do +IETF with, but we are currently investigating how other established projects do their SDLC and will likely choose one to emulate and adapt to our needs. Although we don't have a replacement solution in place yet, we are confident that continuing to abuse the IETF I-D process or conforming to a standards organization process that doesn't fit our needs is not the way to go. +Option 2 and 3 are still on the table if we feel it makes sense when we get to a +more stable place in the future. The main concern is the pain this process is +causing while we are in this unusual phase of simultaneous unstable growth and +production use. Standardization isn't out of the question, it's just not +productive for us to be developing JSON Schema within the constraints of a +standards organizations procedures. + +Option 1 was rejected because it ignores the problems we've been facing and +provides no solution. No one wants this. + +Option 2 was rejected for several reasons. If we go all in with IETF, we would +have to join a working group and treat JSON Schema like a normal I-D. That means +we would have to start treating drafts as drafts, which means not recommending +production use until we are ready for RFC and not releasing a new +production-ready version of JSON Schema until we've reached RFC status. Most of +the core contributors don't believe that we are close enough to an RFC-ready +release that we want to commit to not being able to issue another release until +that happens. + +There are other concerns including skepticism that even with an extension +mechanism that the RFC wouldn't need regular updates, which is not normal +practice for an RFC and would require significant effort to issue a replacing +RFC. Without a concrete proposal on the scope of the RFC and the extension +mechanisms, it's hard to commit to this path. + +Additionally, many of the core contributors have found working with the IETF +unproductive and have concerns about JSON Schema getting deeper involved without +compelling enough reason. Most agree that the reasons are not sufficiently +compelling at this point. + +Option 3 was rejected because it has the same problems as Option 2 accept that +we don't have the same unpleasant history with W3C than we do with IETF. + ### Positive Consequences * Decoupling from IETF allows us to distance ourselves from the assumptions that @@ -79,8 +122,14 @@ organization process that doesn't fit our needs is not the way to go. * Not being associated with a recognized standards organization such as IETF, W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. + However, people seem comfortable adopting OpenAPI without it being associated + with a standards organization, so we don't expect this to be a significant + issue for JSON Schema either. * If we don't go the standardization route with IETF or W3C, we lose access to their expert review process. +* One of the benefits of an RFC is other standards can normatively reference it, + and use JSON Schema to define their JSON-based syntaxes. Independently + publishing a specification does not permit this. * Defining our own SLDC process will be a lot of work and none of us have expertise in defining such a process. However, we can take inspiration from existing well established projects and we would have the freedom to update our From cd373ea983f787f66cc4d5f39623b7e2a2904e98 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Tue, 6 Sep 2022 09:48:41 -0700 Subject: [PATCH 408/780] ADR decouping from IETF draft 4 Include feedback about referencing JSON Schema in other standards without the backing of a recognized standards body. --- adr/2022-08-decouple-from-ietf.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index 48499d39..cdbe2503 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -122,9 +122,10 @@ we don't have the same unpleasant history with W3C than we do with IETF. * Not being associated with a recognized standards organization such as IETF, W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. - However, people seem comfortable adopting OpenAPI without it being associated - with a standards organization, so we don't expect this to be a significant - issue for JSON Schema either. + However, we have received feedback from people involved in standards + development that say they are comfortable adopting OpenAPI without it being + associated with a standards organization, so we don't expect this to be a + significant issue for JSON Schema either. * If we don't go the standardization route with IETF or W3C, we lose access to their expert review process. * One of the benefits of an RFC is other standards can normatively reference it, From 8f44fcce13695443151b76d5884ccdf188a06b67 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Wed, 7 Sep 2022 11:46:38 -0700 Subject: [PATCH 409/780] ADR decoupling from IETF draft 5 Mention OpenJS / Linux Foundation and add Henry as a decider --- adr/2022-08-decouple-from-ietf.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index cdbe2503..c9f6dcca 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -1,7 +1,7 @@ # Decoupling from IETF * Status: accepted -* Deciders: @jdesrosiers @relequestual @awwright +* Deciders: @jdesrosiers @relequestual @awwright @handrews * Date: 2022-08-17 Related Issues: @@ -123,9 +123,12 @@ we don't have the same unpleasant history with W3C than we do with IETF. * Not being associated with a recognized standards organization such as IETF, W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. However, we have received feedback from people involved in standards - development that say they are comfortable adopting OpenAPI without it being - associated with a standards organization, so we don't expect this to be a - significant issue for JSON Schema either. + development that told us that they were comfortable referencing OpenAPI's self + published specification in their standards and that OpenAPI's membership with + the Linux Foundation was an important aspect of what makes them comfortable + doing so. JSON Schema is a member of the OpenJS Foundation, which is a + sub-group of the Linux Foundation, so we expect standards developers to be + just as comfortable referencing JSON Schema as they are referencing OpenAPI. * If we don't go the standardization route with IETF or W3C, we lose access to their expert review process. * One of the benefits of an RFC is other standards can normatively reference it, From a6a70f912c27e58cd09ed29dab81bb57c2777b6e Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 8 Sep 2022 10:02:43 -0700 Subject: [PATCH 410/780] ADR decoupling from IETF draft 6 Feedback from Henry. The main changes are updating the section on our prior experience with IETF and clarifying that our descision not to use IETF doesn't apply to media type registration or supporting components such as Relative JSON Pointer. --- adr/2022-08-decouple-from-ietf.md | 65 ++++++++++++++++++++----------- 1 file changed, 42 insertions(+), 23 deletions(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index c9f6dcca..4b2430a9 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -37,23 +37,30 @@ that our "drafts" are intended for use in production. programming language. When it stops evolving, it will lose its relevance. When we finish a release of JSON Schema, we don't disband, we start work on the next release. -* Every one of our releases is expected to be used in production and will be - depended on for many years forward. This is not consistent with normal IETF - drafts. Even if we don't publicly use the term "draft", we're still using the - IETF I-D system in a way that's not intended. +* Since the project resumed activity after the gap following draft-04, every one + of our releases is expected to be used in production and will be depended on + for many years forward. This is not consistent with normal IETF drafts. Even + if we don't publicly use the term "draft", we're still using the IETF I-D + system in a way that's not intended. * Under IETF, JSON Schema fits under the category of "draft". The community has repeatedly told us that they perceive this to meant that JSON Schema "incomplete" and not "not ready for production use". This is the wrong message for us to be sending as all of our releases are intended to be used in production. This ADR doesn't decide whether or not to drop the "draft" from our releases, but decoupling from IETF gives us that option. -* Several members of the JSON Schema team have had poor interactions with IETF - and don't feel that working with them would be productive. This is a - relatively minor consideration. If we thought IETF was right for JSON Schema, - we could find ways to make those relationships work. We have a good - relationship with the relatively new HTTPAPIs working group and working with - them would be far more likely to be productive than the people/WG we were - previously in communication with. +* Several members of the JSON Schema team have interacted with JSON-related IETF + working groups. Some of these interactions demonstrated an indifference or + hostility to JSON Schema, and a preference for projects taking a different + approach. Equally important was a lack of any active interest or constructive + engagement. Finally, we were informed that any schema project for JSON would + not necessarily start from JSON Schema as a base, indicating that a "JSON + Schema" working group would quite likely not involve JSON Schema itself. This + impression has been reinforced by observing the amount of change introduced to + JSON Path as a consequence of its adoption by an IETF working group. While we + have a good relationship with the relatively new HTTPAPIs working group, the + combination of these other experiences with other mismatches between our + project and the IETF process contributes to our reluctance to move forward + through the iETF. ## Considered Options @@ -78,6 +85,17 @@ Although we don't have a replacement solution in place yet, we are confident that continuing to abuse the IETF I-D process or conforming to a standards organization process that doesn't fit our needs is not the way to go. +However, we still plan to use the IETF process to register the media types +defined by JSON Schema with IANA. This effort is currently in progress with the +HTTPAPIs working group. + +The decision to not use IETF applies only to the main specification documents +and not necessarily supporting components we have defined or will define in the +future. Currently our only such component is Relative JSON Pointer, but there +could be others in the future. These components will be examined on a case by +case basis and we may choose an IETF standards path for those components if it +makes sense. + Option 2 and 3 are still on the table if we feel it makes sense when we get to a more stable place in the future. The main concern is the pain this process is causing while we are in this unusual phase of simultaneous unstable growth and @@ -108,7 +126,7 @@ unproductive and have concerns about JSON Schema getting deeper involved without compelling enough reason. Most agree that the reasons are not sufficiently compelling at this point. -Option 3 was rejected because it has the same problems as Option 2 accept that +Option 3 was rejected because it has the same problems as Option 2 except that we don't have the same unpleasant history with W3C than we do with IETF. ### Positive Consequences @@ -120,20 +138,21 @@ we don't have the same unpleasant history with W3C than we do with IETF. ### Negative Consequences -* Not being associated with a recognized standards organization such as IETF, - W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. - However, we have received feedback from people involved in standards - development that told us that they were comfortable referencing OpenAPI's self - published specification in their standards and that OpenAPI's membership with - the Linux Foundation was an important aspect of what makes them comfortable - doing so. JSON Schema is a member of the OpenJS Foundation, which is a - sub-group of the Linux Foundation, so we expect standards developers to be - just as comfortable referencing JSON Schema as they are referencing OpenAPI. * If we don't go the standardization route with IETF or W3C, we lose access to their expert review process. +* Not being associated with a recognized standards organization such as IETF, + W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. + However, we have received feedback that our membership with OpenJS/Linux + Foundation provides the credibility that we need. * One of the benefits of an RFC is other standards can normatively reference it, - and use JSON Schema to define their JSON-based syntaxes. Independently - publishing a specification does not permit this. + and use JSON Schema to define their JSON-based syntaxes. However, we have + received feedback from people involved in standards development that told us + that they were comfortable referencing OpenAPI's self published specification + in their standards and that OpenAPI's membership with the Linux Foundation was + an important aspect of what makes them comfortable doing so. JSON Schema is a + member of the OpenJS Foundation, which is a sub-group of the Linux Foundation, + so we expect standards developers to be just as comfortable referencing JSON + Schema as they are referencing OpenAPI. * Defining our own SLDC process will be a lot of work and none of us have expertise in defining such a process. However, we can take inspiration from existing well established projects and we would have the freedom to update our From 526c887c43c88534b19143ad0fac67b3e2020e48 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 26 Sep 2022 16:24:05 +0100 Subject: [PATCH 411/780] Add comments about W3C being a pay to play standards org --- adr/2022-08-decouple-from-ietf.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index 4b2430a9..7096d276 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -128,6 +128,15 @@ compelling at this point. Option 3 was rejected because it has the same problems as Option 2 except that we don't have the same unpleasant history with W3C than we do with IETF. +Additionally, the W3C is a "pay to play" standards organization. Organizations +must pay to contribute to specifications the W3C publish, which doesn't match +the JSON Schema Org's open ethos. + +Ben Hutton has had multiple calls with various individuals at different levels +within the W3C, and has a friendly contact should we wish to investigate again +at a later point. The W3C does have an "invited expert" solution for when +a persons employer doesn't want to be a paying member, however this is supposed +to be an exception to the rule, and not frequently used. ### Positive Consequences From d66e49a4ce27089229f41c52426e1914c234490f Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 27 Sep 2022 10:22:24 +0100 Subject: [PATCH 412/780] Add Greg to IETF decouple ADR --- adr/2022-08-decouple-from-ietf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index 7096d276..821591c0 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -1,7 +1,7 @@ # Decoupling from IETF * Status: accepted -* Deciders: @jdesrosiers @relequestual @awwright @handrews +* Deciders: @jdesrosiers @relequestual @awwright @handrews @gregsdennis * Date: 2022-08-17 Related Issues: From 0c9a8a05fa931defb5b4399bf145233efe09f35b Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 27 Sep 2022 10:33:09 +0100 Subject: [PATCH 413/780] Updated date to reflect last update to ADR --- ...2-08-decouple-from-ietf.md => 2022-09-decouple-from-ietf.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename adr/{2022-08-decouple-from-ietf.md => 2022-09-decouple-from-ietf.md} (99%) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-09-decouple-from-ietf.md similarity index 99% rename from adr/2022-08-decouple-from-ietf.md rename to adr/2022-09-decouple-from-ietf.md index 821591c0..f7a190fa 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-09-decouple-from-ietf.md @@ -2,7 +2,7 @@ * Status: accepted * Deciders: @jdesrosiers @relequestual @awwright @handrews @gregsdennis -* Date: 2022-08-17 +* Date: 2022-09-27 Related Issues: * https://github.com/orgs/json-schema-org/discussions/69 - This issue is about From c4aed5eab5ba403e607ce32228a54b123525a8d5 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Sun, 2 Oct 2022 13:52:19 -0700 Subject: [PATCH 414/780] Remove stray empty paragraph. --- jsonschema-core.xml | 2 -- 1 file changed, 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index e5be8bbe..94392427 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -534,8 +534,6 @@ "application/schema+json" document are specified in the "$anchor" keyword section. - -
From ead3d317584f2ad356d2390d77de4fb974eddb33 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Thu, 22 Sep 2022 12:47:33 -0700 Subject: [PATCH 415/780] "minContains"/"maxContains" to applicator vocab This moves the keywords with minamal changes to make sure the cross-referencing (which no longer goes between two documents) makes sense. A subsequent commit will fix the direction of the dependency. --- jsonschema-core.xml | 49 +++++++++++++++++++++++++++++++++- jsonschema-validation.xml | 55 +++++---------------------------------- meta/applicator.json | 9 +++++++ meta/validation.json | 5 ---- 4 files changed, 63 insertions(+), 55 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index c0c7d99d..fa553d95 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2122,7 +2122,7 @@ "contains", whose behavior is affected by the presence and value of - "minContains", in the Validation vocabulary + "minContains" @@ -2502,6 +2502,53 @@
+
+ + The value of this keyword MUST be a non-negative integer. + + + If "contains" is not present within the same schema object, + then this keyword has no effect. + + + An instance array or object is valid against "maxContains" in two ways, + depending on the form of the annotation result of an adjacent + "contains" keyword. The first way is if + the annotation result is an array and the length of that array is less than + or equal to the "maxContains" value. The second way is if the annotation + result is a boolean "true" and the instance length (number of items or + properties) is less than or equal to the "maxContains" value. + +
+ +
+ + The value of this keyword MUST be a non-negative integer. + + + If "contains" is not present within the same schema object, + then this keyword has no effect. + + + An instance array or object is valid against "minContains" in two ways, + depending on the form of the annotation result of an adjacent + "contains" keyword. The first way is if + the annotation result is an array and the length of that array is greater + than or equal to the "minContains" value. The second way is if the + annotation result is a boolean "true" and the instance length (number of + items or properties) is greater than or equal to the "minContains" value. + + + A value of 0 is allowed, but is only useful for setting a range + of occurrences from 0 to the value of "maxContains". A value of + 0 causes "minContains" and "contains" to always pass validation + (but validation can still fail against a "maxContains" keyword). + + + Omitting this keyword has the same behavior as a value of 1. + +
+
The value of this keyword MUST be a valid JSON Schema. diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index a8426471..390231e9 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -404,53 +404,6 @@ Omitting this keyword has the same behavior as a value of false.
- -
- - The value of this keyword MUST be a non-negative integer. - - - If "contains" is not present within the same schema object, - then this keyword has no effect. - - - An instance array or object is valid against "maxContains" in two ways, - depending on the form of the annotation result of an adjacent - "contains" keyword. The first way is if - the annotation result is an array and the length of that array is less than - or equal to the "maxContains" value. The second way is if the annotation - result is a boolean "true" and the instance length (number of items or - properties) is less than or equal to the "maxContains" value. - -
- -
- - The value of this keyword MUST be a non-negative integer. - - - If "contains" is not present within the same schema object, - then this keyword has no effect. - - - An instance array or object is valid against "minContains" in two ways, - depending on the form of the annotation result of an adjacent - "contains" keyword. The first way is if - the annotation result is an array and the length of that array is greater - than or equal to the "minContains" value. The second way is if the - annotation result is a boolean "true" and the instance length (number of - items or properties) is greater than or equal to the "minContains" value. - - - A value of 0 is allowed, but is only useful for setting a range - of occurrences from 0 to the value of "maxContains". A value of - 0 causes "minContains" and "contains" to always pass validation - (but validation can still fail against a "maxContains" keyword). - - - Omitting this keyword has the same behavior as a value of 1. - -
@@ -1368,8 +1321,8 @@
Several keywords have been moved from this document into the - Core Specification as of this draft, in some - cases with re-naming or other changes. This affects the following former + Core Specification starting with draft 2019-09, + in some cases with re-naming or other changes. This affects the following former validation keywords: @@ -1393,6 +1346,10 @@ For this reason, they are better defined as a generic mechanism on which validation, hyper-schema, and extension vocabularies can all be based. + + These keywords modify the behavior of "contains", and are therefore + grouped with it in the applicator vocabulary. + This keyword had two different modes of behavior, which made it relatively challenging to implement and reason about. diff --git a/meta/applicator.json b/meta/applicator.json index 1b2f8c2e..dbc0f68f 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -11,6 +11,11 @@ "properties": { "prefixItems": { "$ref": "#/$defs/schemaArray" }, "items": { "$dynamicRef": "#meta" }, + "maxContains": { "$ref": "#/$defs/nonNegativeInteger" }, + "minContains": { + "$ref": "#/$defs/nonNegativeInteger", + "default": 1 + }, "contains": { "$dynamicRef": "#meta" }, "additionalProperties": { "$dynamicRef": "#meta" }, "properties": { @@ -48,6 +53,10 @@ "not": { "$dynamicRef": "#meta" } }, "$defs": { + "nonNegativeInteger": { + "type": "integer", + "minimum": 0 + }, "schemaArray": { "type": "array", "minItems": 1, diff --git a/meta/validation.json b/meta/validation.json index 69d52e95..cdda94eb 100644 --- a/meta/validation.json +++ b/meta/validation.json @@ -53,11 +53,6 @@ "type": "boolean", "default": false }, - "maxContains": { "$ref": "#/$defs/nonNegativeInteger" }, - "minContains": { - "$ref": "#/$defs/nonNegativeInteger", - "default": 1 - }, "maxProperties": { "$ref": "#/$defs/nonNegativeInteger" }, "minProperties": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, "required": { "$ref": "#/$defs/stringArray" }, From 5c22b3085d3cafc92feb017b9ce1b1f0d5c13522 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Thu, 22 Sep 2022 13:30:36 -0700 Subject: [PATCH 416/780] Reverse contains dependency per Karen Etheridge This fixes the problem where "minContains": 0 effectively un-failed "contains". The observable validation behavior is unchanged. Instead of "minContains" and "maxContains" reading annotations from "contains", "contains" reads annotations from "minContains" and "maxContains" and makes the only assertion decision. This solution was first proposed by Karen Etheridge. --- jsonschema-core.xml | 79 +++++++++++++++++++++------------------------ 1 file changed, 37 insertions(+), 42 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index fa553d95..33fb40fd 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -733,7 +733,7 @@ schema object.
-
+
A missing keyword MUST NOT produce a false assertion result, MUST NOT produce annotation results, and MUST NOT cause any other schema @@ -2507,17 +2507,12 @@ The value of this keyword MUST be a non-negative integer. - If "contains" is not present within the same schema object, - then this keyword has no effect. + This keyword modifies the behavior of "contains" within the same schema object, + as described below in the section for that keyword. - An instance array or object is valid against "maxContains" in two ways, - depending on the form of the annotation result of an adjacent - "contains" keyword. The first way is if - the annotation result is an array and the length of that array is less than - or equal to the "maxContains" value. The second way is if the annotation - result is a boolean "true" and the instance length (number of items or - properties) is less than or equal to the "maxContains" value. + Validation MUST always succeed against this keyword. + The value of this keyword is used as its annotation result.
@@ -2526,26 +2521,17 @@ The value of this keyword MUST be a non-negative integer. - If "contains" is not present within the same schema object, - then this keyword has no effect. + This keyword modifies the behavior of "contains" within the same schema object, + as described below in the section for that keyword. - An instance array or object is valid against "minContains" in two ways, - depending on the form of the annotation result of an adjacent - "contains" keyword. The first way is if - the annotation result is an array and the length of that array is greater - than or equal to the "minContains" value. The second way is if the - annotation result is a boolean "true" and the instance length (number of - items or properties) is greater than or equal to the "minContains" value. + Validation MUST always succeed against this keyword. + The value of this keyword is used as its annotation result. - - A value of 0 is allowed, but is only useful for setting a range - of occurrences from 0 to the value of "maxContains". A value of - 0 causes "minContains" and "contains" to always pass validation - (but validation can still fail against a "maxContains" keyword). - - - Omitting this keyword has the same behavior as a value of 1. + Per section , + omitted keywords MUST NOT produce annotation results. However, as described + in the section for "contains", the absence of this keyword's annotation + causes "contains" to assume a minimum value of 1.
@@ -2554,18 +2540,27 @@ The value of this keyword MUST be a valid JSON Schema. - An array instance is valid against "contains" if at least one of - its elements is valid against the given schema, - except when "minContains" is present and has a value of 0, in which - case an array instance MUST be considered valid against the "contains" keyword, - even if none of its elements is valid against the given schema. + This keyword applies its subschema to array elements or object property values. + + + An instance is valid against "contains" if the number of elements or property + values that are valid against its subschema is with the inclusive range of + the minimum and (if any) maximum number of occurrences. - An object instance is valid against "contains" if at least one of - its properties is valid against the given schema, - except when "minContains" is present and has a value of 0, in which - case an object instance MUST be considered valid against the "contains" keyword, - even if none of its property values is valid against the given schema. + The maximum number of occurrences is provided by the "maxContains" keyword + within the same schema object as "contains". If "maxContains" is absent, + the maximum number of occurrences MUST be unbounded. + + + The minimum number of occurrences is provided by the "minContains" keyword + within the same schema object as "contains". If "minContains" is absent, + the minimum number of occurrences MUST be 1. + + + Implementations MAY implement the dependency on "minContians" and + "maxContains" by inspecting their values rather than reading annotations + produced by those keywords. This keyword produces an annotation value which is an array of the @@ -2578,13 +2573,13 @@ This annotation affects the behavior of "unevaluatedItems" in the - Unevaluated vocabulary, and MAY also be used to implement the - "minContains" and "maxContains" keywords in the Validation vocabulary. + Unevaluated vocabulary. - The subschema MUST be applied to every array element even after the first - match has been found, in order to collect annotations for use by other - keywords. This is to ensure that all possible annotations are collected. + The subschema MUST be applied to every array element or object property + value even after the first match has been found, in order to collect + annotations for use by other keywords. This is to ensure that all possible + annotations are collected.
From 51326f80900357fe3069beb4f5f575db24c1b9a7 Mon Sep 17 00:00:00 2001 From: Julian Berman Date: Tue, 12 Jul 2022 14:15:56 +0200 Subject: [PATCH 417/780] Specify the specific BSD and AFL versions this repo is licensed under. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Historically JSON Schema has declared that contributions are licensed BSD or AFL, without specifying the version of BSD. We’ve been asked to specify a version for work elsewhere in the ecosystem, and OpenJS Foundation counsel recommended BSD 3-clause as the most common choice. This commit clarifies the specific versions (3-clause and v3.0 respectively), and adds a LICENSE file to make this explicit. See https://github.com/json-schema-org/json-schema-spec/issues/1160#issuecomment-1123583441 for the full guidance. Closes: #1160 --- LICENSE | 213 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ README.md | 2 +- 2 files changed, 214 insertions(+), 1 deletion(-) create mode 100644 LICENSE diff --git a/LICENSE b/LICENSE new file mode 100644 index 00000000..7d4605f1 --- /dev/null +++ b/LICENSE @@ -0,0 +1,213 @@ +Copyright (c) 2022 JSON Schema Specification Authors + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are +met: + +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. + +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. + +3. Neither the name of the copyright holder nor the names of its +contributors may be used to endorse or promote products derived from +this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED +TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR +PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF +LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING +NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS +SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +--- + +This Academic Free License (the "License") applies to any original work +of authorship (the "Original Work") whose owner (the "Licensor") has +placed the following licensing notice adjacent to the copyright notice +for the Original Work: + +Licensed under the Academic Free License version 3.0 + +1) Grant of Copyright License. Licensor grants You a worldwide, +royalty-free, non-exclusive, sublicensable license, for the duration of +the copyright, to do the following: + +a) to reproduce the Original Work in copies, either alone or as part of +a collective work; + +b) to translate, adapt, alter, transform, modify, or arrange the +Original Work, thereby creating derivative works ("Derivative Works") +based upon the Original Work; + +c) to distribute or communicate copies of the Original Work and +Derivative Works to the public, under any license of your choice that +does not contradict the terms and conditions, including Licensor's +reserved rights and remedies, in this Academic Free License; + +d) to perform the Original Work publicly; and + +e) to display the Original Work publicly. + +2) Grant of Patent License. Licensor grants You a worldwide, +royalty-free, non-exclusive, sublicensable license, under patent claims +owned or controlled by the Licensor that are embodied in the Original +Work as furnished by the Licensor, for the duration of the patents, to +make, use, sell, offer for sale, have made, and import the Original Work +and Derivative Works. + +3) Grant of Source Code License. The term "Source Code" means the +preferred form of the Original Work for making modifications to it +and all available documentation describing how to modify the Original +Work. Licensor agrees to provide a machine-readable copy of the Source +Code of the Original Work along with each copy of the Original Work +that Licensor distributes. Licensor reserves the right to satisfy this +obligation by placing a machine-readable copy of the Source Code in an +information repository reasonably calculated to permit inexpensive and +convenient access by You for as long as Licensor continues to distribute +the Original Work. + +4) Exclusions From License Grant. Neither the names of Licensor, nor +the names of any contributors to the Original Work, nor any of their +trademarks or service marks, may be used to endorse or promote products +derived from this Original Work without express prior permission of the +Licensor. Except as expressly stated herein, nothing in this License +grants any license to Licensor's trademarks, copyrights, patents, trade +secrets or any other intellectual property. No patent license is granted +to make, use, sell, offer for sale, have made, or import embodiments +of any patent claims other than the licensed claims defined in Section +2. No license is granted to the trademarks of Licensor even if such +marks are included in the Original Work. Nothing in this License shall +be interpreted to prohibit Licensor from licensing under terms different +from this License any Original Work that Licensor otherwise would have a +right to license. + +5) External Deployment. The term "External Deployment" means the use, +distribution, or communication of the Original Work or Derivative +Works in any way such that the Original Work or Derivative Works may +be used by anyone other than You, whether those works are distributed +or communicated to those persons or made available as an application +intended for use over a network. As an express condition for the grants +of license hereunder, You must treat any External Deployment by You of +the Original Work or a Derivative Work as a distribution under section +1(c). + +6) Attribution Rights. You must retain, in the Source Code of any +Derivative Works that You create, all copyright, patent, or trademark +notices from the Source Code of the Original Work, as well as any +notices of licensing and any descriptive text identified therein as an +"Attribution Notice." You must cause the Source Code for any Derivative +Works that You create to carry a prominent Attribution Notice reasonably +calculated to inform recipients that You have modified the Original +Work. + +7) Warranty of Provenance and Disclaimer of Warranty. Licensor warrants +that the copyright in and to the Original Work and the patent rights +granted herein by Licensor are owned by the Licensor or are sublicensed +to You under the terms of this License with the permission of the +contributor(s) of those copyrights and patent rights. Except as +expressly stated in the immediately preceding sentence, the Original +Work is provided under this License on an "AS IS" BASIS and WITHOUT +WARRANTY, either express or implied, including, without limitation, +the warranties of non-infringement, merchantability or fitness for a +particular purpose. THE ENTIRE RISK AS TO THE QUALITY OF THE ORIGINAL +WORK IS WITH YOU. This DISCLAIMER OF WARRANTY constitutes an essential +part of this License. No license to the Original Work is granted by this +License except under this disclaimer. + +8) Limitation of Liability. Under no circumstances and under no legal +theory, whether in tort (including negligence), contract, or otherwise, +shall the Licensor be liable to anyone for any indirect, special, +incidental, or consequential damages of any character arising as a +result of this License or the use of the Original Work including, +without limitation, damages for loss of goodwill, work stoppage, +computer failure or malfunction, or any and all other commercial damages +or losses. This limitation of liability shall not apply to the extent +applicable law prohibits such limitation. + +9) Acceptance and Termination. If, at any time, You expressly +assented to this License, that assent indicates your clear and +irrevocable acceptance of this License and all of its terms and +conditions. If You distribute or communicate copies of the Original +Work or a Derivative Work, You must make a reasonable effort under the +circumstances to obtain the express assent of recipients to the terms +of this License. This License conditions your rights to undertake +the activities listed in Section 1, including your right to create +Derivative Works based upon the Original Work, and doing so without +honoring these terms and conditions is prohibited by copyright law and +international treaty. Nothing in this License is intended to affect +copyright exceptions and limitations (including "fair use" or "fair +dealing"). This License shall terminate immediately and You may no +longer exercise any of the rights granted to You by this License upon +your failure to honor the conditions in Section 1(c). + +10) Termination for Patent Action. This License shall terminate +automatically and You may no longer exercise any of the rights granted +to You by this License as of the date You commence an action, including +a cross-claim or counterclaim, against Licensor or any licensee +alleging that the Original Work infringes a patent. This termination +provision shall not apply for an action alleging patent infringement by +combinations of the Original Work with other software or hardware. + +11) Jurisdiction, Venue and Governing Law. Any action or suit relating +to this License may be brought only in the courts of a jurisdiction +wherein the Licensor resides or in which Licensor conducts its primary +business, and under the laws of that jurisdiction excluding its +conflict-of-law provisions. The application of the United Nations +Convention on Contracts for the International Sale of Goods is +expressly excluded. Any use of the Original Work outside the scope +of this License or after its termination shall be subject to the +requirements and penalties of copyright or patent law in the appropriate +jurisdiction. This section shall survive the termination of this +License. + +12) Attorneys' Fees. In any action to enforce the terms of this License +or seeking damages relating thereto, the prevailing party shall +be entitled to recover its costs and expenses, including, without +limitation, reasonable attorneys' fees and costs incurred in connection +with such action, including any appeal of such action. This section +shall survive the termination of this License. + +13) Miscellaneous. If any provision of this License is held to be +unenforceable, such provision shall be reformed only to the extent +necessary to make it enforceable. + +14) Definition of "You" in This License. "You" throughout this License, +whether in upper or lower case, means an individual or a legal entity +exercising rights under, and complying with all of the terms of, this +License. For legal entities, "You" includes any entity that controls, +is controlled by, or is under common control with you. For purposes of +this definition, "control" means (i) the power, direct or indirect, to +cause the direction or management of such entity, whether by contract +or otherwise, or (ii) ownership of fifty percent (50%) or more of the +outstanding shares, or (iii) beneficial ownership of such entity. + +15) Right to Use. You may use the Original Work in all ways not +otherwise restricted or conditioned by this License or by law, and +Licensor promises not to interfere with or be responsible for such uses +by You. + +16) Modification of This License. This License is Copyright © +2005 Lawrence Rosen. Permission is granted to copy, distribute, or +communicate this License without modification. Nothing in this License +permits You to modify this License as applied to the Original Work or +to Derivative Works. However, You may modify the text of this License +and copy, distribute or communicate your modified version (the "Modified +License") and apply it to other original works of authorship subject +to the following conditions: (i) You may not indicate in any way that +your Modified License is the "Academic Free License" or "AFL" and you +may not use those names in the name of your Modified License; (ii) You +must replace the notice specified in the first paragraph above with +the notice "Licensed under " or with a +notice of your own that is not confusingly similar to the notice in +this License; and (iii) You may not claim that your original works are +open source software unless your Modified License has been approved by +Open Source Initiative (OSI) and You comply with its license review and +certification process. diff --git a/README.md b/README.md index efc5a058..3c100288 100644 --- a/README.md +++ b/README.md @@ -93,4 +93,4 @@ Here are our top sponsors. You could be next! [[Become a sponsor](https://openco ## License -The source material in this repository is licensed under the AFL or BSD license. +The contents of this repository are [licensed under](./LICENSE) either the BSD 3-clause license *or* the Academic Free License v3.0. From 40f4a61148774737dc2583e6a48163bdd15cdc11 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Sun, 21 Aug 2022 13:28:02 -0700 Subject: [PATCH 418/780] Make targets for a virtualenv It's common to make a virtualenv inside of your cloned repo to ensure that you have the right enviornment for that repository, and .venv is a common convention for that virtualenv. This adds targets to create and clean a .venv virtual env using the checked-in requirements.txt file. It also adds the .venv to the .gitignore, and updates the README. --- .gitignore | 3 +++ Makefile | 12 +++++++++++- README.md | 10 +++++++++- 3 files changed, 23 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index 83386b0d..f375fa6e 100644 --- a/.gitignore +++ b/.gitignore @@ -4,3 +4,6 @@ jsonschema-*.txt relative-json-pointer.html relative-json-pointer.pdf relative-json-pointer.txt + +# For the Python enviornment +.venv diff --git a/Makefile b/Makefile index cb7008f7..539a3943 100644 --- a/Makefile +++ b/Makefile @@ -1,11 +1,11 @@ XML2RFC ?= xml2rfc +VENV ?= .venv OUT = \ jsonschema-core.html jsonschema-core.txt \ jsonschema-validation.html jsonschema-validation.txt \ relative-json-pointer.html relative-json-pointer.txt - all: $(OUT) %.txt: %.xml @@ -25,6 +25,16 @@ json-schema.tar.gz: $(OUT) tar -czf json-schema.tar.gz --exclude '.*' json-schema rm -rf json-schema +venv: $(VENV) + +$(VENV): + python -m venv .venv + . .venv/bin/activate && python -m pip install --upgrade pip setuptools wheel + . .venv/bin/activate && python -m pip install -r requirements.txt + +venv-clean: + rm -rf .venv + clean: rm -f $(OUT) json-schema.tar.gz diff --git a/README.md b/README.md index 3c100288..3f2bdc70 100644 --- a/README.md +++ b/README.md @@ -35,7 +35,15 @@ Labels are assigned based on [Sensible Github Labels](https://github.com/Releque * links.json - JSON Hyper-Schema's Link Description Object meta-schema * hyper-schema-output.json - The recommended output format for JSON Hyper-Schema links -Install "xml2rfc" using "pip" (https://pypi.org/project/xml2rfc/) and type "make" at a shell to build the .txt and .html spec files: +The Makefile can create the necessary Python virtual environment for you: + +```sh +make venv +source .venv/bin/activate +make +``` + +Or you can manually install "xml2rfc" using "pip" (https://pypi.org/project/xml2rfc/) and type "make" at a shell to build the .txt and .html spec files: ```sh pip install --requirement requirements.txt From 95d372d17ffdbea8137c2421cf3e8e58c947dc94 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Thu, 8 Sep 2022 23:37:28 -0700 Subject: [PATCH 419/780] Incorporate review feedback. Much better usage of make, incorporate venv into default target and clean target, add a spec-clean target to avoid having to always rebuild the venv. --- Makefile | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/Makefile b/Makefile index 539a3943..ed3923d8 100644 --- a/Makefile +++ b/Makefile @@ -6,7 +6,7 @@ OUT = \ jsonschema-validation.html jsonschema-validation.txt \ relative-json-pointer.html relative-json-pointer.txt -all: $(OUT) +all: $(VENV) $(OUT) %.txt: %.xml $(XML2RFC) --text $< -o $@ @@ -25,17 +25,15 @@ json-schema.tar.gz: $(OUT) tar -czf json-schema.tar.gz --exclude '.*' json-schema rm -rf json-schema -venv: $(VENV) +$(VENV): requirements.txt + python -m venv $@ + $@/bin/python -m pip install --upgrade pip + $@/bin/python -m pip install -r requirements.txt -$(VENV): - python -m venv .venv - . .venv/bin/activate && python -m pip install --upgrade pip setuptools wheel - . .venv/bin/activate && python -m pip install -r requirements.txt - -venv-clean: - rm -rf .venv - -clean: +spec-clean: rm -f $(OUT) json-schema.tar.gz -.PHONY: clean all +clean: spec-clean + rm -rf $(VENV) + +.PHONY: spec-clean clean all From 49ca037ae7034fc9949e5061bbeea711f84a05a7 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Thu, 13 Oct 2022 13:22:10 -0700 Subject: [PATCH 420/780] More feedback. --- Makefile | 2 +- README.md | 15 ++++++--------- 2 files changed, 7 insertions(+), 10 deletions(-) diff --git a/Makefile b/Makefile index ed3923d8..a81ca9b4 100644 --- a/Makefile +++ b/Makefile @@ -28,7 +28,7 @@ json-schema.tar.gz: $(OUT) $(VENV): requirements.txt python -m venv $@ $@/bin/python -m pip install --upgrade pip - $@/bin/python -m pip install -r requirements.txt + $@/bin/python -m pip install -r $< spec-clean: rm -f $(OUT) json-schema.tar.gz diff --git a/README.md b/README.md index 3f2bdc70..ce62c2e1 100644 --- a/README.md +++ b/README.md @@ -35,19 +35,16 @@ Labels are assigned based on [Sensible Github Labels](https://github.com/Releque * links.json - JSON Hyper-Schema's Link Description Object meta-schema * hyper-schema-output.json - The recommended output format for JSON Hyper-Schema links -The Makefile can create the necessary Python virtual environment for you: +The Makefile will create the necessary Python venv for you as part of the regular make target. -```sh -make venv -source .venv/bin/activate -make -``` +`make clean` will remove all output including the venv. To clean just the spec output and +keep the venv, use `make spec-clean`. -Or you can manually install "xml2rfc" using "pip" (https://pypi.org/project/xml2rfc/) and type "make" at a shell to build the .txt and .html spec files: +If you want to run `xml2rfc` manually after running make for the first time, you will +need to activate the virtual environment: ```sh -pip install --requirement requirements.txt -make +source .venv/bin/activate ``` The version of "xml2rfc" that this project uses is updated by modifying `requirements.in` and running `pip-compile requirements.in`. From 923a1526c36f473e0e2ef8252280b7a77f2951fe Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Wed, 12 Oct 2022 13:56:15 -0700 Subject: [PATCH 421/780] Fix a lot of build warnings This gets rid of all of the build warnings except the ones for the lines being too long, which aren't worth trying to fix as we're changing formats anyway. But these are simple fixes to remove everything else. As of RFC 7749 (xml2rfc v2 vocabulary), the RFC 2629 DTD is no longer needed. The submissionType was also added then. It is supposed to default to "IETF" but apparently newer versions of xml2rfc no longer do this. I don't know why xml2rfc did not like the no-breaking space in the xref, but it's happier with it gone. --- jsonschema-core.xml | 4 ++-- jsonschema-validation.xml | 4 ++-- relative-json-pointer.xml | 6 +++--- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 33fb40fd..5a078dc4 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1,5 +1,5 @@ - @@ -22,7 +22,7 @@ - + JSON Schema: A Media Type for Describing JSON Documents diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 390231e9..064af49b 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -1,5 +1,5 @@ - @@ -28,7 +28,7 @@ - + JSON Schema Validation: A Vocabulary for Structural Validation of JSON diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 7d8523d8..e3e93721 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="US-ASCII"?> -<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ +<!DOCTYPE rfc [ <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC6901 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6901.xml"> <!ENTITY RFC8259 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8259.xml"> @@ -12,7 +12,7 @@ <?rfc rfcedstyle="yes"?> <?rfc comments="yes"?> <?rfc inline="yes" ?> -<rfc category="info" docName="draft-bhutton-relative-json-pointer-00" ipr="trust200902"> +<rfc category="info" docName="draft-bhutton-relative-json-pointer-00" ipr="trust200902" submissionType="IETF"> <front> <title abbrev="Relative JSON Pointers">Relative JSON Pointers @@ -107,7 +107,7 @@ where <json-pointer> follows the production defined in - RFC 6901, Section 3 ("Syntax"). + RFC 6901, Section 3 ("Syntax"). From f0eca1cdad9d153cabfdb734bd58968537719b61 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Sat, 24 Sep 2022 13:18:42 -0700 Subject: [PATCH 422/780] Remove annotation-applicator interaction section The idea of annotations and applicators interacting is outdated. Annotation deletion/dropping occurs at the schema object level (clarified in recent drafts), and annotation values have not defined aggregation semantics within JSON Schema evaluation since draft-07. --- jsonschema-core.xml | 7 ------- 1 file changed, 7 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 5a078dc4..b7e6fcff 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1093,13 +1093,6 @@ is kept, as the instance passes the string type assertions.
-
- - In addition to possibly defining annotation results of their own, - applicator keywords aggregate the annotations collected in their - subschema(s) or referenced schema(s). - -
From b83e0925d7a30d2e558421da707b84e9b0e7e835 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Sat, 15 Oct 2022 17:08:48 -0700 Subject: [PATCH 423/780] Further improve applicator interaction language There were more places where some interaction between applicators and annoations were implied. This fixes thos. --- jsonschema-core.xml | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b7e6fcff..4802e29d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -655,8 +655,12 @@ Typically, applicator keywords are processed until a schema object with no applicators (and therefore no subschemas) is reached. The appropriate location in the instance is evaluated against the assertion and - annotation keywords in the schema object, and their results are gathered - into the parent schema according to the rules of the applicator. + annotation keywords in the schema object. The interactions of those + keyword results to produce the schema object results are governed by + section , while the + relationship of subschema results to the results of the applicator + keyword that applied them is described by section + . Evaluation of a parent schema object can complete once all of its @@ -811,10 +815,11 @@ assertion conditions of their own. - Annotation results are - preserved along with the instance location and the location of - the schema keyword, so that applications can decide how to - interpret multiple values. + Annotation results from subschemas + are preserved in accordance with section + so that applications + can decide how to interpret multiple values. Applicator keywords + do not play a direct role in this preservation.
@@ -935,7 +940,7 @@ for failing schemas. -
+
Annotations are collected by keywords that explicitly define annotation-collecting behavior. Note that boolean schemas cannot @@ -1058,7 +1063,7 @@ schema locations.
-
+
Schema objects that produce a false assertion result MUST NOT produce any annotation results, whether from their own keywords From 043105987d7451983a232eff95dd0a0280d185de Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 8 Sep 2022 12:08:43 +1200 Subject: [PATCH 424/780] update output schema to describe new structure --- output/schema.json | 68 +++++++++++++++++++--------------------------- 1 file changed, 28 insertions(+), 40 deletions(-) diff --git a/output/schema.json b/output/schema.json index 72551fc6..b3b80799 100644 --- a/output/schema.json +++ b/output/schema.json @@ -6,18 +6,17 @@ "anyOf": [ { "$ref": "#/$defs/flag" }, { "$ref": "#/$defs/basic" }, - { "$ref": "#/$defs/detailed" }, - { "$ref": "#/$defs/verbose" } + { "$ref": "#/$defs/hierarchical" } ], "$defs": { "outputUnit":{ "properties": { "valid": { "type": "boolean" }, - "keywordLocation": { + "evaluationPath": { "type": "string", "format": "json-pointer" }, - "absoluteKeywordLocation": { + "schemaLocation": { "type": "string", "format": "uri" }, @@ -25,56 +24,38 @@ "type": "string", "format": "json-pointer" }, - "error": { - "type": "string" - }, - "errors": { + "nested": { "$ref": "#/$defs/outputUnitArray" }, "annotations": { - "$ref": "#/$defs/outputUnitArray" + "type": "object", + "additionalProperties": true + }, + "errors": { + "type": "object", + "additionalProperties": { "type": "string" } } }, - "required": [ "valid", "keywordLocation", "instanceLocation" ], + "required": [ "valid", "evaluationPath", "schemaLocation", "instanceLocation" ], "allOf": [ { "if": { + "required": [ "errors" ] + }, + "then": { "properties": { "valid": { "const": false } } - }, - "then": { - "anyOf": [ - { - "required": [ "error" ] - }, - { - "required": [ "errors" ] - } - ] } }, { "if": { - "anyOf": [ - { - "properties": { - "keywordLocation": { - "pattern": "/\\$ref/" - } - } - }, - { - "properties": { - "keywordLocation": { - "pattern": "/\\$dynamicRef/" - } - } - } - ] + "required": [ "annotations" ] }, "then": { - "required": [ "absoluteKeywordLocation" ] + "properties": { + "valid": { "const": true } + } } } ] @@ -89,8 +70,15 @@ }, "required": [ "valid" ] }, - "basic": { "$ref": "#/$defs/outputUnit" }, - "detailed": { "$ref": "#/$defs/outputUnit" }, - "verbose": { "$ref": "#/$defs/outputUnit" } + "basic": { + "properties": { + "valid": { "type": "boolean" }, + "nested": { + "$ref": "#/$defs/outputUnitArray" + } + }, + "required": [ "valid", "nested" ] + }, + "hierarchical": { "$ref": "#/$defs/outputUnit" } } } From ac54fdf1788223595875f79e0ad414de410dc9e8 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Sat, 15 Oct 2022 16:24:04 -0700 Subject: [PATCH 425/780] Delete hyper-schema after move to own repo These files (with their revision history at both this location and their pre-archive locations) now live in json-schema-org/json-hyperschema-spec It seems better to just delete these than to prune the whole history as Hyper-Schema was released from this repo in the past. Also update README which didn't quite reflect reality anyway. --- README.md | 3 - archive/hyper-schema.json | 28 - archive/jsonschema-hyperschema.xml | 2828 ---------------------------- archive/links.json | 93 - archive/meta/hyper-schema.json | 30 - output/hyper-schema.json | 62 - 6 files changed, 3044 deletions(-) delete mode 100644 archive/hyper-schema.json delete mode 100644 archive/jsonschema-hyperschema.xml delete mode 100644 archive/links.json delete mode 100644 archive/meta/hyper-schema.json delete mode 100644 output/hyper-schema.json diff --git a/README.md b/README.md index ce62c2e1..58007547 100644 --- a/README.md +++ b/README.md @@ -31,9 +31,6 @@ Labels are assigned based on [Sensible Github Labels](https://github.com/Releque * relative-json-pointer.xml - source for the Relative JSON Pointer I-D * _meta-schemas and recommended output formats_ * schema.json - JSON Schema "core" and Validation meta-schema - * hyper-schema.json - JSON Hyper-Schema meta-schema - * links.json - JSON Hyper-Schema's Link Description Object meta-schema - * hyper-schema-output.json - The recommended output format for JSON Hyper-Schema links The Makefile will create the necessary Python venv for you as part of the regular make target. diff --git a/archive/hyper-schema.json b/archive/hyper-schema.json deleted file mode 100644 index 7558b6f3..00000000 --- a/archive/hyper-schema.json +++ /dev/null @@ -1,28 +0,0 @@ -{ - "$comment": "This file represents a work in progress and may not be a complete or valid 2019-09 / 2020-12 schema or vocabulary", - "$schema": "https://json-schema.org/draft/2019-09/hyper-schema", - "$id": "https://json-schema.org/draft/2019-09/hyper-schema", - "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/core": true, - "https://json-schema.org/draft/2019-09/vocab/applicator": true, - "https://json-schema.org/draft/2019-09/vocab/unevaluated": true, - "https://json-schema.org/draft/2019-09/vocab/validation": true, - "https://json-schema.org/draft/2019-09/vocab/meta-data": true, - "https://json-schema.org/draft/2019-09/vocab/format": false, - "https://json-schema.org/draft/2019-09/vocab/content": true, - "https://json-schema.org/draft/2019-09/vocab/hyper-schema": true - }, - "$dynamicAnchor": "meta", - - "title": "JSON Hyper-Schema", - "allOf": [ - {"$ref": "https://json-schema.org/draft/2019-09/schema"}, - {"$ref": "https://json-schema.org/draft/2019-09/meta/hyper-schema"} - ], - "links": [ - { - "rel": "self", - "href": "{+%24id}" - } - ] -} diff --git a/archive/jsonschema-hyperschema.xml b/archive/jsonschema-hyperschema.xml deleted file mode 100644 index 78997685..00000000 --- a/archive/jsonschema-hyperschema.xml +++ /dev/null @@ -1,2828 +0,0 @@ - - - - - - - - - - - - - - - - -]> - - - - - - - - - - - - JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON - - - -
- andrews_henry@yahoo.com -
- - - -
- aaa@bzfx.net -
- - - - Internet Engineering Task Force - JSON - Schema - JavaScript - Object - Notation - Hyper Schema - Hypermedia - - - - JSON Schema is a JSON-based format for describing JSON data using various - vocabularies. This document specifies a vocabulary for annotating JSON - documents with hyperlinks. These hyperlinks include attributes describing - how to manipulate and interact with remote resources through hypermedia - environments such as HTTP, as well as determining whether the link is usable - based on the instance value. The hyperlink serialization format described in - this document is also usable independent of JSON Schema. - - - - - The issues list for this draft can be found at - . - - - For additional information, see - . - - - To provide feedback, use this issue tracker, the communication methods listed on the - homepage, or email the document editors. - - - - - -
- - JSON Hyper-Schema is a JSON Schema vocabulary for annotating JSON documents - with hyperlinks and instructions for processing and - manipulating remote JSON resources through hypermedia environments such as HTTP. - - - The term JSON Hyper-Schema is used to refer to a JSON Schema that uses these - keywords. The term "hyper-schema" on its own refers to a JSON Hyper-Schema - within the scope of this specification. - - - The primary mechanism introduced for specifying links is the Link Description - Object (LDO), which is a serialization of the abstract link model - defined in RFC 8288, section 2. - - - This specification will use the concepts, syntax, and terminology defined by the - JSON Schema core and - JSON Schema validation specifications. - It is advised that readers have a copy of these specifications. - -
- -
- - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", - "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be - interpreted as described in RFC 2119. - -
- -
- - JSON Hyper-Schema makes it possible to build hypermedia systems from JSON - documents by describing how to construct hyperlinks from instance data. - - - The combination of a JSON instance document and a valid application/schema+json - hyper-schema for that instance behaves as a single hypermedia representation. - By allowing this separation, hyper-schema-based systems can gracefully support - applications that expect plain JSON, while providing full hypermedia capabilities - for hyper-schema-aware applications and user agents. - - - User agents can detect the presence of hyper-schema by looking for - the application/schema+json media type and a "$schema" value that indicates the - presence of the hyper-schema vocabulary. A user agent can then use an - implementation of JSON Hyper-Schema to provide an interface to the - combination of the schema and instance documents as a single logical - representation of a resource, just as with any single-document hypermedia - representation format. - - - Hyper-schemas allow representations to take up fewer bytes on the wire, and - distribute the burden of link construction from the server to each client. - A user agent need not construct a link unless a client application requests - that link. JSON Hyper-Schema can also be used on the server side to generate - other link serializations or representation formats at runtime, or pre-emptively - follow links to facilitate server push usage. - -
- - Here is an example hyper-schema that adds a single link, with the - IANA-registered link relation type "self", that is built from an instance - with one known object field named "id": - - - - - - If the instance is {"id": 1234}, and its base URI according to - RFC 3986 section 5.1, is - "https://example.com/api/", then "https://example.com/api/thing/1234" - is the resulting link's target URI. - -
- -
- - The terms "schema", "instance", and "meta-schema" are to be interpreted as - defined in the JSON Schema core specification. - - - The terms "applicable" and "attached" are to be interpreted as defined in - Section 3.1 of the - JSON Schema core specification. - - - The terms "link", "link context" (or "context"), "link target" (or "target"), - and "target attributes" are to be interpreted as defined in - Section 2 of RFC 8288. - - - The term "user agent" is to be interpreted as defined in - Section 2.1 of RFC 7230, generalized to apply - to any protocol that may be used in a hypermedia system rather than - specifically being an HTTP client. - - - This specification defines the following terms: - - - A JSON Schema using the keywords defined by this specification. - - - Within this document, the term "hyper-schema" always refers to - a JSON Hyper-Schema - - - A valid link for an instance is one that is applicable to that - instance and does not fail any requirement imposed by the keywords - in the Link Description Object. Note that invalid links can - occur when using keywords such as "if" or "oneOf" (from the - Core specification) to describe links that are conditional on - the representation's structure or value. - - - A user agent which can be used to interact with any resource, from - any server, from among the standardized link relations, media types, - URI schemes, and protocols that it supports; though it may be - extendible to specially handle particular profiles of media types. - - - An application which uses a hypermedia system for a specific - purpose. Such an application may also be its own user agent, - or it may be built on top of a generic user agent. A client - application is programmed with knowledge of link relations, - media types, URI schemes, protocols, and data structures that - are specific to the application's domain. - - - Data provided through a user agent, and most often also through - a client application. Such data may be requested from a user - interactively, or provided before interaction in forms such as - command-line arguments, configuration files, or hardcoded values - in source code. - - - A specific use of a hyperlink, such as making a network request - (for a URI with a scheme such as "http://" that indicates a protocol) - or otherwise taking action based on a link (reading data from a - "data:" URI, or constructing an email message based on a "mailto:" - link). For protocols such as HTTP that support multiple methods, - each method is considered to be a separate operation on the same link. - - - -
- -
- - A JSON Hyper-Schema implementation is able to take a hyper-schema, an - instance, and in some cases client input, and produce a set of fully - resolved valid links. As defined by - RFC 8288, section 2, - a link consists of a context, a typed relation, a target, and optionally - additional target attributes. - - - The relation type and target attributes are taken directly from each link's - Link Description Object. The context and target identifiers are constructed - from some combination of URI Templates, instance data, and (in the case - of the target identifier) client input. - - - The target is always fully identified by a URI. Due to the lack of a URI - fragment identifier syntax for application/json and many other media types - that can be used with JSON Hyper-Schema, the context may be only partially - identified by a URI. In such cases, the remaining identification will be - provided as a JSON Pointer. - - - A few IANA-registered link relation types are given specific semantics in - a JSON Hyper-Schema document. A "self" link is used to interact with the - resource that the instance document represents, while "collection" and - "item" links identify resources for which collection-specific semantics - can be assumed. - -
-
- -
- - The current URI for the JSON Hyper-Schema meta-schema is - . - - - The current URI for this vocabulary, known as the Hyper-Schema vocabulary, is: - <https://json-schema.org/draft/2019-09/vocab/hyper-schema>. - - - The current URI for the corresponding meta-schema, which differs from the - convenience meta-schema above in that it describes only the hyper-schema - keywords ("base" and "link") is: - . - - - The link description format can be used without JSON - Schema, and use of this format can be declared by referencing the normative - link description schema as the schema for the data structure that uses the links. - The URI of the normative link description schema is: - . - - - JSON Hyper-Schema implementations are free to provide output in any format. - However, a specific format is defined for use in the conformance test suite, - which is also used to illustrate points in the - "Implementation Requirements", and to - show the output generated by examples. - It is RECOMMENDED that implementations be capable of producing output - in this format to facilitated testing. The URI of the JSON Schema - describing the recommended output format is - . - - - Updated vocabulary and meta-schema URIs MAY be published between - specification drafts in order to correct errors. Implementations - SHOULD consider URIs dated after this specification draft and - before the next to indicate the same syntax and semantics - as those listed here. - -
-
- - Hyper-schema keywords from all schemas that are applicable to a position - in an instance, as defined by Section - 3.1 of JSON Schema core, can be used with that instance. - - - When multiple subschemas are applicable to a given sub-instance, all "link" - arrays MUST be combined, in any order, into a single set. Each object - in the resulting set MUST retain its own list of applicable "base" values, - in resolution order, from the same schema and any parent schemas. - - - As with all JSON Schema keywords, all keywords described in this section - are optional. The minimal valid JSON Hyper-schema is the blank object. - - -
- - If present, this keyword MUST be first resolved as - a URI Template, and then MUST be resolved as a URI Reference against the - current URI base of the instance. The result MUST be set as the new URI - base for the instance while processing the sub-schema containing "base" - and all sub-schemas within it. - - - The process for resolving the "base" template can be different when being - resolved for use with "anchor" than when being resolved for use with "href", - which is explained in detail in the URI Templating section. - -
- -
- - The "links" property of schemas is used to associate Link Description Objects - with instances. The value of this property MUST be an array, and the items in - the array must be Link Description Objects, as defined below. - -
-
- -
- - A Link Description Object (LDO) is a serialization of the abstract link model - defined in RFC 8288, section 2. - As described in that document, a link consists of a context, a relation type, - a target, and optionally target attributes. JSON Hyper-Schema's LDO provides - all of these, along with additional features using JSON Schema to describe input - for use with the links in various ways. - - - Due to the use of URI Templates to identify link contexts and targets, as well - as optional further use of client input when identifying targets, an LDO is - a link template that may resolve to multiple links when used with a JSON - instance document. - - - A specific use of an LDO, typically involving a request and response across - a protocol, is referred to as an operation. For many protocols, multiple - operations are possible on any given link. The protocol is indicated by - the target's URI scheme. Note that not all URI schemes indicate a protocol - that can be used for communications, and even resources with URI schemes that - do indicate such protocols need not be available over that protocol. - - - A Link Description Object MUST be an object, and the - "href" and "rel" properties - MUST be present. Each keyword is covered briefly in this section, with additional - usage explanation and comprehensive examples given later in the document. - - -
- - In JSON Hyper-Schema, the link's context resource is, by default, the - sub-instance to which it is attached (as defined by - Section 3.1 of the JSON Schema - core specification). This is often not the entire instance - document. This default context can be changed using the keywords - in this section. - - - Depending on the media type of the instance, it may or may not be possible - to assign a URI to the exact default context resource. In particular, - application/json does not define a URI fragment resolution syntax, so - properties or array elements within a plain JSON document cannot be fully - identified by a URI. When it is not possible to produce a complete URI, - the position of the context SHOULD be conveyed by the URI of the instance - document, together with a separate plain-string JSON Pointer. - - - Implementations MUST be able to construct the link context's URI, and - (if necessary for full identification), a JSON Pointer in string representation - form as per RFC 6901, section 5 in place of - a URI fragment. The process for constructing a URI based on a URI template - is given in the URI Templating section. - -
- - This property sets the context URI of the link. - The value of the property is a URI Template, - and the resulting URI-reference MUST - be resolved against the base URI of the instance. - - - The URI is computed from the provided URI template using the same process - described for the "href" property, with the - exception that "hrefSchema" MUST NOT - be applied. Unlike target URIs, context URIs do not accept user input. - -
-
- - This property changes the point within the instance that is considered - to be the context resource of the link. The value of the property MUST - be a valid JSON Pointer in JSON String representation form, or a valid - Relative JSON Pointer - which is evaluated relative to the default context. - - - While an alternate context with a known URI is best set with the - "anchor" keyword, the lack of a fragment - identifier syntax for application/json means that it is usually not - possible to change the context within a JSON instance using a URI. - - - Even in "+json" media types that define JSON Pointer as a fragment - identifier syntax, if the default context is nested within an array, - it is not possible to obtain the index of the default context's position - in that array in order to construct a pointer to another property in that - same nested JSON object. This will be demonstrated in the examples. - - - The result of processing this keyword SHOULD be a URI fragment if the - media type of the instance allows for such a fragment. Otherwise it - MUST be a string-encoded JSON Pointer. - -
-
-
- - The link's relation type identifies its semantics. It is the primary - means of conveying how an application can interact with a resource. - - - Relationship definitions are not normally media type - dependent, and users are encouraged to utilize the most - suitable existing accepted relation definitions. - -
- - The value of this property MUST be either a string or - an array of strings. If the value is an array, - it MUST contain at least one string. - - - Each string MUST be a single Link Relation Type as defined - in RFC 8288, Section 2.1, including the restriction that - additional semantics SHOULD NOT be inferred based upon the - presence or absence of another link relation type. - - - This property is required. - -
-
- - A "self" link, as originally defined by Section - 4.2.7.2 of RFC 4287, indicates that the target URI identifies - a resource equivalent to the link context. In JSON Hyper-Schema, - a "self" link MUST be resolvable from the instance, and therefore - "hrefSchema" MUST NOT be present. - - - Hyper-schema authors SHOULD use "templateRequired" to ensure that the - "self" link has all instance data that is needed for use. - - - A hyper-schema implementation MUST recognize that a link with relation - type "self" that has the entire current instance document as its context - describes how a user agent can interact with the resource represented by - that instance document. - -
-
- - RFC 6573 defines and registers - the "item" and "collection" link relation types. JSON Hyper-Schema imposes - additional semantics on collection resources indicated by these types. - - - Implementations MUST recognize the target of a "collection" link and - the context of an "item" link as collections. - - - A well-known design pattern in hypermedia is to use a collection resource - to create a member of the collection and give it a server-assigned URI. - If the protocol indicated by the URI scheme defines a specific method - that is suited to creating a resource with a server-assigned URI, then - a collection resource, as identified by these link relation types, - MUST NOT define semantics for that method that conflict with the semantics - of creating a collection member. Collection resources MAY implement - item creation via such a protocol method, and user agents MAY assume - that any such operation, if it exists, has item creation semantics. - - - As such a method would correspond to JSON Hyper-Schema's data submission - concept, the "submissionSchema" - field for the link SHOULD be compatible with the schema of the - representation of the collection's items, as indicated by the "item" link's - target resource or the "self" link of the "collection" link's context - resource. - -
-
- - When no registered relation (aside from "related") applies, users are - encouraged to mint their own extension relation types, as described in - section 2.1.2 of RFC 8288. The simplest - approaches for choosing link relation type URIs are to either use - a URI scheme that is already in use to identify the system's primary - resources, or to use a human-readable, non-dereferenceable URI scheme - such as "tag", defined by RFC 4151. - - - Extension relation type URIs need not be dereferenceable, even when - using a scheme that allows it. - -
-
-
- - The target URI template is used to identify the link's target, potentially - making use of instance data. Additionally, with - "hrefSchema", this template can identify - a set of possible target resources to use based on client input. - The full process of resolving the URI template, with or without client - input, is covered in the URI Templating - section. - -
- - The value of the "href" link description property is a template used to - determine the target URI of the related resource. - The value of the instance property MUST be resolved as a - URI-reference against the base URI of the - instance. - - - This property is REQUIRED. - -
-
- -
- - The keywords in this section are used when resolving all URI Templates - involved in hyper-schema: "base", "anchor", and "href". See the - URI Templating section for the complete - template resolution algorithm. - - - Note that when resolving a "base" template, the attachment point from - which resolution begins is the attachment point of the "href" or "anchor" - keyword being resolved which requires "base" templates to be resolved, - not the attachment point of the "base" keyword itself. - -
- - The value of the "templatePointers" link description property MUST be - an object. Each property value in the object MUST be a valid - JSON Pointer, or a valid - Relative JSON Pointer - which is evaluated relative to the attachment point of the link - for which the template is being resolved. - - - For each property name in the object that matches a variable name in the - template being resolved, the value of that property adjusts the starting - position of variable resolution for that variable. Properties which - do not match template variable names in the template being resolved - MUST be ignored. - -
-
- - The value of this keyword MUST be an array, and the elements MUST be unique. - Each element SHOULD match a variable in the link's URI Template, without - percent-encoding. After completing the entire URI Template resolution - process, if any variable that is present in this array does not have - a value, the link MUST NOT be used. - -
-
- -
- - All properties in this section are advisory only. While keywords such - as "title" and "description" are used primarily to present the link - to users, those keywords that predict the nature of a link interaction - or response MUST NOT be considered authoritative. The runtime behavior - of the target resource MUST be respected whenever it conflicts with - the target attributes in the LDO. - -
- - This property defines a title for the link. - The value MUST be a string. - - - - User agents MAY use this title when presenting the link to the user. - -
- -
- - This property provides additional information beyond what - is present in the title. The value MUST be a string. - While a title is preferably short, a description can be - used to go into more detail about the purpose and usage - of the link. - - - - User agents MAY use this description when presenting - the link to the user. - -
- -
- - The value of this property represents the media type - RFC 2046, that is expected to be returned - when fetching this resource. This property value MAY be a media range - instead, using the same pattern defined in - RFC 7231, section 5.3.2 - - HTTP "Accept" header. - - - This property is analogous to the "type" property of other link - serialization formats. User agents MAY use this information to inform - the interface they present to the user before the link is followed, - but MUST NOT use this information in the interpretation of the resulting - data. Instead, a user agent MUST use the media type given by the response - for run-time interpretation. See the section on - "Security Concerns" for a detailed - examination of mis-use of "targetMediaType". - - - For protocols supporting content-negotiation, implementations MAY choose to - describe possible target media types using protocol-specific information in - "headerSchema". If both - protocol-specific information and "targetMediaType" are present, then the - value of "targetMediaType" MUST be compatible with the protocol-specific - information, and SHOULD indicate the media type that will be returned in the - absence of content negotiation. - - - When no such protocol-specific information is available, or when the - implementation does not recognize the protocol involved, then the value - SHOULD be taken to be "application/json". - -
- -
- - This property provides a schema that is expected to describe - the link target's representation. Depending on the protocol, - the schema may or may not describe the request or response to - any particular operation performed with the link. See the - JSON Hyper-Schema and HTTP section for - an in-depth discussion of how this keyword is used with HTTP. - -
- -
- - - This section attempts to strike a balance between comprehensiveness - and flexibility by deferring most of its structure to the protocol - indicated by the URI scheme. Note that a resource can be identified - by a URI with a dereferenceable scheme, yet not be accessible over - that protocol. While currently very loose, this section is expected - to become more well-defined based on draft feedback, and may change - significantly in future drafts. - - - - The value of this property is advisory only. It represents information that - is expected to be discoverable through interacting with the target resource, - typically in the form of protocol-specific control information or meta-data - such as headers returned in response to an HTTP HEAD or OPTIONS request. - The protocol is determined by the "href" URI scheme, although note that - resources are not guaranteed to be accessible over such a protocol. - - - The value of this property SHOULD be an object. The keys to this object - SHOULD be lower-cased forms of the control data field names. Each value - SHOULD be an array, in order to uniformly handle multi-valued fields. - Multiple values MUST be presented as an array, and not as a single string. - - - Protocols with control information not suitable for representation as - a JSON object MAY be represented by another data type, such as an array. - - - Values that cannot be understood as part of the indicated protocol MUST - be ignored by a JSON Hyper-Schema implementation. Applications MAY make - use of such values, but MUST NOT assume interoperability with other - implementations. - - - Implementations MUST NOT assume that all discoverable information is - accounted for in this object. Client applications MUST properly handle - run-time responses that contradict this property's values. - - - Client applications MUST NOT assume that an implementation will - automatically take any action based on the value of this property. - - - See "JSON Hyper-Schema and HTTP" for - guidance on using this keyword with HTTP and analogous protocols. - -
-
-
- - There are four ways to use client input with a link, and each - is addressed by a separate link description object keyword. When performing - operations, user agents SHOULD ignore schemas that are not relevant to their - semantics. - -
- - The value of the "hrefSchema" link description property MUST be - a valid JSON Schema. This schema is used to validate user input - or other user agent data for filling out the URI Template in - "href". - - - Omitting "hrefSchema" or setting the entire schema to "false" prevents - any user agent data from being accepted. - - - Setting any subschema that applies to a particular variable to the - JSON literal value "false" prevents any user agent data from being - accepted for that single variable. - - - For template variables that can be resolved from the instance data, - if the instance data is valid against all applicable subschemas - in "hrefSchema", then it MUST be used to pre-populate the input - data set for that variable. - - - Note that even when data is pre-populated from the instance, the - validation schema for that variable in "hrefSchema" need not be identical - to the validation schema(s) that apply to the instance data's location. - This allows for different validation rules for user agent data, such as - supporting spelled-out months for date-time input, but using the standard - date-time format for storage. - - - After input is accepted, potentially overriding the pre-populated - instance data, the resulting data set MUST successfully validate - against the value of "hrefSchema". If it does not then the link - MUST NOT be used. If it is valid, then the process given in the - "URI Templating" section continues with this updated data set. - -
- -
- - - As with "targetHints", this keyword is somewhat under-specified - to encourage experimentation and feedback as we try to balance - flexibility and clarity. - - - - If present, this property is a schema for protocol-specific request - headers or analogous control and meta-data. The value of this - object MUST be a valid JSON Schema. - The protocol is determined by the "href" URI scheme, although note that - resources are not guaranteed to be accessible over such a protocol. - The schema is advisory only; the target resource's behavior is not - constrained by its presence. - - - The purpose of this keyword is to advertise target resource interaction - features, and indicate to user agents and client applications what headers - and header values are likely to be useful. - User agents and client applications MAY use the schema to validate relevant - headers, but MUST NOT assume that missing headers or values are forbidden - from use. While schema authors MAY set "additionalProperties" to - false, this is NOT RECOMMENDED and MUST NOT prevent client applications - or user agents from supplying additional headers when requests are made. - - - The exact mapping of the JSON data model into the headers is - protocol-dependent. However, in most cases this schema SHOULD - specify a type of "object", and the property names SHOULD be - lower-cased forms of the control data field names. As with - "targetHints", the values SHOULD be described as arrays to - allow for multiple values, even if only one value is expected. - - - See the "JSON Hyper-Schema and HTTP" section - for detailed guidance on using this keyword with HTTP and - analogous protocols. - - - "headerSchema" is applicable to any request method or command that the - protocol supports. When generating a request, user agents and client - applications SHOULD ignore schemas for headers that are not relevant - to that request. - -
- -
- - In JSON Hyper-Schema, "targetSchema" - supplies a non-authoritative description of the target resource's - representation. A client application can use "targetSchema" to structure - input for replacing or modifying the representation, or as the base - representation for building a patch document based on a patch media type. - - - Alternatively, if "targetSchema" is absent or if the client application - prefers to only use authoritative information, it can interact with the - target resource to confirm or discover its representation structure. - - - "targetSchema" is not intended to describe link operation responses, - except when the response semantics indicate that it is a representation - of the target resource. In all cases, the schema indicated by the response - itself is authoritative. See - "JSON Hyper-Schema and HTTP" for detailed - examples. - -
- -
- - The "submissionSchema" and - "submissionMediaType" keywords - describe the domain of the processing function implemented by the target - resource. Otherwise, as noted above, the submission schema and media type - are ignored for operations to which they are not relevant. - - -
- - If present, this property indicates the media type format the - client application and user agent should use for the request - payload described by - "submissionSchema". - - - Omitting this keyword has the same behavior as a value of - application/json. - - - Note that "submissionMediaType" and "submissionSchema" - are not restricted to HTTP URIs. - This statement might move to wherever the example ends up. - -
- -
- - This property contains a schema which defines the acceptable structure - of the document to be encoded according to the "submissionMediaType" - property and sent to the target resource for processing. This can be - viewed as describing the domain of the processing function implemented - by the target resource. - - - This is a separate concept from the - "targetSchema" property, which - describes the target information resource (including for replacing the - contents of the resource in a PUT request), unlike "submissionSchema" - which describes the user-submitted request data to be evaluated by the - resource. "submissionSchema" is intended for use with requests that - have payloads that are not necessarily defined in terms of the target - representation. - - - Omitting "submissionSchema" has the same behavior as a value of "true". - -
-
-
-
- -
- - At a high level, a conforming implementation will meet the following - requirements. Each of these requirements is covered in more detail in the - individual keyword sections and keyword group overviews. - - - Note that the requirements around how an implementation MUST recognize - "self", "collection", and "item" links are thoroughly covered in the - link relation type section and are not - repeated here. - - - While it is not a mandatory format for implementations, the output format used - in the test suite summarizes what needs to be computed for each link before - it can be used: - - - The fully resolved URI (with scheme) of the context resource. If - the context is not the entire resource and there is a usable fragment - identifier syntax, then the URI includes a fragment. Note that there - is no such syntax for application/json. - - - The JSON Pointer for the location within the instance of the context - resource. If the instance media type supports JSON Pointers as fragment - identifiers, this pointer will be the same as the one encoded in the - fragment of the "contextUri" field. - - - The link relation type. When multiple link relation types appear - in the LDO, for the purpose of producing output, they are to be - treated as multiple LDOs, each with a single link relation type - but otherwise identical. - - - The fully resolved URI (with a scheme) of the target resource. If the - link accepts input, this can only be produced once the input has been - supplied. - - - The list of partially resolved URI references for a link that accepts - input. The first entry in the list is the partially resolved "href". - The additional entries, if any, are the partially resolved "base" values - ordered from the most immediate out to the root of the schema. - Template variables that are pre-populated in the input are not resolved - at this stage, as the pre-populated value can be overridden. - - - The data set that the user agent should use to prepopulate any - input mechanism before accepting client input. If input is to be - accepted but no fields are to be pre-populated, then this will be - an empty object. - - - The JSON Pointer for the location within the instance to which the - link is attached. By default, "contextUri" and "attachmentPointer" are - the same, but "contextUri" can be changed by LDO keywords, while - "attachmentPointer" cannot. - - - Other LDO keywords that are not involved in producing the above information - are included exactly as they appear when producing output for the test suite. - Those fields will not be further discussed here unless specifically relevant. - - -
- - Before links can be used, they must be discovered by applying the hyper-schema - to the instance and finding all applicable and valid links. Note that in - addition to collecting valid links, any "base" - values necessary to resolve each LDO's URI Templates must also be located - and associated with the LDO through whatever mechanism is most useful for - the implementation's URI Template resolution process. - - - And implementation MUST support looking up links by either their - attachment pointer or context pointer, either by performing the look-up - or by providing the set of all links with both pointers determined - so that user agents can implement the look-up themselves. - - - When performing look-ups by context pointer, links that are attached to - elements of the same array MUST be returned in the same order as the - array elements to which they are attached. - -
- -
- - Three hyper-schema keywords are URI Templates: - "base", "anchor", and "href". Each are resolved separately to URI-references, - and then the anchor or href URI-reference is resolved against the base (which - is itself resolved against earlier bases as needed, each of which was first - resolved from a URI Template to a URI-reference). - - - All three keywords share the same algorithm for resolving variables from - instance data, which makes use of the "templatePointers" and "templateRequired" - keywords. When resolving "href", both it and any "base" templates - needed for resolution to an absolute URI, the algorithm is modified to - optionally accept user input based on the "hrefSchema" keyword. - - - For each URI Template (T), the following pseudocode describes an algorithm for - resolving T into a URI-reference (R). For the purpose of this algorithm: - - - "ldo.templatePointers" is an empty object if the keyword was not - present and "ldo.templateRequired" is likewise an empty array. - - - "attachmentPointer" is the absolute JSON Pointer for the attachment - location of the LDO. - - - "getApplicableSchemas()" returns an iterable set of all (sub)schemas - that apply to the attachment point in the instance. - - - - - This algorithm should be applied first to either "href" or "anchor", - and then as needed to each successive "base". The order is important, - as it is not always possible to tell whether a template will resolve - to a full URI or a URI-reference. - - - In English, the high-level algorithm is: - - Populate template variable data from the instance - If input is desired, accept input - Check that all required variables have a value - Encode values into strings and fill out the template - - -
- - This is the high-level algorithm as pseudocode. "T" comes from either - "href" or "anchor" within the LDO, or from "base" in a containing schema. - Pseudocode for each step follows. "initialTemplateKeyword" indicates - which of the two started the process (since "base" is always resolved - in order to finish resolving one or the other of those keywords). - - - - -
- -
- - This step looks at various locations in the instance for variable values. - For each variable: - - - Use "templatePointers" to find a value if the variable - appears in that keyword's value - - - Otherwise, look for a property name matching the variable in - the instance location to which the link is attached - - - In either case, if there is a value at the location, put it in - the template resolution data set - - - -
- - - -
-
- -
- - This step is relatively complex, as there are several cases to support. - Some variables will forbid input and some will allow it. Some will - have initial values that need to be presented in the input interface, - and some will not. - - - - - Determine which variables can accept input - - - Pre-populate the input data set if the template resolution data - set has a value - - - Accept input (present a web form, make a callback, etc.) - - - Validate the input data set, (not the template resolution data set) - - - Put the input in the template resolution data set, overriding - any existing values - - - -
- - "InputForm" represents whatever sort of input mechanism is appropriate. - This may be a literal web form, or may be a more programmatic construct - such as a callback function accepting specific fields and data types, - with the given initial values, if any. - - - - -
-
- -
- - This section is straightforward, converting literals to their names - as strings, and converting numbers to strings in the most obvious manner, - and percent-encoding as needed for use in the URI. - -
- - - - - In some software environments the original JSON representation of a - number will not be available (there is no way to tell the difference - between 1.0 and 1), so any reasonable representation should be used. - Schema and API authors should bear this in mind, and use other types - (such as string or boolean) if the exact representation is - important. If the number was provide as input in the form of a - string, the string used as input SHOULD be used. - -
-
-
- -
- - For a given link, an implementation MUST make the values of all - target attribute keywords directly available to the user agent. - Implementations MAY provide additional interfaces for using this - information, as discussed in each keyword's section. - - - For a given link, an implementation MUST make the value of each - input schema keyword directly available to the user agent. - - - To encourage encapsulation of the URI Template resolution process, - implementations MAY omit the LDO keywords that are used only to - construct URIs. However, implementations MUST provide access to - the link relation type. - - - Unrecognized keywords SHOULD be made available to the user agent, - and MUST otherwise be ignored. - -
- -
- - A hyper-schema implementation SHOULD provide access to all information - needed to construct any valid request to the target resource. - - - The LDO can express all information needed to perform any operation on - a link. This section explains what hyper-schema fields a user agent - should examine to build requests from any combination of instance data - and client input. A hyper-schema implementation is not itself expected - to construct and send requests. - - - Target URI construction rules, including "hrefSchema" for accepting input, - are identical for all possible requests. - - - Requests that do not carry a body payload do not require additional keyword - support. - - - Requests that take a target representation as a payload SHOULD use the - "targetSchema" and "targetMediaType" keywords for input description and - payload validation. If a protocol allows an operation taking a payload - that is based on the representation as modified by a media type - (such as a patch media type), then such a media type SHOULD be indicated - through "targetHints" in a protocol-specific manner. - - - Requests that take a payload that is not derived from the target resource's - representation SHOULD use the "submissionSchema" and "submissionMediaType" - keywords for input description and payload validation. Protocols used in - hypermedia generally only support one such non-representation operation - per link. - - - RPC systems that pipe many application operations with arbitrarily different - request structures through a single hypermedia protocol operation are outside - of the scope of a hypermedia format such as JSON Hyper-Schema. - -
- -
- - As a hypermedia format, JSON Hyper-Schema is concerned with describing - a resource, including describing its links in sufficient detail to make - all valid requests. It is not concerned with directly describing all - possible responses for those requests. - - - As in any hypermedia system, responses are expected to be self-describing. - In the context of hyper-schema, this means that each response MUST link - its own hyper-schema(s). While responses that consist of a representation - of the target resource are expected to be valid against "targetSchema" - and "targetMediaType", those keywords are advisory only and MUST be - ignored if contradicted by the response itself. - - - Other responses, including error responses, complex redirections, and - processing status representations SHOULD also link to their own schemas - and use appropriate media types - (e.g. "application/problem+json" for errors). - Certain errors might not link a schema due to being generated by an - intermediary that is not aware of hyper-schema, rather than by the origin. - - - User agents are expected to understand protocol status codes and response - media types well enough to handle common situations, and provide enough - information to client applications to handle domain-specific responses. - - - Statically mapping all possible responses and their schemas at design time - is outside of the scope of JSON Hyper-Schema, but may be within the scope - of other JSON Schema vocabularies which build on hyper-schema - (see ). - -
- -
- - The requirements around discovering links based on their context, or - using the context of links to identify collections, present unique - challenges when used with streaming parsers. It is not possible to - authoritatively fulfill these requirements without processing the entire - schema and instance documents. - - - Such implementations MAY choose to return non-authoritative answers - based on data processed to date. When offering this approach, - implementations MUST be clear on the nature of the response, and MUST - offer an option to block and wait until all data is processed and - an authoritative answer can be returned. - -
-
- -
- - While JSON Hyper-Schema is a hypermedia format and therefore protocol-independent, - it is expected that its most common use will be in HTTP systems, or systems - using protocols such as CoAP that are explicitly analogous to HTTP. - - - This section provides guidance on how to use each common HTTP method with a link, - and how collection resources impose additional constraints on HTTP POST. - Additionally, guidance is provided on hinting at HTTP response header values and - describing possible HTTP request headers that are relevant to the given resource. - - - Section 13 of the JSON Schema core specification - provides guidance on linking instances in a hypermedia system to their schemas. - This may be done with network-accessible schemas, or may simply identify schemas - which were pre-packaged within the client application. JSON Hyper-Schema - intentionally does not constrain this mechanism, although it is RECOMMENDED that - the techniques outlined in the core specification be used to whatever extent - is possible. - -
- - Link Description Objects do not directly indicate what operations, such - as HTTP methods, are supported by the target resource. Instead, operations - should be inferred primarily from link relation types - and URI schemes. - - - This means that for each target resource and link relation type pair, schema - authors SHOULD only define a single LDO. While it is possible to use - "allow" with "targetHints" to repeat a relation type and target pair with - different HTTP methods marked as allowed, this is NOT RECOMMENDED and may - not be well-supported by conforming implementations. - - - All information necessary to use each HTTP method can be conveyed in a - single LDO as explained in this section. The "allow" field in "targetHints" - is intended simply to hint at which operations are supported, not to - separately define each operation. - - - Note, however, that a resource may always decline an operation at runtime, - for instance due to authorization failure, or due to other application state - that controls the operation's availability. - -
-
- - "targetSchema" describes the resource on the target end of the link, while - "targetMediaType" defines that resource's media type. With HTTP links, - "headerSchema" can also be used to describe valid values for use in an - "Accept" request header, which can support multiple media types or - media ranges. When both ways of indicating the target media type are - present, "targetMediaType" SHOULD indicate the default representation - media type, while the schema for "accept" in "headerSchema" SHOULD include - the default as well as any alternate media types or media ranges that can - be requested. - - - Since the semantics of many HTTP methods are defined in terms of the target - resource, "targetSchema" is used for requests and/or responses for several - HTTP methods. In particular, "targetSchema" suggests what a client - application can expect for the response to an HTTP GET or any response - for which the "Content-Location" header is equal to the request URI, - and what a client application should send if it creates or replaces - the resource with an HTTP PUT request. - These correlations are defined by RFC 7231, - section 4.3.1 - "GET", section 4.3.4 "PUT", and section 3.1.4.2, - "Content-Location". - - - Per RFC 5789, the request structure for an HTTP - PATCH is determined by the combination of "targetSchema" and the request - media type, which is conveyed by the "Accept-Patch" header, which may be - included in "targetHints". Media types that are suitable for PATCH-ing - define a syntax for expressing changes to a document, which can be applied - to the representation described by "targetSchema" to determine the set of - syntactically valid request payloads. Often, the simplest way to validate - a PATCH request is to apply it and validate the result as a normal - representation. - -
-
- - JSON Hyper-Schema allows for resources that process arbitrary data - in addition to or instead of working with the target's representation. - This arbitrary data is described by the "submissionSchema" and - "submissionMediaType" keywords. In the case of HTTP, the POST method - is the only one that handles such data. While there are certain - conventions around using POST with collections, the semantics of a POST - request are defined by the target resource, not HTTP. - - - In addition to the protocol-neutral "submission*" keywords (see - for a non-HTTP example), the "Accept-Post" header - can be used to specify the necessary media type, and MAY be - advertised via the "targetHints" field. - - What happens if both are used? Also, "submissionSchema" is a MUST - to support, while "targetHints" are at most a SHOULD. But forbidding - the use of "Accept-Post" in "targetHints" seems incorrect. - - - - Successful responses to POST other than a 201 or a 200 with "Content-Location" - set likewise have no HTTP-defined semantics. As with all HTTP responses, - any representation in the response should link to its own hyper-schema to - indicate how it may be processed. As noted in , - connecting hyperlinks with all possible operation responses is not within - the scope of JSON Hyper-Schema. - -
-
- - It would be good to also include a section with CoAP examples. - - - JSON serializations of HTTP response header information SHOULD follow the - guidelines established by the work in progress - "A JSON Encoding for HTTP Header Field Values". - Approaches shown in that document's examples SHOULD be applied to other - similarly structured headers wherever possible. - - - Headers for all possible HTTP method responses all share "headerSchema". - In particular, both headers that appear in a HEAD response and those - that appear in an OPTIONS response can appear. No distinction is made - within "headerSchema" as to which method response contains which header. - - - It is RECOMMENDED that schema authors provide hints for the values of - the following types of HTTP headers whenever applicable: - - Method allowance - Method-specific request media types - Authentication challenges - - - - In general, headers that are likely to have different values at different - times SHOULD NOT be included in "targetHints". - -
- - As an example, an Allow header allowing HEAD, GET, and POST - would be shown as follows: - - - - - - Note that this is represented identically whether there is - a single-line Allow header with comma-separated values, - multiple Allow headers on separate lines, each with one value, - or any combination of such arrangements. As is generally true - with HTTP headers, comma-separated values and multiple occurrences - of the header are treated the same way. - -
-
-
- - Schemas SHOULD be written to describe JSON serializations that - follow guidelines established by the work in progress - "A JSON Encoding for HTTP Header Field Values" - Approaches shown in that document's examples SHOULD be applied to - other similarly structured headers wherever possible. - - - It is RECOMMENDED that schema authors describe the available usage of - the following types of HTTP headers whenever applicable: - - Content negotiation - Authentication and authorization - Range requests - The "Prefer" header - - - - Headers such as cache control and conditional request headers are generally - implemented by intermediaries rather than the resource, and are therefore - not generally useful to describe. While the resource must supply the - information needed to use conditional requests, the runtime handling of - such headers and related responses is not resource-specific. - -
-
- - When using HTTP, or a protocol such as CoAP that is explicitly analogous - to HTTP, this is done by POST-ing a representation of the individual - resource to be created to the collection resource. The process for - recognizing collection and item resources is described in - . - -
-
- - JSON Hyper-Schema facilitates HTTP content negotiation, and allows for - a hybrid of the proactive and reactive strategies. As mentioned - above, a hyper-schema can include a schema for HTTP headers such as - "Accept", "Accept-Charset", "Accept-Language", etc with the "headerSchema" - keyword. A user agent or client application can use information in - this schema, such as an enumerated list of supported languages, in lieu of - making an initial request to start the reactive negotiation process. - - - In this way, the proactive content negotiation technique of setting these - headers can be informed by server information about what values are - possible, similar to examining a list of alternatives in reactive negotiation. - - - For media types that allow specifying a schema as a media type parameter, - the "Accept" values sent in a request or advertised in "headerSchema" can - include the URI(s) of the schema(s) to which the negotiated representation - is expected to conform. One possible use for schema parameters in - content negotiation is if the resource has conformed to several different - schema versions over time. The client application can indicate what version(s) - it understands in the "Accept" header in this way. - -
-
- -
- - This section shows how the keywords that construct URIs and JSON Pointers - are used. The results are shown in the format used by the test suite. - - Need to post that and link it, but it should be pretty self-explanatory - to those of you reviewing things at this stage. - - - Most other keywords are either straightforward ("title" and "description"), - apply validation to specific sorts of input, requests, or responses, or have - protocol-specific behavior. Examples demonstrating HTTP usage are available - in an Appendix. - - -
- - For this example, we will assume an example API with a documented - entry point URI of https://example.com/api, which is an empty JSON object - with a link to a schema. Here, the entry point has no data of its - own and exists only to provide an initial set of links: - -
- -; rel="describedBy" -{} -]]> - -
- - The linked hyper-schema defines the API's base URI and provides - two links: an "about" link to API documentation, and a "self" - link indicating that this is a schema for the base URI. - -
- - - -
- - These are the simplest possible links, with only a relation type and - an "href" with no template variables. They resolve as follows: - - - The duplication of "api" in both the base and the "../api" - href in the "self" link is due to quirks of the RFC 3986 - URI-reference resolution algorithm. In order for relative - URI-references to work well in general, the base URI needs - to include a trailing slash. The "about" link with its "docs" - href shows the common case of relative references, which is - used in the other examples in this document. - - - However, if an API uses URIs without trailing slashes for its resources, - there is no way to provide a relative reference that just removes a - trailing slash without duplicating the path component above it. - Which makes the case of the entry point resource, which differs - from the base URI only in terms of the trailing slash, somewhat awkward. - - - Resource URIs, of course, may have trailing slashes, but this example - is intended to highlight this frequently confusing special case. - -
- - - -
- - The attachment pointer is the root pointer (the only possibility with - an empty object for the instance). The context URI is the default, - which is the requested document. Since application/json does not allow - for fragments, the context pointer is necessary to fully describe the - context. Its default behavior is to be the same as the attachment pointer. - -
-
- - Let's add "things" to our system, starting with an individual thing: - -
- - - -
- - Our "thing" has a server-assigned id, which is required in order to - construct the "self" link. It also has a "data" field which can be - of any type. The reason for the "$defs" section will be clear - in the next example. - - - Note that "id" is not required by the validation schema, but is required - by the self link. This makes sense: a "thing" only has a URI if it has - been created, and the server has assigned an id. However, you can use - this schema with an instance containing only the data field, which allows - you to validate "thing" instances that you are about to create. - - - Let's add a link to our entry point schema that lets you jump directly - to a particular thing if you can supply it's id as input. To save space, - only the new LDO is shown. Unlike "self" and "about", there is no - IANA-registered relationship about hypothetical things, so an extension - relationship is defined using the - "tag:" URI scheme: - -
- - - -
- - The "href" value here is the same, but everything else is different. - Recall that the instance is an empty object, so "id" cannot be resolved - from instance data. Instead it is required as client input. This LDO - could also have used "templateRequired" but with "required" in "hrefSchema" - it is not strictly necessary. Providing "templateRequired" without marking - "id" as required in "hrefSchema" would lead to errors, as client input - is the only possible source for resolving this link. - -
-
- - This example covers using the "submission" fields for non-representation - input, as well as using them alongside of resolving the URI Template with - input. Unlike HTML forms, which require either constructing a URI or - sending a payload, but do not allow not both at once, JSON Hyper-Schema can - describe both sorts of input for the same operation on the same link. - - - The "submissionSchema" and "submissionMediaType" fields are for - describing payloads that are not representations of the target resource. - When used with "http(s)://" URIs, they generally refer to a POST request - payload, as seen in the appendix on HTTP usage. - - - In this case, we use a "mailto:" URI, which, per - RFC 6068, Section 3", does not provide any - operation for retrieving a resource. It can only be used to construct - a message for sending. Since there is no concept of a retrievable, - replaceable, or deletable target resource, "targetSchema" and - "targetMediaType" are not used. Non-representation payloads are - described by "submissionSchema" and "submissionMediaType". - - - We use "submissionMediaType" to indicate a multipart/alternative - payload format, providing two representations of the same data (HTML and - plain text). Since a multipart/alternative message is an ordered sequence - (the last part is the most preferred alternative), we model the sequence as - an array in "submissionSchema". Since each part is itself a document with - a media type, we model each item in the array as a string, using - "contentMediaType" to indicate the format within the string. - - - Note that media types such as multipart/form-data, which associate a name with - each part and are not ordered, should be modeled as JSON objects rather than - arrays. - -
- - Note that some lines are wrapped to fit this document's width restrictions. - - - - -
- - For the URI parameters, each of the three demonstrates a different way of - resolving the input: - - - This variable's presence in "templateRequired" means that it must be - resolved for the template to be used. Since the "false" schema - assigned to it in "hrefSchema" excludes it from the input data set, - it must be resolved from the instance. - - - The instance field matching this variable is required, and it is also - allowed in the input data. So its instance value is used to - pre-populate the input data set before accepting client input. The - client application can opt to leave the instance value in place. Since - this field is required in "hrefSchema", the client application cannot - delete it (although it could set it to an empty string). - - - The "false" schema set for this in the main schema prevents this field - from having an instance value. If it is present at all, it must come - from client input. As it is not required in "hrefSchema", it may not - be used at all. - - - - - So, given the following instance retrieved from "https://example.com/api/stuff": - -
- - - -
- - We can partially resolve the link as follows, before asking the client - application for input. - -
- - - -
- - Notice the "href*" keywords in place of "targetUri". These are three - possible kinds of "targetUri" values covering different sorts of input. Here - are examples of each: - - - "mailto:someone@example.com?subject=The%20Awesome%20Thing" - - - "mailto:someone@example.com?subject=your%20work" - - - "mailto:someone@example.com?subject=your%20work&cc=other@elsewhere.org" - - - -
-
- - A link is a typed connection from a context resource to a target resource. - Older link serializations support a "rev" keyword that takes a link relation - type as "rel" does, but reverses the semantics. This has long been deprecated, - so JSON Hyper-Schema does not support it. Instead, "anchor"'s ability to - change the context URI can be used to reverse the direction of a link. - It can also be used to describe a link between two resources, neither of - which is the current resource. - - - As an example, there is an IANA-registered "up" relation, but - there is no "down". In an HTTP Link header, you could implement - "down" as "rev": "up". - -
- - First let's look at how this could be done in HTTP, showing a "self" - link and two semantically identical links, one with "rev": "up" - and the other using "anchor" with "rel": "up" (line wrapped due to - formatting limitations). - - -; rel="self" -Link: ; rel="up"; - anchor="https://example.com/api/trees/1/nodes/456" -Link: ; rev="up" -{ - "id": 123, - "treeId": 1, - "childIds": [456] -} -]]> - - - Note that the "rel=up" link has a target URI identical - to the "rel=self" link, and sets "anchor" (which identifies - the link's context) to the child's URI. This sort of reversed - link is easily detectable by tools when a "self" link is also present. - -
- -
- - The following hyper-schema, applied to the instance in the response - above, would produce the same "self" link and "up" link with "anchor". - It also shows the use of a templated "base" URI, plus both absolute - and relative JSON Pointers in "templatePointers". - - - - - - The "base" template is evaluated identically for both the - target ("href") and context ("anchor") URIs. - -
- - Note the two different sorts of templatePointers used. - "thisNodeId" is mapped to an absolute JSON Pointer, "/id", - while "childId" is mapped to a relative pointer, "0", which - indicates the value of the current item. Absolute - JSON Pointers do not support any kind of wildcarding, so - there is no way to specify a concept like "current item" - without a relative JSON Pointer. - -
-
- - In many systems, individual resources are grouped into collections. Those - collections also often provide a way to create individual item resources with - server-assigned identifiers. - -
- - For this example, we will re-use the individual thing schema as - shown in an earlier section. It is repeated here for convenience, - with an added "collection" link with a "targetSchema" reference - pointing to the collection schema we will introduce next. - - - - - - The "collection" link is the same for all items, so there are no - URI Template variables. The "submissionSchema" is that of the - item itself. As described in , - if a "collection" link supports a submission mechanism (POST in HTTP) - then it MUST implement item creation semantics. Therefore - "submissionSchema" is the schema for creating a "thing" via this link. - -
-
- - Now we want to describe collections of "thing"s. - This schema describes a collection where each item representation is - identical to the individual "thing" representation. While many - collection representations only include subset of the item - representations, this example uses the entirety to minimize the - number of schemas involved. The actual collection items appear as - an array within an object, as we will add more fields to the object - in the next example. - - - - -
-
- - Here is a simple two-element collection instance: - - - - -
-
- - Here are all of the links that apply to this instance, - including those that are defined in the referenced individual - "thing" schema: - - - - - - - In all cases, the context URI is shown for - an instance of media type application/json, which does not - support fragments. If the instance media type was - application/instance+json, which supports JSON Pointer fragments, - then the context URIs would contain fragments identical to - the context pointer field. For application/json and other media types - without fragments, it is critically important to consider the context - pointer as well as the context URI. - -
- - There are three "self" links, one for the collection, and one for - each item in the "elements" array. The item "self" links are defined - in the individual "thing" schema which is referenced with "$ref". - The three links can be distinguished by their context or attachment - pointers. We will revisit the "submissionSchema" of the collection's - "self" link in . - - - There are two "item" links, one for each item in the "elements" array. - Unlike the "self" links, these are defined only in the collection schema. - Each of them have the same target URI as the corresponding "self" link that - shares the same attachment pointer. However, each has a different context - pointer. The context of the "self" link is the entry in "elements", - while the context of the "item" link is always the entire collection - regardless of the specific item. - - - Finally, there are two "collection" links, one for each item in "elements". - In the individual item schema, these produce links with the item resource - as the context. When referenced from the collection schema, the context - is the location in the "elements" array of the relevant "thing", rather than - that "thing"'s own separate resource URI. - - - The collection links have identical target URIs as there is only one relevant - collection URI. While calculating both links as part of a full set of - constructed links may not seem useful, when constructing links on an as-needed - basis, this arrangement means that there is a "collection" link definition - close at hand no matter which "elements" entry you are processing. - -
-
- - Here we add pagination to our collection. There is a "meta" section - to hold the information about current, next, and previous pages. - Most of the schema is the same as in the previous section and has been - omitted. Only new fields and new or (in the case of the main "self" - link) changed links are shown in full. - - - - - - Notice that the "self" link includes the pagination query - that produced the exact representation, rather than being - a generic link to the collection allowing selecting the - page via input. - -
-
- - Given this instance: - - - - -
-
- - Here are all of the links that apply to this instance - that either did not appear in the previous example or - have been changed with pagination added. - - - - - - Note that there is no "prev" link in the output, as we are looking - at the first page. The lack of a "prev" field under "meta", - together with the "prev" link's "templateRequired" values, means - that the link is not usable with this particular instance. - -
- - - It's not clear how pagination should work with the link from - the "collection" links in the individual "thing" schema. - Technically, a link from an item to a paginated or filtered - collection should go to a page/filter that contains the item - (in this case the "thing") that is the link context. - See GitHub issue #421 for more discussion. - - - - Let's add a link for this collection to the entry point schema - (), including - pagination input in order to allow client applications to jump directly - to a specific page. Recall that the entry point schema consists only - of links, therefore we only show the newly added link: - -
- - - - - Now we see the pagination parameters being accepted as input, so - we can jump to any page within the collection. The link relation - type is a custom one as the generic "collection" link can only - be used with an item as its context, not an entry point or other - resource. - -
-
-
- - When we do not have any "thing"s, we do not have any resources with - a relevant "collection" link. Therefore we cannot use a "collection" - link's submission keywords to create the first "thing"; hyper-schemas - must be evaluated with respect to an instance. Since the "elements" - array in the collection instance would be empty, it cannot provide - us with a collection link either. - - - However, our entry point link can take us to the empty collection, and - we can use the presence of "item" links in the hyper-schema to recognize - that it is a collection. Since the context of the "item" link is the - collection, we simply look for a "self" link with the same context, which - we can then treat as collection for the purposes of a creation operation. - - - Presumably, our custom link relation type in the entry point schema was - sufficient to ensure that we have found the right collection. A client - application that recognizes that custom link relation type may know that - it can immediately assume that the target is a collection, but a generic - user agent cannot do so. Despite the presence of a "-collection" suffix - in our example, a generic user agent would have no way of knowing whether - that substring indicates a hypermedia resource collection, or some other - sort of collection. - - - Once we have recognized the "self" link as being for the correct collection, - we can use its "submissionSchema" and/or "submissionMediaType" keywords to - perform an item creation operation. - - This works perfectly if the collection is unfiltered and unpaginated. - However, one should generally POST to a collection that will contain - the created resource, and a "self" link MUST include any filters, - pagination, or other query parameters. Is it still valid to POST to - such a "self" link even if the resulting item would not match the - filter or appear within that page? See GitHub issue #421 for further - discussion. - - - Draft-04 of Hyper-Schema defined a "create" link relation that - had the schema, rather than the instance, as its context. This - did not fit into the instance-based link model, and incorrectly - used an operation name for a link relation type. However, defining - a more correctly designed link from the schema to the collection - instance may be one possible approach to solving this. - Again, see GitHub issue #421 for more details. - - -
-
-
- -
- - JSON Hyper-Schema defines a vocabulary for JSON Schema core and concerns all - the security considerations listed there. As a link serialization format, - the security considerations of RFC 8288 Web Linking - also apply, with appropriate adjustments (e.g. "anchor" as an LDO keyword rather - than an HTTP Link header attribute). - -
- - As stated in , all LDO keywords describing - the target resource are advisory and MUST NOT be used in place of - the authoritative information supplied by the target resource in response - to an operation. Target resource responses SHOULD indicate their own - hyper-schema, which is authoritative. - - - If the hyper-schema in the target response matches (by "$id") the hyper-schema - in which the current LDO was found, then the target attributes MAY be - considered authoritative. - - Need to add something about the risks of spoofing by "$id", but given - that other parts of the specification discourage always re-downloading - the linked schema, the risk mitigation options are unclear. - - - - User agents or client applications MUST NOT use the value of "targetSchema" - to aid in the interpretation of the data received in response to following - the link, as this leaves - "safe" data open to re-interpretation. - - - When choosing how to interpret data, the type information provided by the - server (or inferred from the filename, or any other usual method) MUST be - the only consideration, and the "targetMediaType" property of the link - MUST NOT be used. - User agents MAY use this information to determine how they represent the - link or where to display it (for example hover-text, opening in a new tab). - If user agents decide to pass the link to an external program, they SHOULD - first verify that the data is of a type that would normally be passed to - that external program. - - - This is to guard against re-interpretation of "safe" data, similar to the - precautions for "targetSchema". - - - Protocol meta-data values conveyed in "targetHints" MUST NOT be considered - authoritative. Any security considerations defined by the protocol that - may apply based on incorrect assumptions about meta-data values apply. - - - Even when no protocol security considerations are directly applicable, - implementations MUST be prepared to handle responses that do not - match the link's "targetHints" values. - -
-
- - When link relation of "self" is used to denote a full representation of an - object, the user agent SHOULD NOT consider the representation to be the - authoritative representation of the resource denoted by the target URI if - the target URI is not equivalent to or a sub-path of the URI used to request - the resource representation which contains the target URI with the "self" - link. - - It is no longer entirely clear what was intended by the "sub-path" - option in this paragraph. It may have been intended to allow - "self" links for embedded item representations in a collection, which - usually have target URIs that are sub-paths of that collection's URI, - to be considered authoritative. However, this is simply a common - design convention and does not appear to be based in RFC 3986 or any other - guidance on URI usage. See GitHub issue #485 for further discussion. - - -
-
- -
- - Thanks to - Gary Court, - Francis Galiegue, - Kris Zyp, - and Geraint Luff - for their work on the initial drafts of JSON Schema. - - - Thanks to - Jason Desrosiers, - Daniel Perrett, - Erik Wilde, - Ben Hutton, - Evgeny Poberezkin, - Brad Bowman, - Gowry Sankar, - Donald Pipowitch, - Dave Finlay, - and Denis Laxalde - for their submissions and patches to the document. - -
- - - - - - &rfc2119; - &rfc3986; - &rfc4287; - &rfc6570; - &rfc6573; - &rfc6901; - &rfc8288; - - - Relative JSON Pointers - - - - - - - - - - - - - JSON Schema: A Media Type for Describing JSON Documents - - - - - - - - - - - - - JSON Schema Validation: A Vocabulary for Structural Validation of JSON - - - - - - - - - - - - - - - - &rfc2046; - &rfc4151; - &rfc5789; - &rfc6068; - &rfc7230; - &rfc7231; - &rfc7807; - &I-D.reschke-http-jfv; - -
- - Hypermedia APIs, which follow the constraints of the REST architectural - style, enable the creation of generic user agents. Such a user agent - has no application-specific knowledge. Rather, it understands pre-defined - media types, URI schemes, protocols, and link relations, often by recognizing - these and coordinating the use of existing software that implements support - for them. Client applications can then be built on top of such a user agent, - focusing on their own semantics and logic rather than the mechanics of the - interactions. - - - Hyper-schema is only concerned with one resource and set of associated links - at a time. Just as a web browser works with only one HTML page at a time, - with no concept of whether or how that page functions as part of a "site", - a hyper-schema-aware user agent works with one resource at a time, without - any concept of whether or how that resource fits into an API. - - - Therefore, hyper-schema is suitable for use within an API, but is not suitable - for the description of APIs as complete entities in their own right. There is - no way to describe concepts at the API scope, rather than the resource and - link scope, and such descriptions are outside of the boundaries - of JSON Hyper-Schema. - -
- - Since a given JSON Hyper-Schema is used with a single resource at a single - point in time, it has no inherent notion of versioning. However, a given - resource can change which schema or schemas it uses over time, and the - URIs of these schemas can be used to indicate versioning information. - When used with a media type that supports indicating a schema with a media - type parameter, these versioned schema URIs can be used in content negotiation. - - - A resource can indicate that it is an instance of multiple schemas, which allows - supporting multiple compatible versions simultaneously. A client application - can then make use of the hyper-schema that it recognizes, and ignore newer - or older versions. - -
-
- - Because a hyper-schema represents a single resource at a time, it does not - provide for an enumeration of all possible responses to protocol operations - performed with links. Each response, including errors, is considered - its own (possibly anonymous) resource, and should identify its own - hyper-schema, and optionally use an appropriate media type such as - RFC 7807's "application/problem+json", - to allow the user agent or client application to interpret any - information that is provided beyond the protocol's own status reporting. - -
-
- - It is possible to statically analyze a set of hyper-schemas without instance - data in order to generate output such as documentation or code. However, - the full feature set of both validation and hyper-schema cannot be accessed - without runtime instance data. - - - This is an intentional design choice to provide the maximum runtime - flexibility for hypermedia systems. JSON Schema as a media type allows for - establishing additional vocabularies for static analysis and content - generation, which are not addressed in this specification. Additionally, - individual systems may restrict their usage to subsets that can be - analyzed statically if full design-time description is a goal. - - Vocabularies for API documentation and other purposes have been - proposed, and contributions are welcome at - https://github.com/json-schema-org/json-schema-vocabularies - - -
-
- -
- - This section to be removed before leaving Internet-Draft status. - - - - - - Allow multiple values for "rel" - Clarify that "headerSchema", like "targetHints", should use array values - Clarified link behavior with conditional applicator keywords such as "if" - Added and clarified various examples - Avoid accidentally implying that only POST can be used to create in HTTP - - - - - This draft is purely a bug fix with no functional changes - Fixed erroneous meta-schema URI (draft-07, not draft-07-wip) - Removed stray "work in progress" language left over from review period - Fixed missing trailing "/" in various "base" examples - Fixed incorrect draft name in changelog (luff-*-00, not -01) - Update relative pointer ref to handrews-*-01, also purely a bug fix - - - - - Top to bottom reorganization and rewrite - Group keywords per RFC 8288 context/relation/target/target attributes - Additional keyword groups for template resolution and describing input - Clarify implementation requirements with a suggested output format - Expanded overview to provide context - Consolidated examples into their own section, illustrate real-world patterns - Consolidated HTTP guidance in its own section - Added a subsection on static analysis of hyper-schemas - Consolidated security concerns in their own section - Added an appendix on usage in APIs - Moved "readOnly" to the validation specification - Moved "media" to validation as "contentMediaType"/"contentEncoding" - Renamed "submissionEncType" to "submissionMediaType" - Renamed "mediaType" to "targetMediaType" - Added "anchor" and "anchorPointer" - Added "templatePointers" and "templateRequired" - Clarified how "hrefSchema" is used - Added "targetHints" and "headerSchema" - Added guidance on "self", "collection" and "item" link usage - Added "description" as an LDO keyword - Added "$comment" in LDOs to match the schema keyword - - - - - Fixed examples - Added "hrefSchema" for user input to "href" URI Templates - Removed URI Template pre-processing - Clarified how links and data submission work - Clarified how validation keywords apply hyper-schema keywords and links - Clarified HTTP use with "targetSchema" - Renamed "schema" to "submissionSchema" - Renamed "encType" to "submissionEncType" - Removed "method" - - - - - "rel" is now optional - rel="self" no longer changes URI base - Added "base" keyword to change instance URI base - Removed "root" link relation - Removed "create" link relation - Removed "full" link relation - Removed "instances" link relation - Removed special behavior for "describedBy" link relation - Removed "pathStart" keyword - Removed "fragmentResolution" keyword - Updated references to JSON Pointer, HTML - Changed behavior of "method" property to align with hypermedia best current practices - - - - - Split from main specification. - - - - -
- - diff --git a/archive/links.json b/archive/links.json deleted file mode 100644 index 8474f117..00000000 --- a/archive/links.json +++ /dev/null @@ -1,93 +0,0 @@ -{ - "$comment": "This file represents a work in progress and may not be a complete or valid 2019-09 / 2020-12 schema or vocabulary", - "$schema": "https://json-schema.org/draft/2019-09/hyper-schema", - "$id": "https://json-schema.org/draft/2019-09/links", - "title": "Link Description Object", - - "allOf": [ - { "required": [ "rel", "href" ] }, - { "$ref": "#/$defs/noRequiredFields" } - ], - "$defs": { - "noRequiredFields": { - "type": "object", - "properties": { - "anchor": { - "type": "string", - "format": "uri-template" - }, - "anchorPointer": { - "type": "string", - "anyOf": [ - { "format": "json-pointer" }, - { "format": "relative-json-pointer" } - ] - }, - "rel": { - "anyOf": [ - { "type": "string" }, - { - "type": "array", - "items": { "type": "string" }, - "minItems": 1 - } - ] - }, - "href": { - "type": "string", - "format": "uri-template" - }, - "hrefSchema": { - "$dynamicRef": "https://json-schema.org/draft/2019-09/hyper-schema#meta", - "default": false - }, - "templatePointers": { - "type": "object", - "additionalProperties": { - "type": "string", - "anyOf": [ - { "format": "json-pointer" }, - { "format": "relative-json-pointer" } - ] - } - }, - "templateRequired": { - "type": "array", - "items": { - "type": "string" - }, - "uniqueItems": true - }, - "title": { - "type": "string" - }, - "description": { - "type": "string" - }, - "targetSchema": { - "$dynamicRef": "https://json-schema.org/draft/2019-09/hyper-schema#meta", - "default": true - }, - "targetMediaType": { - "type": "string" - }, - "targetHints": { }, - "headerSchema": { - "$dynamicRef": "https://json-schema.org/draft/2019-09/hyper-schema#meta", - "default": true - }, - "submissionMediaType": { - "type": "string", - "default": "application/json" - }, - "submissionSchema": { - "$dynamicRef": "https://json-schema.org/draft/2019-09/hyper-schema#meta", - "default": true - }, - "$comment": { - "type": "string" - } - } - } - } -} diff --git a/archive/meta/hyper-schema.json b/archive/meta/hyper-schema.json deleted file mode 100644 index 8bf7ac73..00000000 --- a/archive/meta/hyper-schema.json +++ /dev/null @@ -1,30 +0,0 @@ -{ - "$comment": "This file represents a work in progress and may not be a complete or valid 2019-09 / 2020-12 schema or vocabulary", - "$schema": "https://json-schema.org/draft/2019-09/hyper-schema", - "$id": "https://json-schema.org/draft/2019-09/meta/hyper-schema", - "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/hyper-schema": true - }, - "$dynamicAnchor": "meta", - - "title": "JSON Hyper-Schema Vocabulary Schema", - "type": ["object", "boolean"], - "properties": { - "base": { - "type": "string", - "format": "uri-template" - }, - "links": { - "type": "array", - "items": { - "$ref": "https://json-schema.org/draft/2019-09/links" - } - } - }, - "links": [ - { - "rel": "self", - "href": "{+%24id}" - } - ] -} diff --git a/output/hyper-schema.json b/output/hyper-schema.json deleted file mode 100644 index 34e67303..00000000 --- a/output/hyper-schema.json +++ /dev/null @@ -1,62 +0,0 @@ -{ - "$schema": "https://json-schema.org/draft/2019-09/schema", - "$id": "https://json-schema.org/draft/2019-09/output/hyper-schema", - "title": "JSON Hyper-Schema Output", - "type": "array", - "items": { - "allOf": [ - {"$ref": "https://json-schema.org/draft/2019-09/links#/$defs/noRequiredFields" } - ], - "type": "object", - "required": [ - "contextUri", - "contextPointer", - "rel", - "attachmentPointer" - ], - "if": { "required": [ "hrefSchema" ] }, - "then": { "required": [ "hrefInputTemplates", "hrefPrepopulatedInput" ] }, - "else": { "required": [ "targetUri" ] }, - "properties": { - "contextUri": { - "$comment": "The fully resolved URI of the link context, including a fragment if it is possible to construct one for the given media type and instance", - "type": "string", - "format": "uri" - }, - "contextPointer": { - "$comment": "The absolute JSON Pointer to the location in the instance that is the context of the link. If the context resource supports JSON Pointer fragments, this will the string form of the identical JSON Pointer", - "type": "string", - "format": "json-pointer" - }, - "rel": { - "type": "string" - }, - "targetUri": { - "$comment": "The fully resolved target URI", - "type": "string", - "format": "uri" - }, - "hrefInputTemplates": { - "$comment": "The list of partially resolved URI Templates, starting with \"href\", followed by applicable \"base\" values from nearest to furthest.", - "type": "array", - "items": { - "type": "string", - "format": "uri-template" - } - }, - "hrefPrepopulatedInput": { - "$comment": "The initial data set to be presented with the input form when URI Template input is accepted.", - "type": "object", - "propertyNames": { - "$comment": "These are all URI Template variable names, specifically the 'varname' production from RFC 6570, Section 2.3", - "pattern": "^(?:\\w|(?:%[a-f\\d]{2}))+(?:\\.(?:\\w|(?:%[a-f\\d]{2})))*$" - } - }, - "attachmentPointer": { - "$comment": "The absolute JSON Pointer, in string form, of the position to which this resolved link applies", - "type": "string", - "format": "json-pointer" - } - } - } -} From cb7861b3b90e8d176f29ef7e490efc30222c1bcd Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 19 Oct 2022 12:43:46 +1300 Subject: [PATCH 426/780] add droppedAnnotations --- jsonschema-core.xml | 39 ++++++++++++++++++++++++++++++++++----- 1 file changed, 34 insertions(+), 5 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 5a078dc4..adc255f0 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2888,11 +2888,14 @@ https://example.com/schemas/common#/$defs/allOf/1
- Any annotations produced by the validation. This property MUST NOT - be included if the validation was unsuccessful. The value - for this property MUST be an object where the keys are the names of - keywords and the values are the annotations produced by the - associated keyword. + Any annotations produced by the evaluation. This property MUST NOT + be included if the validation result of the containing subschema was + unsuccessful. + + + The value for this property MUST be an object where the + keys are the names of keywords and the values are the annotations + produced by the associated keyword. Each keyword defines its own annotation data type (e.g. "properties" @@ -2903,6 +2906,32 @@ https://example.com/schemas/common#/$defs/allOf/1
+
+ + Any annotations produced and subsequently dropped by the evaluation + due to an unsuccessful validation result of the containing subschema. + This property MAY be included if the validation result of the containing + subschema was unsuccessful. It MUST NOT be included if the local + validation result of the containing subschema was successful. + + + Implementations that wish to include these annotations are encouraged + to provide users with a configuration option to exclude them. + + + The value for this property MUST be an object where the + keys are the names of keywords and the values are the annotations + produced by the associated keyword. + + + Each keyword defines its own annotation data type (e.g. "properties" + produces a list of keywords, whereas "title" produces a string). + + + The JSON key for this information is "droppedAnnotations". + +
+
Nested results are generated from keywords which create a new dynamic From 8ea42da75683516e1bd3f12da935bff5814aaf5d Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 20 Oct 2022 10:55:52 +1300 Subject: [PATCH 427/780] add droppedAnnotations to sample output --- jsonschema-core.xml | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index adc255f0..091aa866 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -3325,6 +3325,10 @@ https://example.com/schemas/common#/$defs/allOf/1 "evaluationPath": "/properties/foo/allOf/1", "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1", "instanceLocation": "/foo", + "droppedAnnotations": { + "properties": [ "foo-prop" ], + "title": "foo-title" + }, "nested": [ { "valid": false, @@ -3333,6 +3337,9 @@ https://example.com/schemas/common#/$defs/allOf/1 "instanceLocation": "/foo/foo-prop", "errors": { "const": "Expected \"1\"" + }, + "droppedAnnotations": { + "title": "foo-prop-title" } }, { @@ -3356,6 +3363,10 @@ https://example.com/schemas/common#/$defs/allOf/1 "evaluationPath": "/properties/bar/$ref", "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar", "instanceLocation": "/bar", + "droppedAnnotations": { + "properties": [ "bar-prop" ], + "title": "bar-title" + }, "nested": [ { "valid": false, @@ -3364,6 +3375,9 @@ https://example.com/schemas/common#/$defs/allOf/1 "instanceLocation": "/bar/bar-prop", "errors": { "minimum": "2 is less than or equal to 10" + }, + "droppedAnnotations": { + "title": "bar-prop-title" } } ] From 7b51ad611976d39833f22f8c270983c417acdb84 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Sun, 18 Sep 2022 18:34:32 -0700 Subject: [PATCH 428/780] Normative language for "$vocabulary" This reworks the language around "$vocabulary" to capture the original intent in normative language. In particular, it explicitly addresses vocabularies omitted from "$vocabulary". The new text emphasizes the concepts of required or optional vocabularies more than the true and false boolean values that implement them, and adds some explanation of the utility of optional vocabularies. It also adds a clarification around identically-named vocabulary and non-vocabulary keywords, including that the standard keywords MUST be considered vocabulary keywords and subject to "$vocabulary" control even if the implementation does not support custom vocabularies at all. --- jsonschema-core.xml | 114 ++++++++++++++++++++++++++++++-------------- 1 file changed, 79 insertions(+), 35 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 4802e29d..3cc27d93 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1132,7 +1132,7 @@
-
+
Keywords declared in this section, which all begin with "$", make up the JSON Schema Core vocabulary. These keywords are either required in @@ -1238,17 +1238,13 @@
The "$vocabulary" keyword is used in meta-schemas to identify the - vocabularies available for use in schemas described by that meta-schema. - It is also used to indicate whether each vocabulary is required or optional, - in the sense that an implementation MUST understand the required vocabularies - in order to successfully process the schema. Together, this information forms - a dialect. Any vocabulary that is understood by the implementation MUST be - processed in a manner consistent with the semantic definitions contained - within the vocabulary. + vocabularies available for use in schemas described by that meta-schema, + and whether each vocabulary is required or optional. Together, this + information forms a dialect. The value of this keyword MUST be an object. The property names in the - object MUST be IRIs (containing a scheme) and this IRI MUST be normalized. + object MUST be IRIs (containing a scheme) and each IRI MUST be normalized. Each IRI that appears as a property name identifies a specific set of keywords and their semantics. @@ -1268,32 +1264,79 @@ The values of the object properties MUST be booleans. - 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. The value has no impact if the implementation - understands the vocabulary. + If the value is true, then the vocabulary MUST be considered to be required. + If the value is false, then the vocabulary MUST be considered to be optional. - - Per , unrecognized - keywords SHOULD be treated as annotations. - This remains the case for keywords defined - by unrecognized vocabularies. It is not currently possible to distinguish - between unrecognized keywords that are defined in vocabularies from - those that are not part of any vocabulary. - - - The "$vocabulary" keyword SHOULD be used in the root schema of any schema - resource intended for use as a meta-schema. It MUST NOT appear in subschemas. - - - The "$vocabulary" keyword MUST be ignored in schema resources that - are not being processed as a meta-schema. This allows validating - a meta-schema M against its own meta-schema M' without requiring - the validator to understand the vocabularies declared by M. - -
+
+ + A schema is said to use a dialect and its constituent vocabularies if it is + associated with a meta-schema defining the dialect with "$vocabulary", + either through "$schema", through appropriately defined media type parameters + or link relation types, or through documented default implementation-defined + behavior in the absence of an explicit meta-schema. If a meta-schema + does not contain "$vocabulary", the set of vocabularies in use is determined + according to section . + + + Any vocabulary in use by a schema and understood by the implementation + MUST be processed in a manner consistent with the semantic definitions + contained within the vocabulary, regardless of whether that vocabulary + is required or optional. + + + Any vocabulary that is not present in "$vocabulary" MUST NOT be made + available for use in schemas described by that meta-schema, except for + the core vocabulary as specified by the introduction to section + . + + + Implementations that do not support a vocabulary required by a schema + MUST refuse to process that schema. + + + Implementations that do not support a vocabulary that is optionally used + by a schema SHOULD proceed with processing the schema. The keywords will + be considered to be unrecognized keywords as addressed by section + . Note that since + the recommended behavior for such keywords is to collect them as + annotations, vocabularies consisting only of annotations will have + the same behavior when used optionally whether the implementation + supports them or not. This allows annotation-only vocabularies to + be supported without custom code, even in implementations that do + not support providing custom code for extension vocabularies. + +
+
+ + The "$vocabulary" keyword SHOULD be used in the root schema of any schema + resource intended for use as a meta-schema. It MUST NOT appear in subschemas. + + + The "$vocabulary" keyword MUST be ignored in schema resources that + are not being processed as a meta-schema. This allows validating + a meta-schema M against its own meta-schema M' without requiring + the validator to understand the vocabularies declared by M. + +
+
+ + Keywords from different vocabularies, as well as non-vocabulary + extension keywords, can have identical names. These are not + considered to be the same keyword from the perspective of + enabling or disabling them through "$vocabulary". + + + In particular the keywords defined in this specification and its + companion documents MUST be considered to be vocabulary keywords, + with availability governed by "$vocabulary" even in implementations + that do not support any extension vocabularies. + + + Guidance regarding vocabularies with identically-named keywords is provided + in Appendix . + +
+
If "$vocabulary" is absent, an implementation MAY determine behavior based on the meta-schema if it is recognized from the @@ -3936,7 +3979,8 @@ https://example.com/schemas/common#/$defs/allOf/1
-
+
Vocabulary authors should take care to avoid keyword name collisions if the vocabulary is intended From c8f45323d318d4d45d0a7c1da7c82a6e75f6fe38 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 27 Oct 2022 10:03:56 +1300 Subject: [PATCH 429/780] add droppedAnnotations to output validation schema --- output/schema.json | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/output/schema.json b/output/schema.json index b3b80799..be2ec3fd 100644 --- a/output/schema.json +++ b/output/schema.json @@ -31,6 +31,10 @@ "type": "object", "additionalProperties": true }, + "droppedAnnotations": { + "type": "object", + "additionalProperties": true + }, "errors": { "type": "object", "additionalProperties": { "type": "string" } @@ -40,7 +44,14 @@ "allOf": [ { "if": { - "required": [ "errors" ] + "anyOf": [ + { + "required": [ "errors" ] + }, + { + "required": [ "droppedAnnotations" ] + } + ] }, "then": { "properties": { From c28c256df8a317e3a2823d81fc960e86b04b5106 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 27 Oct 2022 10:22:55 +1300 Subject: [PATCH 430/780] reworked droppedAnnotations language to require opt-in --- jsonschema-core.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 091aa866..354cf8a0 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2915,8 +2915,9 @@ https://example.com/schemas/common#/$defs/allOf/1 validation result of the containing subschema was successful. - Implementations that wish to include these annotations are encouraged - to provide users with a configuration option to exclude them. + Implementations that wish to provide these annotations MUST NOT provide + them as their default behavior. These annotations MUST only be included + by explicitly configuring the implementation to do so. The value for this property MUST be an object where the From 9187f10cb6e6e1400807a2731c299d92fc740723 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 28 Oct 2022 10:41:26 +1300 Subject: [PATCH 431/780] refine 'match' language for properties and patternProperties --- jsonschema-core.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 5a078dc4..656ae63b 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2404,7 +2404,7 @@ The annotation result of this keyword is the set of instance - property names matched by this keyword. + property names which are present in both this keyword and the instance. This annotation affects the behavior of "additionalProperties" (in this vocabulary) and "unevaluatedProperties" in the Unevaluated vocabulary. @@ -2430,7 +2430,7 @@ The annotation result of this keyword is the set of instance - property names matched by this keyword. + property names matched by at least one key in this keyword. This annotation affects the behavior of "additionalProperties" (in this vocabulary) and "unevaluatedProperties" (in the Unevaluated vocabulary). From 550817f9abf574580f27a15858fd6146c53c9530 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 28 Oct 2022 10:45:18 +1300 Subject: [PATCH 432/780] remove redundancy in `properties` annotation definition --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 656ae63b..9793aab1 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2404,7 +2404,7 @@ The annotation result of this keyword is the set of instance - property names which are present in both this keyword and the instance. + property names which are also present in this keyword. This annotation affects the behavior of "additionalProperties" (in this vocabulary) and "unevaluatedProperties" in the Unevaluated vocabulary. From 7e689536719ae86463cd0861587c2c9822ff1fd3 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Mon, 24 Oct 2022 10:39:08 -0700 Subject: [PATCH 433/780] Update code of conduct in CONTRIBUTING.md --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 942f71a8..71cc8e8b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -46,7 +46,7 @@ As an informative document, bugs in the meta-schema may be fixed in place to ali ## Conduct -All official channels including the mailing list, GitHub organization, and Freenode channel, follow the IETF Guidelines for Conduct as specified in [RFC7154](https://tools.ietf.org/html/rfc7154). +All official channels including the mailing list, GitHub organization, Slack server, and IRC channels, follow our [Code of Conduct](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md). ## Financial contributions From c028e943ab213531f55e60ff6a2b1202f5d443c6 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Sun, 27 Mar 2022 21:17:09 -0700 Subject: [PATCH 434/780] fix the type for $recursiveAnchor --- schema.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/schema.json b/schema.json index 066d86b9..58da4e70 100644 --- a/schema.json +++ b/schema.json @@ -46,7 +46,7 @@ }, "$recursiveAnchor": { "$comment": "\"$recursiveAnchor\" has been replaced by \"$dynamicAnchor\".", - "$ref": "meta/core#/$defs/anchorString", + "type": "boolean", "deprecated": true }, "$recursiveRef": { From 751390284c186df70351a2d7b9c5ca6c8dc8fc24 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Mon, 7 Nov 2022 08:53:49 +1300 Subject: [PATCH 435/780] Incorporate suggested change Co-authored-by: Karen Etheridge --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 9793aab1..f24077f9 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2430,7 +2430,7 @@ The annotation result of this keyword is the set of instance - property names matched by at least one key in this keyword. + property names matched by at least one property under this keyword. This annotation affects the behavior of "additionalProperties" (in this vocabulary) and "unevaluatedProperties" (in the Unevaluated vocabulary). From ee931a06c3795d2f073325031819aab79c20fc03 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Mon, 7 Nov 2022 08:54:09 +1300 Subject: [PATCH 436/780] Incoporate suggested change Co-authored-by: Karen Etheridge --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f24077f9..f4397b08 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2404,7 +2404,7 @@ The annotation result of this keyword is the set of instance - property names which are also present in this keyword. + property names which are also present under this keyword. This annotation affects the behavior of "additionalProperties" (in this vocabulary) and "unevaluatedProperties" in the Unevaluated vocabulary. From 29761ccaaac6ace399f8991c739a5e89bf2dc9df Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Mon, 21 Nov 2022 13:06:18 -0800 Subject: [PATCH 437/780] Clarify how to use "contentSchema" We know that many schema users find base URIs/IRIs confusing, and that the behavior of implementations in the absence of "$schema" is inconsistent. Without delving into those topics (which are addressed in core, or in RFC 3986), this clarification shows how to use "contentSchema" as a normal subschema from an annotation. It also explains the circumstances under which the extracted annotation value is safe to use. The language attempts to balance the likelihood that readers will not be familiar enough with the restrictions to note this on their own with the desire to minimize re-stating schema processing rules documented in the core specification. This should be enough to encourage readers to check the relevant core specification sections. --- jsonschema-validation.xml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 22a67a0e..aa15895f 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -960,7 +960,10 @@ The value of this property MUST be a valid JSON schema. It SHOULD be ignored if - "contentMediaType" is not present. + "contentMediaType" is not present. Accessing the schema through the schema location + IRI included as part of the annotation will ensure that it is correctly processed + as a subschema. Using the extracted annotation value directly is only safe if + the schema is an embedded resource with both "$schema" and an absolute-IRI "$id".
From 92569982678cf170eeabadaaa96bb6a8ef99ac6c Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 22 Nov 2022 09:17:09 +1300 Subject: [PATCH 438/780] update output's 'nested' to 'details' --- jsonschema-core.xml | 44 ++++++++++++++++++++++---------------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index a8ca268f..8a9f2c10 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2974,10 +2974,10 @@ https://example.com/schemas/common#/$defs/allOf/1
-
+
- Nested results are generated from keywords which create a new dynamic - scope by applying a subschema to the instance or a child of the instance. + Evaluation results generated by applying a subschema to the instance + or a child of the instance. Keywords which have multiple subschemas (e.g. "anyOf") will generally generate an output unit for each subschema. In order to accommodate potentially multiple results, the value of this property MUST be an @@ -2988,8 +2988,8 @@ https://example.com/schemas/common#/$defs/allOf/1 and will hold all output units in a flat list. - For "hierarchical", this property will hold nested results in a tree - structure where each output unit may itself have nested results. + For "hierarchical", this property will contain results in a tree + structure where each output unit may itself have further nested results. The sequence of output units within this list is not specified and @@ -2997,7 +2997,7 @@ https://example.com/schemas/common#/$defs/allOf/1 considered equivalent if they contain the same units, in any order. - The JSON key for nested results is "nested". + The JSON key for these additional results is "details".
@@ -3007,13 +3007,13 @@ https://example.com/schemas/common#/$defs/allOf/1 The output MUST be an object containing a boolean property named "valid". When additional information about the result is required, the output MUST also contain - "nested" as described below. + "details" as described below. "valid" - a boolean value indicating the overall validation success or failure - "nested" - the collection of results produced by subschemas + "details" - the collection of results produced by subschemas For these examples, the following schema and instances will be used. @@ -3207,11 +3207,11 @@ https://example.com/schemas/common#/$defs/allOf/1 root output unit. - The root output unit contains "valid" for the overall result and "nested" + The root output unit contains "valid" for the overall result and "details" for the list of specific results. All other information is explicitly omitted from the root output unit. If the root schema produces errors or annotations, then the output node for the root MUST be present within the - root output unit's "nested" list with those errors or annotations. + root output unit's "details" list with those errors or annotations. Output units which do not contain errors or annotations SHOULD be excluded @@ -3224,7 +3224,7 @@ https://example.com/schemas/common#/$defs/allOf/1 // failing results { "valid": false, - "nested": [ + "details": [ { "valid": false, "evaluationPath": "/properties/foo/allOf/0", @@ -3258,7 +3258,7 @@ https://example.com/schemas/common#/$defs/allOf/1 // passing results { "valid": true, - "nested": [ + "details": [ { "valid": true, "evaluationPath": "", @@ -3346,13 +3346,13 @@ https://example.com/schemas/common#/$defs/allOf/1 "evaluationPath": "", "schemaLocation": "https://json-schema.org/schemas/example#", "instanceLocation": "", - "nested": [ + "details": [ { "valid": false, "evaluationPath": "/properties/foo", "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo", "instanceLocation": "/foo", - "nested": [ + "details": [ { "valid": false, "evaluationPath": "/properties/foo/allOf/0", @@ -3371,7 +3371,7 @@ https://example.com/schemas/common#/$defs/allOf/1 "properties": [ "foo-prop" ], "title": "foo-title" }, - "nested": [ + "details": [ { "valid": false, "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", @@ -3399,7 +3399,7 @@ https://example.com/schemas/common#/$defs/allOf/1 "evaluationPath": "/properties/bar", "schemaLocation": "https://json-schema.org/schemas/example#/properties/bar", "instanceLocation": "/bar", - "nested": [ + "details": [ { "valid": false, "evaluationPath": "/properties/bar/$ref", @@ -3409,7 +3409,7 @@ https://example.com/schemas/common#/$defs/allOf/1 "properties": [ "bar-prop" ], "title": "bar-title" }, - "nested": [ + "details": [ { "valid": false, "evaluationPath": "/properties/bar/$ref/properties/bar-prop", @@ -3442,13 +3442,13 @@ https://example.com/schemas/common#/$defs/allOf/1 "bar" ] }, - "nested": [ + "details": [ { "valid": true, "evaluationPath": "/properties/foo", "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo", "instanceLocation": "/foo", - "nested": [ + "details": [ { "valid": true, "evaluationPath": "/properties/foo/allOf/0", @@ -3469,7 +3469,7 @@ https://example.com/schemas/common#/$defs/allOf/1 "unspecified-prop" ] }, - "nested": [ + "details": [ { "valid": true, "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", @@ -3494,7 +3494,7 @@ https://example.com/schemas/common#/$defs/allOf/1 "evaluationPath": "/properties/bar", "schemaLocation": "https://json-schema.org/schemas/example#/properties/bar", "instanceLocation": "/bar", - "nested": [ + "details": [ { "valid": true, "evaluationPath": "/properties/bar/$ref", @@ -3506,7 +3506,7 @@ https://example.com/schemas/common#/$defs/allOf/1 "bar-prop" ] }, - "nested": [ + "details": [ { "valid": true, "evaluationPath": "/properties/bar/$ref/properties/bar-prop", From 69dd9a2bcbcf1516ff234f8748f7764d0fa0d06b Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Mon, 21 Nov 2022 13:38:49 -0800 Subject: [PATCH 439/780] Put boundaries on lack of "$schema" behavior This may well change prior to the next release, but documents the intended range of options so as to avoid crashes or completely arbitrary behavior. --- jsonschema-core.xml | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index a8ca268f..c286acea 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1228,7 +1228,15 @@ The "$schema" keyword SHOULD be used in the document root schema object, and MAY be used in the root schema objects of embedded schema resources. It MUST NOT appear in non-resource root schema objects. If absent from - the document root schema, the resulting behavior is implementation-defined. + the document root schema, the resulting behavior is implementation-defined, + but MUST fall within the following options: +
    +
  • Refuse to process the schema, as with unsupported required + vocabularies
    • +
  • Assume a specific, documented meta-schema
    • +
  • Document the process by which it examines the schema and determines + which of a specific set of meta-schemas to assume
    • +
Values for this property are defined elsewhere in this and other documents, @@ -3547,9 +3555,9 @@ https://example.com/schemas/common#/$defs/allOf/1 Instances and schemas are both frequently written by untrusted third parties, to be deployed on public Internet servers. - Validators should take care that the parsing and validating against schemas does not consume excessive - system resources. - Validators MUST NOT fall into an infinite loop. + Implementations should take care that the parsing and evaluating against schemas + does not consume excessive system resources. + Implementations MUST NOT fall into an infinite loop. A malicious party could cause an implementation to repeatedly collect a copy From eed8b19b5d020c40fe37ec0d1f49f85b7cb1bbaf Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 24 Nov 2022 09:57:55 +1300 Subject: [PATCH 440/780] update basic to list --- jsonschema-core.xml | 10 +++++----- output/schema.json | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 8a9f2c10..53ea8c6b 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2806,7 +2806,7 @@ with no further details. - Basic - Provides validation information in a flat list structure. + List - Provides validation information in a flat list structure. Hierarchical - Provides validation information in a hierarchical @@ -2815,7 +2815,7 @@ An implementation MUST provide the "flag" format and SHOULD provide at least one - of the "basic" or "hierarchical" formats. Implementations SHOULD specify in + of the "list" or "hierarchical" formats. Implementations SHOULD specify in their documentation which formats they support. @@ -2984,7 +2984,7 @@ https://example.com/schemas/common#/$defs/allOf/1 array of output units, even if only a single output unit is produced. - For "basic", this property will appear only at the root output unit + For "list", this property will appear only at the root output unit and will hold all output units in a flat list. @@ -3201,9 +3201,9 @@ https://example.com/schemas/common#/$defs/allOf/1
-
+
- The "Basic" structure is a flat list of output units contained within a + The "List" structure is a flat list of output units contained within a root output unit. diff --git a/output/schema.json b/output/schema.json index be2ec3fd..8487a290 100644 --- a/output/schema.json +++ b/output/schema.json @@ -5,7 +5,7 @@ "anyOf": [ { "$ref": "#/$defs/flag" }, - { "$ref": "#/$defs/basic" }, + { "$ref": "#/$defs/list" }, { "$ref": "#/$defs/hierarchical" } ], "$defs": { @@ -81,7 +81,7 @@ }, "required": [ "valid" ] }, - "basic": { + "list": { "properties": { "valid": { "type": "boolean" }, "nested": { From 1d8a5eb0aa1fd36ff530760624470e5e84606939 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 28 Nov 2022 11:13:02 +0000 Subject: [PATCH 441/780] Remove Relequestual from funding links --- .github/FUNDING.yml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml index 93f90d33..27ac9973 100644 --- a/.github/FUNDING.yml +++ b/.github/FUNDING.yml @@ -1,9 +1,8 @@ # These are supported funding model platforms -github: [relequestual] # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2] +github: [] # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2] patreon: # Replace with a single Patreon username open_collective: json-schema -ko_fi: relequestual +ko_fi: # Single username tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry -custom: https://buymeacoffee.com/relequestual From d7ef2804e0eefa78f14e76f8d75883133d9e9726 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 3 Nov 2022 16:00:04 -0700 Subject: [PATCH 442/780] Add ADR for choosing a new SDLC --- adr/2022-11-stable-spec.md | 180 +++++++++++++++++++++++++++++++++++++ 1 file changed, 180 insertions(+) create mode 100644 adr/2022-11-stable-spec.md diff --git a/adr/2022-11-stable-spec.md b/adr/2022-11-stable-spec.md new file mode 100644 index 00000000..fce8e502 --- /dev/null +++ b/adr/2022-11-stable-spec.md @@ -0,0 +1,180 @@ +# Selecting a new specification development process + +* Status: accepted +* Deciders: @jdesrosiers @relequestual @awwright @handrews @gregsdennis +* Date: 2022-11-02 + +## Context and Problem Statement +We've chosen to decouple our process from IETF, so we need to choose a new +specification development process to replace it. + +## Decision Drivers +* Dropping the "draft" label is an important driver of this change. It's mostly + an artifact of the IETF process and has proven to be confusing for the + community. +* The community wants a stable version of JSON Schema. +* There is a need for JSON Schema to continue to evolve to meet evolving + needs. +* There is a demand for custom keywords/vocabularies/dialects and we want to + continue to support those use cases. +* There is a need to ease the burden of implementations supporting multiple + versions of JSON Schema. + +## Considered Options +There have been two proposals put forward. Both address the goal of a stable +specification with the ability to evolve. The third option represents sticking +with the status quo. + +### Option 1 - TC-39 inspired +The spec would be converted from I-D XML to Markdown, but can otherwise be +structured however we choose. A system would be put in place to allow us to flag +the stability level of any feature in the spec. There would be only one version +of the spec and that version can change at any time, but changes to stable +features must follow strict backward and forward compatibility requirements. + +New features must go through a hardening process to ensure that they are very +unlikely to change before they are considered stable and subject to +compatibility requirements. This process will impose strict requirements +including tests, implementations, documentation, and real world vetting before a +feature or new keyword can be made stable in the spec. + +Since the spec is constantly evolving, a "release" is just a matter of promoting +unstable features to "stable" status. Releases would happen once a year and be +designated by the year they were released. + +### Option 2 - IETF Inspired +The spec would be reorganized into two parts: "Core Semantics" and "Standard +Extensions". + +The "Core Semantics" spec would contain the bare minimum rules that +must be implemented for validators to not produce inaccurate results regardless +of future revisions or extensions. Among other necessities, this would include a +core set of keywords necessary to fully support structural validation and an +extension mechanism. This spec should be considered stable and should rarely +change, but if it does, it must do so in a backward and forward compatible way. + +The "Standard Extensions" spec would include the rest of the spec. Features and +keywords included in this spec are so ubiquitous that they should be considered +essential for implementations to support. Changes to this spec must be +compatible with previous releases with exceptions only in extreme cases. + +A registry could be maintained that maps keywords to their specified semantics. +User extensions that aren't in the registry should use a URI for their keyword +to avoid conflicts with other third-party extensions or with future standard +extensions. + +### Option 3 - Minimal Change +Option 3 represents the minimal amount of change to our process from what we +have been doing. The spec would need to be converted from I-D XML to a Markdown +version that would be served on the website, but otherwise we would continue to +work the way we have been. We would aim for new version release every year with +a patch release mid-cycle. Each release is a distinct version of JSON Schema and +has no compatibility guarantees between versions. + +## Decision Outcome +The decision is to go with Option 1 while leaving discussion open for nearly all +of Option 2 because it is mostly compatible with Option 1. Option 2 uses an +immutable spec where each release replaces the last while the Option 1 uses a +mutable spec. The outcome of having only one current version of the spec is +achieved with either option, but the mutable spec allows us to remove some +unnecessary roadblocks in our development processes and allows us to release a +stable spec much sooner. Other than that, discussion for the rest of Option 2 +can continue within the constraints of Option 1. + +Option 1 puts no constraint on the structure of the spec and restructuring is +allowed at any time as long as it doesn't break compatibility requirements. +Therefore, restructuring the spec as "Core Semantics" and "Standard Extensions" +is compatible with Option 1. We can move forward with Option 1 now while leaving +the restructuring discussion open. + +Option 2 defines a new extension mechanism and some new keywords. These features +can be introduced under the stability model described in Option 1. Therefore, we +can move forward with Option 1 while leaving the discussion open for these new +features. + +## Pros and Cons of the Options +The biggest benefit is shared between Option 1 and Option 2. Both approaches +result in a stable spec. This will have benefits implementers and users. Because +of the compatibility requirements, whenever you write a schema, you will never +need to change it just to keep up with new features added to JSON Schema. This +is also better for implementers because they don't have to maintain separate +code different semantics in different versions. They just need to code for the +current release and they will automatically have support for past releases. + +### Option 1 - TC-39 Inspired +The two things that make this option stand out are the stability model and the +mutability of the spec document. + +Having a mutable spec allows us to make clarifications and bug fixes immediately +rather than having to wait months or years for the next release to go out. It +also allows us to iterate faster on unstable features which would allow us to +get them to a stable state much sooner. For example, we have changes to dynamic +references that have been agreed upon and ready to go for over a year, but users +can't benefit from the change until we can get the next full release published. +With this model, the change could have been made available for over a year now +and we would have a years worth of feedback on it's use. Having a mutable spec +also allows us to introduce new features without having to wait for a release. +For example, the `propertyDependencies` keyword has also been waiting for months +for a release. Users could have been benefiting from it for months and providing +feedback. + +The downside of a mutable spec is that it can be more difficult for implementers +and users to track when changes happen. We will need to be better at +communicating changes in blog posts or equivalent. + +The stability model allows us to ensure we don't make incompatible changes to +stable features, but it also allows us to introduce new features and get real +world feedback without committing to full compatibility requirements. This makes +it much more likely that we don't get stuck with something that doesn't work out +or could be done better. + +The stability model also makes it clear to users which features are stable and +how likely an unstable feature is to change in the future. Whether they prefer +to stick with stable features or want to use a new keyword, users have the +information they need to make that decision. + +The downside of the stability model is that it presents a very high barrier for +a feature to make it into a stable status. It would typically take two years for +a feature to reach stability which could be a long time to wait for users who +need to stick to the stable feature set but could benefit greatly from a new +feature. + +### Option 2 - IETF Inspired +The benefit of this approach is that it's compatible with the IETF process +without imposing some of the constraints and perception issues that we had with +IETF. We can pursue an RFC in the future if we choose to without significant +changes or spec restructuring. + +With this proposal, releases are done as a new document that replaces the +previous documents. Compared to the constantly evolving spec in Option 1, change +from non-functional clarifications and bug fixes to adding and evolving new +features takes much longer if you have to wait for the next release to make a +change. This lengthens the feedback loop slowing spec development progress. + +The main downside of this approach compared to Option 1 is that it will likely +take quite a while to get to a stable release. The spec restructuring is +controversial and it proposes several new keywords that are also controversial. +Discussing, achieving consensus, specifying, and implementing these changes will +take time. Introducing new features and keywords is much more risky with the new +compatibility requirements, so we have to go extra slow to make sure we get it +right. + +### Option 3 - Minimal Changes +The benefit of this solution is that we don't have the overhead of defining +and/or learning a new process. In the short term, we can put more effort into +improving JSON Schema if we don't have the distraction of defining a whole new +process. The problem with this approach is that it doesn't solve the problem +with the "draft" label and doesn't provide the stability the community is +looking for. + +## Links +* https://github.com/jdesrosiers/json-schema-spec/blob/main/adr/2022-09-decouple-from-ietf.md - + The ADR for the decision to decouple from IETF +* https://github.com/orgs/json-schema-org/discussions/234 - Proposal submitted + by @jdesrosiers for a process to replace the IETF based process we'd been + using. +* https://github.com/orgs/json-schema-org/discussions/257 - @awwright's vision + for JSON Schema including how it can continue to evolve while still having a + stable core. +* https://github.com/json-schema-org/community/discussions/119 - When we first + started talking about forward compatibility and a stable spec. From 3c40dd8c60c535891b2bd2a916b20f610c198c9f Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Tue, 8 Nov 2022 10:21:11 -0800 Subject: [PATCH 443/780] Apply suggestions from code review Co-authored-by: Greg Dennis --- adr/2022-11-stable-spec.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/adr/2022-11-stable-spec.md b/adr/2022-11-stable-spec.md index fce8e502..4e935181 100644 --- a/adr/2022-11-stable-spec.md +++ b/adr/2022-11-stable-spec.md @@ -51,7 +51,7 @@ must be implemented for validators to not produce inaccurate results regardless of future revisions or extensions. Among other necessities, this would include a core set of keywords necessary to fully support structural validation and an extension mechanism. This spec should be considered stable and should rarely -change, but if it does, it must do so in a backward and forward compatible way. +change, but if it does, it must maintain backward and forward compatibility. The "Standard Extensions" spec would include the rest of the spec. Features and keywords included in this spec are so ubiquitous that they should be considered @@ -98,7 +98,7 @@ result in a stable spec. This will have benefits implementers and users. Because of the compatibility requirements, whenever you write a schema, you will never need to change it just to keep up with new features added to JSON Schema. This is also better for implementers because they don't have to maintain separate -code different semantics in different versions. They just need to code for the +code with different semantics in different versions. They just need to code for the current release and they will automatically have support for past releases. ### Option 1 - TC-39 Inspired From abcbf052096562f9cf3ebba9046c8cfbd58ade53 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Tue, 8 Nov 2022 15:34:50 -0800 Subject: [PATCH 444/780] ADR SDLC - Improve Option 2 description --- adr/2022-11-stable-spec.md | 108 ++++++++++++++++++------------------- 1 file changed, 53 insertions(+), 55 deletions(-) diff --git a/adr/2022-11-stable-spec.md b/adr/2022-11-stable-spec.md index 4e935181..5f5ddd49 100644 --- a/adr/2022-11-stable-spec.md +++ b/adr/2022-11-stable-spec.md @@ -25,7 +25,7 @@ There have been two proposals put forward. Both address the goal of a stable specification with the ability to evolve. The third option represents sticking with the status quo. -### Option 1 - TC-39 inspired +### Option 1 - TC-39 Inspired The spec would be converted from I-D XML to Markdown, but can otherwise be structured however we choose. A system would be put in place to allow us to flag the stability level of any feature in the spec. There would be only one version @@ -44,66 +44,64 @@ designated by the year they were released. ### Option 2 - IETF Inspired The spec would be reorganized into two parts: "Core Semantics" and "Standard -Extensions". +Extensions". Changes to either spec are subject to strict backward and forward +compatibility requirements and would be released as a new spec that replaces and +obsoletes past versions of the spec. -The "Core Semantics" spec would contain the bare minimum rules that -must be implemented for validators to not produce inaccurate results regardless -of future revisions or extensions. Among other necessities, this would include a +The "Core Semantics" spec would contain the bare minimum rules that must be +implemented for validators to not produce inaccurate results regardless of +future revisions or extensions. Among other necessities, this would include a core set of keywords necessary to fully support structural validation and an -extension mechanism. This spec should be considered stable and should rarely -change, but if it does, it must maintain backward and forward compatibility. - -The "Standard Extensions" spec would include the rest of the spec. Features and -keywords included in this spec are so ubiquitous that they should be considered -essential for implementations to support. Changes to this spec must be -compatible with previous releases with exceptions only in extreme cases. - -A registry could be maintained that maps keywords to their specified semantics. -User extensions that aren't in the registry should use a URI for their keyword -to avoid conflicts with other third-party extensions or with future standard -extensions. +extension mechanism. This spec should rarely change. New features would be added +through additional specifications that define extensions to the "Core Semantics" +spec. + +The "Standard Extensions" spec is an example of one of these extension +specifications. This spec would be authored by the JSON Schema Org, but +extension specifications could be authored by anyone. The "Standard Extensions" +spec would include everything from the current spec that isn't included in the +"Core Semantics" spec. Features and keywords included in this spec are so +ubiquitous that they should be considered essential for implementations to +support. ### Option 3 - Minimal Change Option 3 represents the minimal amount of change to our process from what we have been doing. The spec would need to be converted from I-D XML to a Markdown version that would be served on the website, but otherwise we would continue to -work the way we have been. We would aim for new version release every year with -a patch release mid-cycle. Each release is a distinct version of JSON Schema and +work the way we have been. We would aim for new version releases every year with +patch releases mid-cycle. Each release is a distinct version of JSON Schema and has no compatibility guarantees between versions. ## Decision Outcome -The decision is to go with Option 1 while leaving discussion open for nearly all -of Option 2 because it is mostly compatible with Option 1. Option 2 uses an -immutable spec where each release replaces the last while the Option 1 uses a -mutable spec. The outcome of having only one current version of the spec is -achieved with either option, but the mutable spec allows us to remove some -unnecessary roadblocks in our development processes and allows us to release a -stable spec much sooner. Other than that, discussion for the rest of Option 2 -can continue within the constraints of Option 1. - -Option 1 puts no constraint on the structure of the spec and restructuring is -allowed at any time as long as it doesn't break compatibility requirements. -Therefore, restructuring the spec as "Core Semantics" and "Standard Extensions" -is compatible with Option 1. We can move forward with Option 1 now while leaving -the restructuring discussion open. - -Option 2 defines a new extension mechanism and some new keywords. These features -can be introduced under the stability model described in Option 1. Therefore, we -can move forward with Option 1 while leaving the discussion open for these new -features. +The decision is to go with Option 1 while leaving discussion open for aspects of +Option 2 that could be adopted within the constraints of Option 1. + +Option 2 uses an immutable spec where each release replaces the last while +Option 1 uses a mutable spec. The outcome of having only one current version of +the spec is achieved with either option, but the mutable spec allows us to +remove some unnecessary roadblocks in our development processes and allows us to +release a stable spec much sooner. + +Option 2's restructuring of the spec into "Core Semantics" and "Standard +Extensions" isn't specifically ruled out, but spec evolution is expected to be +done primarily through mutation of the spec guided by the stability process +rather than through extension. Option 1 puts no constraint on the structure of +the spec and restructuring is allowed at any time as long as it doesn't break +compatibility requirements. ## Pros and Cons of the Options The biggest benefit is shared between Option 1 and Option 2. Both approaches -result in a stable spec. This will have benefits implementers and users. Because -of the compatibility requirements, whenever you write a schema, you will never -need to change it just to keep up with new features added to JSON Schema. This -is also better for implementers because they don't have to maintain separate -code with different semantics in different versions. They just need to code for the -current release and they will automatically have support for past releases. +result in a stable spec. This will have benefits for both implementers and +users. Because of the compatibility requirements, whenever you write a schema, +you will never need to change it just to keep up with changes to JSON Schema. +This is also better for implementers because they don't have to maintain +separate code with different semantics in different versions. They just need to +code for the current release and they will automatically have support for past +releases. ### Option 1 - TC-39 Inspired -The two things that make this option stand out are the stability model and the -mutability of the spec document. +The two things that make this option stand out are the stability model governing +spec evolution and the mutability of the spec document. Having a mutable spec allows us to make clarifications and bug fixes immediately rather than having to wait months or years for the next release to go out. It @@ -129,9 +127,9 @@ it much more likely that we don't get stuck with something that doesn't work out or could be done better. The stability model also makes it clear to users which features are stable and -how likely an unstable feature is to change in the future. Whether they prefer -to stick with stable features or want to use a new keyword, users have the -information they need to make that decision. +how likely a feature is to change in the future. Whether they prefer to stick +with stable features or want to use a new keyword, users have the information +they need to make that decision. The downside of the stability model is that it presents a very high barrier for a feature to make it into a stable status. It would typically take two years for @@ -142,14 +140,14 @@ feature. ### Option 2 - IETF Inspired The benefit of this approach is that it's compatible with the IETF process without imposing some of the constraints and perception issues that we had with -IETF. We can pursue an RFC in the future if we choose to without significant -changes or spec restructuring. +our previous process. We can pursue an RFC in the future if we choose to without +significant changes or spec restructuring. With this proposal, releases are done as a new document that replaces the -previous documents. Compared to the constantly evolving spec in Option 1, change -from non-functional clarifications and bug fixes to adding and evolving new -features takes much longer if you have to wait for the next release to make a -change. This lengthens the feedback loop slowing spec development progress. +previous documents. Compared to the constantly evolving spec in Option 1, +changes from non-functional clarifications and bug fixes to adding and evolving +new features takes much longer if you have to wait for the next release to make +a change. This lengthens the feedback loop slowing spec development progress. The main downside of this approach compared to Option 1 is that it will likely take quite a while to get to a stable release. The spec restructuring is From c21205a40815b589c2e1b69a635988f41ecd0c29 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Mon, 14 Nov 2022 09:48:33 -0800 Subject: [PATCH 445/780] Update adr/2022-11-stable-spec.md Co-authored-by: Ben Hutton --- adr/2022-11-stable-spec.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/adr/2022-11-stable-spec.md b/adr/2022-11-stable-spec.md index 5f5ddd49..bead9930 100644 --- a/adr/2022-11-stable-spec.md +++ b/adr/2022-11-stable-spec.md @@ -176,3 +176,5 @@ looking for. stable core. * https://github.com/json-schema-org/community/discussions/119 - When we first started talking about forward compatibility and a stable spec. + * https://json-schema.org/blog/posts/future-of-json-schema - User friendly + comments on decoupling from the IETF. From 38bc78a0ba5c05e6f5c20cb93bd9f3e1c8a9ba0b Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Mon, 14 Nov 2022 10:37:48 -0800 Subject: [PATCH 446/780] ADR SDLC - Improve wording about slow path to stable --- adr/2022-11-stable-spec.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/adr/2022-11-stable-spec.md b/adr/2022-11-stable-spec.md index bead9930..b51595cf 100644 --- a/adr/2022-11-stable-spec.md +++ b/adr/2022-11-stable-spec.md @@ -97,7 +97,7 @@ you will never need to change it just to keep up with changes to JSON Schema. This is also better for implementers because they don't have to maintain separate code with different semantics in different versions. They just need to code for the current release and they will automatically have support for past -releases. +releases (not including "draft" releases). ### Option 1 - TC-39 Inspired The two things that make this option stand out are the stability model governing @@ -131,11 +131,12 @@ how likely a feature is to change in the future. Whether they prefer to stick with stable features or want to use a new keyword, users have the information they need to make that decision. -The downside of the stability model is that it presents a very high barrier for -a feature to make it into a stable status. It would typically take two years for -a feature to reach stability which could be a long time to wait for users who -need to stick to the stable feature set but could benefit greatly from a new -feature. +The stability model sets a very high barrier for a feature to make it into +stable status. This is on purpose so we can be very sure features won't change +once they are stable, but this process can take a long time. It would typically +take two years for a feature to reach stability which could be a long time to +wait for users who need to stick to the stable feature set but could benefit +greatly from a new feature. ### Option 2 - IETF Inspired The benefit of this approach is that it's compatible with the IETF process From d29e9c45183b457845014b870445ca29f4777be7 Mon Sep 17 00:00:00 2001 From: Austin Wright Date: Wed, 7 Dec 2022 17:22:36 -0700 Subject: [PATCH 447/780] Remove some superfluous format="counter" attributes --- jsonschema-core.xml | 64 +++++++++++++++++++-------------------------- 1 file changed, 27 insertions(+), 37 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f006d658..fabcfedc 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -352,8 +352,7 @@ A JSON Schema MAY contain properties which are not schema keywords or are not recognized as schema keywords. - The behavior of such keywords is governed by section - . + The behavior of such keywords is governed by . An empty schema is a JSON Schema with no properties. @@ -439,8 +438,7 @@ The root schema is the schema that comprises the entire JSON document in question. The root schema is always a schema resource, where the - IRI is determined as described in section - . + IRI is determined as described in . Note that documents that embed schemas in another format will not have a root schema resource in this sense. Exactly how such usages @@ -471,8 +469,7 @@ As with the root schema, a subschema is either an object or a boolean. - As discussed in section - , a JSON Schema document + As discussed in , a JSON Schema document can contain multiple JSON Schema resources. When used without qualification, the term "root schema" refers to the document's root schema. In some cases, resource root schemas are discussed. A resource's root schema @@ -657,10 +654,9 @@ location in the instance is evaluated against the assertion and annotation keywords in the schema object. The interactions of those keyword results to produce the schema object results are governed by - section , while the + , while the relationship of subschema results to the results of the applicator - keyword that applied them is described by section - . + keyword that applied them is described by . Evaluation of a parent schema object can complete once all of its @@ -816,8 +812,7 @@ Annotation results from subschemas - are preserved in accordance with section - so that applications + are preserved in accordance with so that applications can decide how to interpret multiple values. Applicator keywords do not play a direct role in this preservation. @@ -1110,8 +1105,8 @@ keywords. - While these keywords do not directly affect results, as explained in section - unrecognized + While these keywords do not directly affect results, as explained in + unrecognized extension keywords that reserve locations for re-usable schemas may have undesirable interactions with references in certain circumstances. @@ -1283,7 +1278,7 @@ or link relation types, or through documented default implementation-defined behavior in the absence of an explicit meta-schema. If a meta-schema does not contain "$vocabulary", the set of vocabularies in use is determined - according to section . + according to . Any vocabulary in use by a schema and understood by the implementation @@ -1294,8 +1289,8 @@ Any vocabulary that is not present in "$vocabulary" MUST NOT be made available for use in schemas described by that meta-schema, except for - the core vocabulary as specified by the introduction to section - . + the core vocabulary as specified by the introduction to + . Implementations that do not support a vocabulary required by a schema @@ -1304,8 +1299,8 @@ Implementations that do not support a vocabulary that is optionally used by a schema SHOULD proceed with processing the schema. The keywords will - be considered to be unrecognized keywords as addressed by section - . Note that since + be considered to be unrecognized keywords as addressed by + . Note that since the recommended behavior for such keywords is to collect them as annotations, vocabularies consisting only of annotations will have the same behavior when used optionally whether the implementation @@ -1341,7 +1336,7 @@ Guidance regarding vocabularies with identically-named keywords is provided - in Appendix . + in .
@@ -1444,7 +1439,7 @@ the parent schema resource. Note that an "$id" consisting of an empty IRI or of the empty fragment only will result in the embedded resource having the same IRI as the encapsulating resource, which SHOULD be considered - an error per section . + an error per . If no parent schema object explicitly identifies itself as a resource @@ -1498,8 +1493,8 @@ If present, the value of these keywords MUST be a string and MUST conform - to the plain name fragment identifier syntax defined in section - . + to the plain name fragment identifier syntax defined in + . Note that the anchor string does not include the "#" character, as it is not a IRI-reference. An "$anchor": "foo" becomes the @@ -1583,8 +1578,7 @@ resolved IRI. - For a full example using these keyword, see appendix - . + For a full example using these keyword, see . The difference between the hyper-schema meta-schema in pre-2019 drafts and an this draft dramatically demonstrates the utility @@ -1724,7 +1718,7 @@ on the trust that the validator has in the schema. Such IRIs and schemas can be supplied to an implementation prior to processing instances, or may be noted within a schema document as it is processed, producing associations - as shown in appendix . + as shown in .
@@ -1926,7 +1920,7 @@ Further examples of such non-canonical IRI construction, as well as the appropriate canonical IRI-based fragments to use instead, - are provided in appendix . + are provided in .
@@ -2577,7 +2571,7 @@ Validation MUST always succeed against this keyword. The value of this keyword is used as its annotation result. - Per section , + Per , omitted keywords MUST NOT produce annotation results. However, as described in the section for "contains", the absence of this keyword's annotation causes "contains" to assume a minimum value of 1. @@ -3599,8 +3593,7 @@ https://example.com/schemas/common#/$defs/allOf/1 media type. See JSON. - Security considerations: See Section - above. + Security considerations: See above. Interoperability considerations: See Sections @@ -3609,8 +3602,8 @@ https://example.com/schemas/common#/$defs/allOf/1 above. - Fragment identifier considerations: See Section - + Fragment identifier considerations: See + @@ -3630,8 +3623,7 @@ https://example.com/schemas/common#/$defs/allOf/1 media type. See JSON. - Security considerations: See Section - above. + Security considerations: See above. Interoperability considerations: See Sections @@ -3640,8 +3632,7 @@ https://example.com/schemas/common#/$defs/allOf/1 above. - Fragment identifier considerations: See Section - + Fragment identifier considerations: See @@ -3772,8 +3763,7 @@ https://example.com/schemas/common#/$defs/allOf/1 The schemas at the following IRI-encoded JSON Pointers (relative to the root schema) have the following base IRIs, and are identifiable by any listed IRI in accordance with - sections and - above. + and above. From b7958d91a2616882c81d38f10256c15b6c29fa54 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Tue, 17 Jan 2023 13:10:47 -0800 Subject: [PATCH 448/780] Update year on JSON Schema specs Note that Relative JSON Pointer has been updated in a separate PR. --- jsonschema-core.xml | 2 +- jsonschema-validation.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index a8ca268f..07e8735d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -53,7 +53,7 @@ - + Internet Engineering Task Force JSON Schema diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 22a67a0e..82684b89 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -54,7 +54,7 @@ - + Internet Engineering Task Force JSON Schema From b82dcbc7694706bb0172143e0ba1d73abd2bbef1 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Wed, 18 Jan 2023 10:32:36 -0800 Subject: [PATCH 449/780] Update year for rel json ptr --- relative-json-pointer.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index e3e93721..0521fac2 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -40,7 +40,7 @@ - + Internet Engineering Task Force JSON JavaScript From 97b47f9576e792019119a6600a2eab3bd97606e1 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Wed, 7 Dec 2022 14:24:23 -0800 Subject: [PATCH 450/780] Fix accidental ABNF omission Taking the index of the result of an index manipulation was shown in the example and intended to work, but left out of the ABNF apparently by accident. Also, rework the ABNF to keep it within the text RFC line width. --- relative-json-pointer.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 0521fac2..05f6af31 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -98,10 +98,11 @@ - relative-json-pointer =/ non-negative-integer "#" + relative-json-pointer = origin-specification + relative-json-pointer =/ origin-specification "#" + origin-specification = non-negative-integer [index-manipulation] index-manipulation = ("+" / "-") non-negative-integer - non-negative-integer = %x30 / %x31-39 *( %x30-39 ) + non-negative-integer = %x30 / %x31-39 *( %x30-39 ) ; "0", or digits without a leading "0" ]]> From f833869e4b1e7943b6693b7d0e1da6c1d908daea Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Tue, 17 Jan 2023 08:51:29 -0800 Subject: [PATCH 451/780] Better Rel JSON Ptr ABNF per Austin Wright Also, use tag. --- relative-json-pointer.xml | 30 +++++++++++------------------- 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 05f6af31..cf152f57 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -92,27 +92,19 @@ length or start with a '/' (%x2F). Similarly, a JSON Pointer will never be ambiguous with the '#'. -
- - The ABNF syntax of a Relative JSON Pointer is: - - - - relative-json-pointer =/ origin-specification "#" - origin-specification = non-negative-integer [index-manipulation] - index-manipulation = ("+" / "-") non-negative-integer - non-negative-integer = %x30 / %x31-39 *( %x30-39 ) - ; "0", or digits without a leading "0" -]]> - - - where <json-pointer> follows the production defined in - RFC 6901, Section 3 ("Syntax"). - -
+ The ABNF syntax of a Relative JSON Pointer is: +
From 0fc1f305cf73cb9dbeb4613625bca13080018ad9 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Tue, 17 Jan 2023 09:49:57 -0800 Subject: [PATCH 452/780] Changelog for rel-json-ptr --- relative-json-pointer.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index cf152f57..c3851f4d 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -322,6 +322,12 @@ + + + Fix ABNF omission for using # with index manipulation + Clarify handling of leading "0" + + Add array forward and backward index manipulation From ee1fd04e2595e3f4c8fd35c6202bfa92fe28d893 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Tue, 17 Jan 2023 11:04:04 -0800 Subject: [PATCH 453/780] Update for next draft identifier. --- relative-json-pointer.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index c3851f4d..3bc5337a 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -12,7 +12,7 @@ - + Relative JSON Pointers From c54b3def5ef2f852d942157888c7fdf3ce8e644b Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Wed, 15 Feb 2023 14:40:31 -0800 Subject: [PATCH 454/780] Update main decription to include index adjustment. Somehow this was left out of the main syntax description paragraph entirely. --- relative-json-pointer.xml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 3bc5337a..858abe94 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -83,11 +83,13 @@ A Relative JSON Pointer is a Unicode string in UTF-8 encoding (see RFC 8259, Section 8), comprising a non-negative integer, - followed by either a '#' (%x23) character or a JSON Pointer - (RFC 6901). + an optional index adjustment consisting of '+' (%x2B) or '-' (%x2D) followed + by a positive integer, followed by either a '#' (%x23) character or + a JSON Pointer (RFC 6901). - The separation between the integer prefix and the JSON Pointer will + The separation between the integer prefix (with optional adjustment) + and the JSON Pointer will always be unambiguous, because a JSON Pointer must be either zero- length or start with a '/' (%x2F). Similarly, a JSON Pointer will never be ambiguous with the '#'. From 64e047f97df12de1c0370a7d7f02e3ce234f719c Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Wed, 15 Feb 2023 14:44:24 -0800 Subject: [PATCH 455/780] Only allow non-zero index adjustmetns The current draft allows for an index adjustment of "0" which creates ambiguity because "1/foo", "1+0/foo", and "1-0/foo" are now three different ways to write a pointer with the exact same effect. This complicates round-trips between textual and functional representations, the original text would need to be preserved in order to re-constitute it correctly. There is no need for this added complication. --- relative-json-pointer.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 858abe94..610e719a 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -103,9 +103,10 @@ ; json-pointer from RFC 6901 origin-specification = non-negative-integer [ index-manipulation ] - index-manipulation = ( "+" / "-" ) non-negative-integer - non-negative-integer = "0" / %x31-39 *DIGIT - ; zero, or digits without a leading zero + index-manipulation = ( "+" / "-" ) positive-integer + non-negative-integer = "0" / positive-integer + positive-integer = %x31-39 *DIGIT + ; digits without a leading zero ]]>
From c327b1978f82bcc7756ae36a671bde52e520409c Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Wed, 15 Feb 2023 14:48:03 -0800 Subject: [PATCH 456/780] Give a positive index adjustment example --- relative-json-pointer.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 610e719a..084a95e4 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -199,7 +199,7 @@ From ab0453ecd229e92d7108c53cbd5950ed85a6498b Mon Sep 17 00:00:00 2001 From: Austin Wright Date: Mon, 26 Dec 2022 13:45:12 -0500 Subject: [PATCH 457/780] Upgrade to rfc2xml v3 --- jsonschema-core.xml | 1305 +++++++++++++++++++++---------------------- 1 file changed, 639 insertions(+), 666 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 38d71473..2672c0d2 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -220,14 +220,14 @@ An instance has one of six primitive types, and a range of possible values depending on the type: - - A JSON "null" value - A "true" or "false" value, from the JSON "true" or "false" value - An unordered set of properties mapping a string to an instance, from the JSON "object" value - An ordered list of instances, from the JSON "array" value - An arbitrary-precision, base-10 decimal number value, from the JSON "number" value - A string of Unicode code points, from the JSON "string" value - +
+
null
A JSON "null" value
+
boolean
A "true" or "false" value, from the JSON "true" or "false" value
+
object
An unordered set of properties mapping a string to an instance, from the JSON "object" value
+
array
An ordered list of instances, from the JSON "array" value
+
number
An arbitrary-precision, base-10 decimal number value, from the JSON "number" value
+
string
A string of Unicode code points, from the JSON "string" value
+
Whitespace and formatting concerns, including different lexical @@ -258,17 +258,17 @@ Two JSON instances are said to be equal if and only if they are of the same type and have the same value according to the data model. Specifically, this means: - - both are null; or - both are true; or - both are false; or - both are strings, and are the same codepoint-for-codepoint; or - both are numbers, and have the same mathematical value; or - both are arrays, and have an equal value item-for-item; or - both are objects, and each property in one has exactly one property with +
    +
  • both are null; or
    • +
  • both are true; or
    • +
  • both are false; or
    • +
  • both are strings, and are the same codepoint-for-codepoint; or
    • +
  • both are numbers, and have the same mathematical value; or
    • +
  • both are arrays, and have an equal value item-for-item; or
    • +
  • both are objects, and each property in one has exactly one property with a key equal to the other's, and that other property has an equal - value. - + value.
    • +
Implied in this definition is that arrays must be the same length, @@ -316,27 +316,32 @@ Object properties that are applied to the instance are called keywords, or schema keywords. Broadly speaking, keywords fall into one of five categories: - - - control schema identification through setting a IRI - for the schema and/or changing how the base IRI is determined - - - produce a boolean result when applied to an instance - - - attach information to an instance for application use - - - apply one or more subschemas to a particular location - in the instance, and combine or modify their results - - - do not directly affect results, but reserve a place - for a specific purpose to ensure interoperability - - +
+
identifiers
+
+ control schema identification through setting a IRI + for the schema and/or changing how the base IRI is determined +
+
assertions
+
+ produce a boolean result when applied to an instance +
+
annotations
+
+ attach information to an instance for application use +
+
applicators
+
+ apply one or more subschemas to a particular location + in the instance, and combine or modify their results +
+
reserved locations
+
+ do not directly affect results, but reserve a place + for a specific purpose to ensure interoperability +
+
Keywords may fall into multiple categories, although applicators SHOULD only produce assertion results based on their subschemas' @@ -369,14 +374,19 @@ facilitate schema processing optimizations. They behave identically to the following schema objects (where "not" is part of the subschema application vocabulary defined in this document). - - - Always passes validation, as if the empty schema {} - - - Always fails validation, as if the schema { "not": {} } - - + +
+
true
+
+ Always passes validation, as if the empty schema {} +
+ +
false
+
+ Always fails validation, as if the schema { "not": {} } +
+
+ While the empty schema object is unambiguous, there are many possible equivalents to the "false" schema. Using the boolean values ensures that the intent is clear to both human readers @@ -449,18 +459,14 @@ Some keywords take schemas themselves, allowing JSON Schemas to be nested: -
- - - -
+]]> In this example document, the schema titled "array item" is a subschema, and the schema titled "root" is the root schema. @@ -584,19 +590,19 @@ schema authors SHOULD limit themselves to the following regular expression tokens: - - individual Unicode characters, as defined by the JSON specification; - simple character classes ([abc]), range character classes ([a-z]); - complemented character classes ([^abc], [^a-z]); - simple quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or - one), and their lazy versions ("+?", "*?", "??"); - range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at least x, at +
    +
  • individual Unicode characters, as defined by the JSON specification;
    • +
  • simple character classes ([abc]), range character classes ([a-z]);
    • +
  • complemented character classes ([^abc], [^a-z]);
    • +
  • simple quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or + one), and their lazy versions ("+?", "*?", "??");
    • +
  • range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at least x, at most y, occurrences), {x,} (x occurrences or more), and their lazy - versions; - the beginning-of-input ("^") and end-of-input ("$") anchors; - simple grouping ("(...)") and alternation ("|"). - + versions;
    • +
  • the beginning-of-input ("^") and end-of-input ("$") anchors;
    • +
  • simple grouping ("(...)") and alternation ("|").
    • +
Finally, implementations MUST NOT take regular expressions to be @@ -878,24 +884,20 @@ for a concise expression of use cases such as a function that might return either a string of a certain length or a null value: -
- - - - - If "maxLength" also restricted the instance type to be a string, - then this would be substantially more cumbersome to express because - the example as written would not actually allow null values. - Each keyword is evaluated separately unless explicitly specified - otherwise, so if "maxLength" restricted the instance to strings, - then including "null" in "type" would not have any useful effect. - -
+]]> + + If "maxLength" also restricted the instance type to be a string, + then this would be substantially more cumbersome to express because + the example as written would not actually allow null values. + Each keyword is evaluated separately unless explicitly specified + otherwise, so if "maxLength" restricted the instance to strings, + then including "null" in "type" would not have any useful effect. +
@@ -943,27 +945,27 @@ A collected annotation MUST include the following information: - - - The name of the keyword that produces the annotation - - - The instance location to which it is attached, as a JSON Pointer - - - The evaluation path, indicating how reference keywords - such as "$ref" were followed to reach the absolute schema location. - - - The absolute schema location of the attaching keyword, as a IRI. - This MAY be omitted if it is the same as the evaluation path - from above. - - - The attached value(s) - - +
    +
  • + The name of the keyword that produces the annotation +
    • +
  • + The instance location to which it is attached, as a JSON Pointer +
    • +
  • + The evaluation path, indicating how reference keywords + such as "$ref" were followed to reach the absolute schema location. +
    • +
  • + The absolute schema location of the attaching keyword, as a IRI. + This MAY be omitted if it is the same as the evaluation path + from above. +
    • +
  • + The attached value(s) +
    • +
Applications MAY make decisions on which of multiple annotation values @@ -975,12 +977,10 @@ For example, consider this schema, which uses annotations and assertions from the Validation specification: -
- - Note that some lines are wrapped for clarity. - - - + Note that some lines are wrapped for clarity. + + - -
+]]> In this example, both Feature A and Feature B make use of the re-usable "enabledToggle" schema. That schema uses the "title", "description", @@ -1068,9 +1066,7 @@ Note that the overall schema results may still include annotations collected from other schema locations. Given this schema: -
- - - -
+]]> - Against the instance "This is a string", the + Against the instance "This is a string", the title annotation "Integer Value" is discarded because the type assertion in that schema object fails. The title annotation "String Value" is kept, as the instance passes the string type assertions. @@ -1176,22 +1170,24 @@ The meta-schema serves two purposes: - - - The "$vocabulary" keyword, when it appears in a meta-schema, declares - which vocabularies are available to be used in schemas that refer - to that meta-schema. Vocabularies define keyword semantics, - as well as their general syntax. - - - A schema MUST successfully validate against its meta-schema, which - constrains the syntax of the available keywords. The syntax described - is expected to be compatible with the vocabularies declared; while - it is possible to describe an incompatible syntax, such a meta-schema - would be unlikely to be useful. - - +
+
Declaring the vocabularies in use
+
+ The "$vocabulary" keyword, when it appears in a meta-schema, declares + which vocabularies are available to be used in schemas that refer + to that meta-schema. Vocabularies define keyword semantics, + as well as their general syntax. +
+
Describing valid schema syntax
+
+ A schema MUST successfully validate against its meta-schema, which + constrains the syntax of the available keywords. The syntax described + is expected to be compatible with the vocabularies declared; while + it is possible to describe an incompatible syntax, such a meta-schema + would be unlikely to be useful. +
+
Meta-schemas are separate from vocabularies to allow for vocabularies to be combined in different ways, and for meta-schema authors @@ -1604,9 +1600,7 @@ integers, where the positive integer constraint is a subschema in "$defs": -
- - - -
+]]>
@@ -1765,9 +1757,7 @@ For example, consider this schema: -
- - - -
+]]> When an implementation encounters the <#/$defs/single> schema, it resolves the "$anchor" value as a fragment name against the current @@ -1831,13 +1819,11 @@ SHOULD NOT use such IRIs to identify embedded schema resources or locations within them. -
- - Consider the following schema document that contains another - schema resource embedded within it: - - - + Consider the following schema document that contains another + schema resource embedded within it: + + - -
+]]> The IRI "https://example.com/foo#/items" points to the "items" schema, which is an embedded resource. The canonical IRI of that schema @@ -1859,35 +1843,32 @@ to the correct object, but that object's IRI relative to its resource's canonical IRI is "https://example.com/bar#/additionalProperties". -
- - Now consider the following two schema resources linked by reference - using a IRI value for "$ref": - - - + Now consider the following two schema resources linked by reference + using a IRI value for "$ref": + + + - - - Here we see that "https://example.com/bar#/additionalProperties", - using a JSON Pointer fragment appended to the canonical IRI of - the "bar" schema resource, is still valid, while - "https://example.com/foo#/items/additionalProperties", which relied - on a JSON Pointer fragment appended to the canonical IRI of the - "foo" schema resource, no longer resolves to anything. - -
+]]> + + Here we see that "https://example.com/bar#/additionalProperties", + using a JSON Pointer fragment appended to the canonical IRI of + the "bar" schema resource, is still valid, while + "https://example.com/foo#/items/additionalProperties", which relied + on a JSON Pointer fragment appended to the canonical IRI of the + "foo" schema resource, no longer resolves to anything. + Note also that "https://example.com/foo#/items" is valid in both arrangements, but resolves to a different value. This IRI ends up @@ -2080,13 +2061,9 @@ Link header. An example of such a header would be: -
- - ; rel="describedby" - ]]> - -
+ ; rel="describedby" +]]>
@@ -2111,13 +2088,9 @@ of significance, the JSON Schema library name/version should precede the more generic HTTP library name (if any). For example: -
- - - -
+ Clients SHOULD be able to make requests with a "From" header so that server operators can contact the owner of a potentially misbehaving script. @@ -2155,20 +2128,20 @@ For schema author convenience, there are some exceptions among the keywords in this vocabulary: - - - "additionalProperties", whose behavior is defined in terms of - "properties" and "patternProperties" - - - "items", whose behavior is defined in terms of "prefixItems" - - - "contains", whose behavior is affected by the presence and value of - "minContains" - - +
    +
  • + "additionalProperties", whose behavior is defined in terms of + "properties" and "patternProperties" +
    • +
  • + "items", whose behavior is defined in terms of "prefixItems" +
    • +
  • + "contains", whose behavior is affected by the presence and value of + "minContains" +
    • +
@@ -2679,18 +2652,18 @@ Schema keywords typically operate independently, without affecting each other's outcomes. However, the keywords in this vocabulary are notable exceptions: - - - "unevaluatedItems", whose behavior is defined in terms of annotations - from "prefixItems", "items", "contains", and itself - - - "unevaluatedProperties", whose behavior is defined in terms of - annotations from "properties", "patternProperties", - "additionalProperties", "contains", and itself - - +
    +
  • + "unevaluatedItems", whose behavior is defined in terms of annotations + from "prefixItems", "items", "contains", and itself +
    • +
  • + "unevaluatedProperties", whose behavior is defined in terms of + annotations from "properties", "patternProperties", + "additionalProperties", "contains", and itself +
    • +
@@ -2802,20 +2775,25 @@ This specification defines three output formats. See the "Output Structure" section for the requirements of each format. - - - Flag - A boolean which simply indicates the overall validation result - with no further details. - - - List - Provides validation information in a flat list structure. - - - Hierarchical - Provides validation information in a hierarchical - structure that follows the evaluation paths generated while processing - the schema. - - + +
+
Flag
+
+ A boolean which simply indicates the overall validation result + with no further details. +
+
List
+
+ Provides validation information in a flat list structure. +
+
Hierarchical
+
+ Provides validation information in a hierarchical + structure that follows the evaluation paths generated while processing + the schema. +
+
+ An implementation MUST provide the "flag" format and SHOULD provide at least one of the "list" or "hierarchical" formats. Implementations SHOULD specify in their documentation which formats they support. @@ -2839,7 +2817,7 @@
- The evalutaion path to the schema object that produced the output unit. + The evaluation path to the schema object that produced the output unit. The value MUST be expressed as a JSON Pointer, and it MUST include any by-reference applicators such as "$ref" or "$dynamicRef". @@ -2848,13 +2826,9 @@ path only. -
- - - -
+]]> Note that this pointer may not be resolvable by the normal JSON Pointer process due to the inclusion of these by-reference applicator keywords. @@ -2879,13 +2853,10 @@ schema object. -
- - - -
+ The JSON key for this information is "schemaLocation". @@ -3010,19 +2981,18 @@ https://example.com/schemas/common#/$defs/allOf/1 The output MUST be an object containing a boolean property named "valid". When additional information about the result is required, the output MUST also contain "details" as described below. - - - "valid" - a boolean value indicating the overall validation success or failure - - - "details" - the collection of results produced by subschemas - - + +
+
valid
+
a boolean value indicating the overall validation success or failure
+ +
details
+
the collection of results produced by subschemas
+
+ For these examples, the following schema and instances will be used. -
- - - -
+]]> The failing instance will produce the following errors: - - - The value at "/foo" - evaluated at "/properties/foo/allOf/0" - by following the path "/properties/foo/allOf/0" - by the "required" keyword - is missing the property "unspecified-prop". - - - The value at "/foo/foo-prop" - evaluated at "/properties/foo/allOf/1/properties/foo-prop" - by following the path "/properties/foo/allOf/1/properties/foo-prop" - by the "const" keyword - is not the constant value 1. - - - The value at "/bar/bar-prop" - evaluated at "/$defs/bar/properties/bar-prop" - by following the path "/properties/bar/$ref/properties/bar-prop" - by the "type" keyword - is not a number. - - + +
    +
  • + The value at "/foo" + evaluated at "/properties/foo/allOf/0" + by following the path "/properties/foo/allOf/0" + by the "required" keyword + is missing the property "unspecified-prop". +
    • +
  • + The value at "/foo/foo-prop" + evaluated at "/properties/foo/allOf/1/properties/foo-prop" + by following the path "/properties/foo/allOf/1/properties/foo-prop" + by the "const" keyword + is not the constant value 1. +
    • +
  • + The value at "/bar/bar-prop" + evaluated at "/$defs/bar/properties/bar-prop" + by following the path "/properties/bar/$ref/properties/bar-prop" + by the "type" keyword + is not a number. +
    • +
+ "minimum" doesn't produce an error because it only operates on instances that are numbers. @@ -3120,63 +3090,63 @@ https://example.com/schemas/common#/$defs/allOf/1 The passing instance will produce the following annotations: - - - The keyword "title" - evaluated at "" - by following the path "" - will produce "root". - - - The keyword "properties" - evaluated at "" - by following the path "" - will produce ["foo", "bar"]. - - - The keyword "title" - evaluated at "/properties/foo" - by following the path "/properties/foo" - will produce "foo-title". - - - The keyword "properties" - evaluated at "/properties/foo/allOf/1" - by following the path "/properties/foo/allOf/1" - will produce ["foo-prop"]. - - - The keyword "additionalProperties" - evaluated at "/properties/foo/allOf/1" - by following the path "/properties/foo/allOf/1" - will produce ["unspecified-prop"]. - - - The keyword "title" - evaluated at "/properties/foo/allOf/1/properties/foo-prop" - by following the path "/properties/foo/allOf/1/properties/foo-prop" - will produce "foo-prop-title". - - - The keyword "title" - evaluated at "/$defs/bar" - by following the path "/properties/bar/$ref" - will produce "bar-title". - - - The keyword "properties" - evaluated at "/$defs/bar" - by following the path "/properties/var/$ref" - will produce ["bar-prop"]. - - - The keyword "title" - evaluated at "/$defs/bar/properties/bar-prop" - by following the path "/properties/bar/$ref/properties/bar-prop" - will produce "bar-prop-title". - - +
    +
  • + The keyword "title" + evaluated at "" + by following the path "" + will produce "root". +
    • +
  • + The keyword "properties" + evaluated at "" + by following the path "" + will produce ["foo", "bar"]. +
    • +
  • + The keyword "title" + evaluated at "/properties/foo" + by following the path "/properties/foo" + will produce "foo-title". +
    • +
  • + The keyword "properties" + evaluated at "/properties/foo/allOf/1" + by following the path "/properties/foo/allOf/1" + will produce ["foo-prop"]. +
    • +
  • + The keyword "additionalProperties" + evaluated at "/properties/foo/allOf/1" + by following the path "/properties/foo/allOf/1" + will produce ["unspecified-prop"]. +
    • +
  • + The keyword "title" + evaluated at "/properties/foo/allOf/1/properties/foo-prop" + by following the path "/properties/foo/allOf/1/properties/foo-prop" + will produce "foo-prop-title". +
    • +
  • + The keyword "title" + evaluated at "/$defs/bar" + by following the path "/properties/bar/$ref" + will produce "bar-title". +
    • +
  • + The keyword "properties" + evaluated at "/$defs/bar" + by following the path "/properties/var/$ref" + will produce ["bar-prop"]. +
    • +
  • + The keyword "title" + evaluated at "/$defs/bar/properties/bar-prop" + by following the path "/properties/bar/$ref/properties/bar-prop" + will produce "bar-prop-title". +
    • +
@@ -3184,15 +3154,11 @@ https://example.com/schemas/common#/$defs/allOf/1 needs to be fulfilled. For this format, all other information is explicitly omitted. -
- - - -
+]]> Because no errors or annotations are returned with this format, it is RECOMMENDED that implementations use short-circuiting logic to return @@ -3220,9 +3186,7 @@ https://example.com/schemas/common#/$defs/allOf/1 from this format, however implementations MAY choose to include them for completeness. -
- - - -
+]]>
@@ -3339,9 +3301,7 @@ https://example.com/schemas/common#/$defs/allOf/1 The location properties of the root output unit MAY be omitted. -
- - - -
+
@@ -3582,60 +3541,77 @@ https://example.com/schemas/common#/$defs/allOf/1
The proposed MIME media type for JSON Schema is defined as follows: - - - Type name: application - Subtype name: schema+json - Required parameters: N/A - - Encoding considerations: Encoding considerations are - identical to those specified for the "application/json" - media type. See JSON. - - - Security considerations: See above. - - - Interoperability considerations: See Sections - , - , and - above. - - - Fragment identifier considerations: See - - - +
+
Type name:
+
application
+ +
Subtype name:
+
schema+json
+ +
Required parameters:
+
N/A
+ +
Encoding considerations:
+
+ Encoding considerations are + identical to those specified for the "application/json" + media type. See JSON. +
+ +
Security considerations:
+
See above.
+ +
Interoperability considerations:
+
+ See Sections + , + , and + above. +
+ +
Fragment identifier considerations:
+
+ See +
+
The proposed MIME media type for JSON Schema Instances that require a JSON Schema-specific media type is defined as follows: - - - Type name: application - Subtype name: schema-instance+json - Required parameters: N/A - - Encoding considerations: Encoding considerations are - identical to those specified for the "application/json" - media type. See JSON. - - - Security considerations: See above. - - - Interoperability considerations: See Sections - , - , and - above. - - - Fragment identifier considerations: See - - +
+
Type name:
+
application
+ +
Subtype name:
+
schema-instance+json
+ +
Required parameters:
+
N/A
+ +
Encoding considerations:
+
+ Encoding considerations are + identical to those specified for the "application/json" + media type. See JSON. +
+ +
Security considerations:
+
See above.
+ +
Interoperability considerations:
+
+ See Sections + , + , and + above. +
+ +
Fragment identifier considerations:
+
See
+
@@ -3729,14 +3705,12 @@ https://example.com/schemas/common#/$defs/allOf/1
-
- - Consider the following schema, which shows "$id" being used to identify - both the root schema and various subschemas, and "$anchor" being used - to define plain name fragment identifiers. - - - + Consider the following schema, which shows "$id" being used to identify + both the root schema and various subschemas, and "$anchor" being used + to define plain name fragment identifiers. + + - -
+]]> The schemas at the following IRI-encoded JSON Pointers (relative to the root schema) have the following base IRIs, and are identifiable by any listed IRI in accordance with and above. - - - - - - https://example.com/root.json - - - https://example.com/root.json# - - - - - - https://example.com/root.json - - https://example.com/root.json#foo - - - https://example.com/root.json#/$defs/A - - - - - - https://example.com/other.json - - https://example.com/other.json# - - - https://example.com/root.json#/$defs/B - - - - - - https://example.com/other.json - - https://example.com/other.json#bar - - - https://example.com/other.json#/$defs/X - - - https://example.com/root.json#/$defs/B/$defs/X - - - - - - https://example.com/t/inner.json - - https://example.com/t/inner.json#bar - - - https://example.com/t/inner.json# - - - https://example.com/other.json#/$defs/Y - - - https://example.com/root.json#/$defs/B/$defs/Y - - - - - - - urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f - - - urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f# - - - https://example.com/root.json#/$defs/C - - - - - +
+
# (document root)
+
+
+
canonical (and base) IRI"
+
https://example.com/root.json
+ +
canonical resource IRI plus pointer fragment"
+
https://example.com/root.json#
+
+
+ +
#/$defs/A
+
+
+
base IRI
+
https://example.com/root.json
+ +
canonical resource IRI plus plain fragment
+
https://example.com/root.json#foo
+ +
canonical resource IRI plus pointer fragment
+
https://example.com/root.json#/$defs/A
+
+
+ +
#/$defs/B
+
+
+
canonical (and base) IRI
+
https://example.com/other.json
+ +
canonical resource IRI plus pointer fragment
+
https://example.com/other.json#
+ +
base IRI of enclosing (root.json) resource plus fragment
+
https://example.com/root.json#/$defs/B
+
+
+ +
#/$defs/B/$defs/X
+
+
+
base IRI
+
https://example.com/other.json
+ +
canonical resource IRI plus plain fragment
+
https://example.com/other.json#bar
+ +
canonical resource IRI plus pointer fragment
+
https://example.com/other.json#/$defs/X
+ +
base IRI of enclosing (root.json) resource plus fragment
+
https://example.com/root.json#/$defs/B/$defs/X
+
+
+ +
#/$defs/B/$defs/Y
+
+
+
canonical (and base) IRI
+
https://example.com/t/inner.json
+ +
canonical IRI plus plain fragment
+
https://example.com/t/inner.json#bar
+ +
canonical IRI plus pointer fragment
+
https://example.com/t/inner.json#
+ +
base IRI of enclosing (other.json) resource plus fragment
+
https://example.com/other.json#/$defs/Y
+ +
base IRI of enclosing (root.json) resource plus fragment
+
https://example.com/root.json#/$defs/B/$defs/Y
+
+
+ +
#/$defs/C
+
+
+
canonical (and base) IRI
+
urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f
+ +
canonical IRI plus pointer fragment
+
urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f#
+ +
base IRI of enclosing (root.json) resource plus fragment
+
https://example.com/root.json#/$defs/C
+
+
+
Note: The fragment part of the IRI does not make it canonical or non-canonical, rather, the base IRI used (as part of the full IRI with any fragment) is what @@ -3911,17 +3894,15 @@ https://example.com/schemas/common#/$defs/allOf/1
-
- + Consider the following two schemas describing a simple recursive tree structure, where each node in the tree can have a "data" field of any type. The first schema allows and ignores other instance properties. The second is more strict and only allows the "data" and "children" properties. An example instance with "data" misspelled as "daat" is also shown. - - - + - -
+]]> When we load these two schemas, we will notice the "$dynamicAnchor" named "node" (note the lack of "#" as this is just the name) present in each, resulting in the following full schema IRIs: - - "https://example.com/tree#node" - "https://example.com/strict-tree#node" - +
    +
  • "https://example.com/tree#node"
    • +
  • "https://example.com/strict-tree#node"
    • +
In addition, JSON Schema implementations keep track of the fact that these fragments were created with "$dynamicAnchor". @@ -3981,22 +3960,22 @@ https://example.com/schemas/common#/$defs/allOf/1 At this point, the evaluation path is "#/$ref/properties/children/items/$dynamicRef", with a dynamic scope containing (from the outermost scope to the innermost): - - "https://example.com/strict-tree#" - "https://example.com/tree#" - "https://example.com/tree#/properties/children" - "https://example.com/tree#/properties/children/items" - +
    +
  1. "https://example.com/strict-tree#"
    2. +
  2. "https://example.com/tree#"
    3. +
  3. "https://example.com/tree#/properties/children"
    4. +
  4. "https://example.com/tree#/properties/children/items"
    5. +
Since we are looking for a plain name fragment, which can be defined anywhere within a schema resource, the JSON Pointer fragments are irrelevant to this check. That means that we can remove those fragments and eliminate consecutive duplicates, producing: - - "https://example.com/strict-tree" - "https://example.com/tree" - +
    +
  1. "https://example.com/strict-tree"
    2. +
  2. "https://example.com/tree"
    3. +
In this case, the outermost resource also has a "node" fragment @@ -4109,12 +4088,10 @@ https://example.com/schemas/common#/$defs/allOf/1 outside of vocabularies, making them unsuitable for use except in a specific environment in which they are understood. -
- - This meta-schema combines several vocabularies for general use. - - - + This meta-schema combines several vocabularies for general use. + + - -
-
- - This meta-schema describes only a single extension vocabulary. - - - + + This meta-schema describes only a single extension vocabulary. + + - -
+]]> As shown above, even though each of the single-vocabulary meta-schemas referenced in the general-use meta-schema's "allOf" declares its @@ -4207,16 +4178,14 @@ https://example.com/schemas/common#/$defs/allOf/1 is to create an annotation keyword for use in the same schema object alongside of a reference keyword such as "$ref". -
- - For example, here is a hypothetical keyword for determining - whether a code generator should consider the reference - target to be a distinct class, and how those classes are related. - Note that this example is solely for illustrative purposes, and is - not intended to propose a functional code generation keyword. - - - + For example, here is a hypothetical keyword for determining + whether a code generator should consider the reference + target to be a distinct class, and how those classes are related. + Note that this example is solely for illustrative purposes, and is + not intended to propose a functional code generation keyword. + + - -
+]]> Here, this schema represents some sort of object-oriented class. The first reference in the "allOf" is noted as the base class. @@ -4285,140 +4252,146 @@ https://example.com/schemas/common#/$defs/allOf/1
-
+
This section to be removed before leaving Internet-Draft status. - - - - - "contains" now applies to objects as well as arrays - Use IRIs instead of URIs - Remove bookending requirement for "$dynamicRef" - Add "propertyDependencies" keyword - - - - - Improve and clarify the "type", "contains", "unevaluatedProperties", and "unevaluatedItems" keyword explanations - Clarify various aspects of "canonical URIs" - Comment on ambiguity around annotations and "additionalProperties" - Clarify Vocabularies need not be formally defined - Remove references to remaining media-type parameters - Fix multiple examples - - - - - "$schema" MAY change for embedded resources - Array-value "items" functionality is now "prefixItems" - "items" subsumes the old function of "additionalItems" - "contains" annotation behavior, and "contains" and "unevaluatedItems" interactions now specified - Rename $recursive* to $dynamic*, with behavior modification - $dynamicAnchor defines a fragment like $anchor - $dynamic* (previously $recursive) no longer use runtime base URI determination - Define Compound Schema Documents (bundle) and processing - Reference ECMA-262, 11th edition for regular expression support - Regular expression should support unicode - Remove media type parameters - Specify Unknown keywords are collected as annotations - Moved "unevaluatedItems" and "unevaluatedProperties" from core into their own vocabulary - - - - - Update to RFC 8259 for JSON specification - Moved "definitions" from the Validation specification here as "$defs" - Moved applicator keywords from the Validation specification as their own vocabulary - Moved the schema form of "dependencies" from the Validation specification as "dependentSchemas" - Formalized annotation collection - Specified recommended output formats - Defined keyword interactions in terms of annotation and assertion results - Added "unevaluatedProperties" and "unevaluatedItems" - Define "$ref" behavior in terms of the assertion, applicator, and annotation model - Allow keywords adjacent to "$ref" - Note undefined behavior for "$ref" targets involving unknown keywords - Add recursive referencing, primarily for meta-schema extension - Add the concept of formal vocabularies, and how they can be recognized through meta-schemas - Additional guidance on initial base URIs beyond network retrieval - Allow "schema" media type parameter for "application/schema+json" - Better explanation of media type parameters and the HTTP Accept header - Use "$id" to establish canonical and base absolute-URIs only, no fragments - Replace plain-name-fragment-only form of "$id" with "$anchor" - Clarified that the behavior of JSON Pointers across "$id" boundary is unreliable - - - - - This draft is purely a clarification with no functional changes - Emphasized annotations as a primary usage of JSON Schema - Clarified $id by use cases - Exhaustive schema identification examples - Replaced "external referencing" with how and when an implementation might know of a schema from another document - Replaced "internal referencing" with how an implementation should recognized schema identifiers during parsing - Dereferencing the former "internal" or "external" references is always the same process - Minor formatting improvements - - - - - Make the concept of a schema keyword vocabulary more clear - Note that the concept of "integer" is from a vocabulary, not the data model - Classify keywords as assertions or annotations and describe their general behavior - Explain the boolean schemas in terms of generalized assertions - Reserve "$comment" for non-user-visible notes about the schema - Wording improvements around "$id" and fragments - Note the challenges of extending meta-schemas with recursive references - Add "application/schema-instance+json" media type - Recommend a "schema" link relation / parameter instead of "profile" - - - - - Updated intro - Allowed for any schema to be a boolean - "$schema" SHOULD NOT appear in subschemas, although that may change - Changed "id" to "$id"; all core keywords prefixed with "$" - Clarify and formalize fragments for application/schema+json - Note applicability to formats such as CBOR that can be represented in the JSON data model - - - - - Updated references to JSON - Updated references to HTTP - Updated references to JSON Pointer - Behavior for "id" is now specified in terms of RFC3986 - Aligned vocabulary usage for URIs with RFC3986 - Removed reference to draft-pbryan-zyp-json-ref-03 - Limited use of "$ref" to wherever a schema is expected - Added definition of the "JSON Schema data model" - Added additional security considerations - Defined use of subschema identifiers for "id" - Rewrote section on usage with HTTP - Rewrote section on usage with rel="describedBy" and rel="profile" - Fixed numerous invalid examples - - - - - Salvaged from draft v3. - Split validation keywords into separate document. - Split hypermedia keywords into separate document. - Initial post-split draft. - Mandate the use of JSON Reference, JSON Pointer. - Define the role of "id". Define URI resolution scope. - Add interoperability considerations. - - - - - Initial draft. - - - - + +
+
    +
  • "contains" now applies to objects as well as arrays
    • +
  • Use IRIs instead of URIs
    • +
  • Remove bookending requirement for "$dynamicRef"
    • +
  • Add "propertyDependencies" keyword
    • +
+
+ +
+
    +
  • Improve and clarify the "type", "contains", "unevaluatedProperties", and "unevaluatedItems" keyword explanations
    • +
  • Clarify various aspects of "canonical URIs"
    • +
  • Comment on ambiguity around annotations and "additionalProperties"
    • +
  • Clarify Vocabularies need not be formally defined
    • +
  • Remove references to remaining media-type parameters
    • +
  • Fix multiple examples
    • +
+
+ +
+
    +
  • "$schema" MAY change for embedded resources
    • +
  • Array-value "items" functionality is now "prefixItems"
    • +
  • "items" subsumes the old function of "additionalItems"
    • +
  • "contains" annotation behavior, and "contains" and "unevaluatedItems" interactions now specified
    • +
  • Rename $recursive* to $dynamic*, with behavior modification
    • +
  • $dynamicAnchor defines a fragment like $anchor
    • +
  • $dynamic* (previously $recursive) no longer use runtime base URI determination
    • +
  • Define Compound Schema Documents (bundle) and processing
    • +
  • Reference ECMA-262, 11th edition for regular expression support
    • +
  • Regular expression should support unicode
    • +
  • Remove media type parameters
    • +
  • Specify Unknown keywords are collected as annotations
    • +
  • Moved "unevaluatedItems" and "unevaluatedProperties" from core into their own vocabulary
    • +
+
+ +
+
    +
  • Update to RFC 8259 for JSON specification
    • +
  • Moved "definitions" from the Validation specification here as "$defs"
    • +
  • Moved applicator keywords from the Validation specification as their own vocabulary
    • +
  • Moved the schema form of "dependencies" from the Validation specification as "dependentSchemas"
    • +
  • Formalized annotation collection
    • +
  • Specified recommended output formats
    • +
  • Defined keyword interactions in terms of annotation and assertion results
    • +
  • Added "unevaluatedProperties" and "unevaluatedItems"
    • +
  • Define "$ref" behavior in terms of the assertion, applicator, and annotation model
    • +
  • Allow keywords adjacent to "$ref"
    • +
  • Note undefined behavior for "$ref" targets involving unknown keywords
    • +
  • Add recursive referencing, primarily for meta-schema extension
    • +
  • Add the concept of formal vocabularies, and how they can be recognized through meta-schemas
    • +
  • Additional guidance on initial base URIs beyond network retrieval
    • +
  • Allow "schema" media type parameter for "application/schema+json"
    • +
  • Better explanation of media type parameters and the HTTP Accept header
    • +
  • Use "$id" to establish canonical and base absolute-URIs only, no fragments
    • +
  • Replace plain-name-fragment-only form of "$id" with "$anchor"
    • +
  • Clarified that the behavior of JSON Pointers across "$id" boundary is unreliable
    • +
+
+ +
+
    +
  • This draft is purely a clarification with no functional changes
    • +
  • Emphasized annotations as a primary usage of JSON Schema
    • +
  • Clarified $id by use cases
    • +
  • Exhaustive schema identification examples
    • +
  • Replaced "external referencing" with how and when an implementation might know of a schema from another document
    • +
  • Replaced "internal referencing" with how an implementation should recognized schema identifiers during parsing
    • +
  • Dereferencing the former "internal" or "external" references is always the same process
    • +
  • Minor formatting improvements
    • +
+
+ +
+
    +
  • Make the concept of a schema keyword vocabulary more clear
    • +
  • Note that the concept of "integer" is from a vocabulary, not the data model
    • +
  • Classify keywords as assertions or annotations and describe their general behavior
    • +
  • Explain the boolean schemas in terms of generalized assertions
    • +
  • Reserve "$comment" for non-user-visible notes about the schema
    • +
  • Wording improvements around "$id" and fragments
    • +
  • Note the challenges of extending meta-schemas with recursive references
    • +
  • Add "application/schema-instance+json" media type
    • +
  • Recommend a "schema" link relation / parameter instead of "profile"
    • +
+
+ +
+
    +
  • Updated intro
    • +
  • Allowed for any schema to be a boolean
    • +
  • "$schema" SHOULD NOT appear in subschemas, although that may change
    • +
  • Changed "id" to "$id"; all core keywords prefixed with "$"
    • +
  • Clarify and formalize fragments for application/schema+json
    • +
  • Note applicability to formats such as CBOR that can be represented in the JSON data model
    • +
+
+ +
+
    +
  • Updated references to JSON
    • +
  • Updated references to HTTP
    • +
  • Updated references to JSON Pointer
    • +
  • Behavior for "id" is now specified in terms of RFC3986
    • +
  • Aligned vocabulary usage for URIs with RFC3986
    • +
  • Removed reference to draft-pbryan-zyp-json-ref-03
    • +
  • Limited use of "$ref" to wherever a schema is expected
    • +
  • Added definition of the "JSON Schema data model"
    • +
  • Added additional security considerations
    • +
  • Defined use of subschema identifiers for "id"
    • +
  • Rewrote section on usage with HTTP
    • +
  • Rewrote section on usage with rel="describedBy" and rel="profile"
    • +
  • Fixed numerous invalid examples
    • +
+
+ +
+
    +
  • Salvaged from draft v3.
    • +
  • Split validation keywords into separate document.
    • +
  • Split hypermedia keywords into separate document.
    • +
  • Initial post-split draft.
    • +
  • Mandate the use of JSON Reference, JSON Pointer.
    • +
  • Define the role of "id". Define URI resolution scope.
    • +
  • Add interoperability considerations.
    • +
+
+ +
+
    +
  • Initial draft.
    • +
+
From d21c0e806300797085d77e15af79499ac899a085 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 8 Mar 2023 10:23:01 +1300 Subject: [PATCH 458/780] reserve dollar keywords for core vocab --- jsonschema-core.xml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 2672c0d2..61d9fff3 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -1157,9 +1157,8 @@ . - While the "$" prefix is not formally reserved for the Core vocabulary, - it is RECOMMENDED that extension keywords (in vocabularies or otherwise) - begin with a character other than "$" to avoid possible future collisions. + The "$" prefix is reserved for use by the Core vocabulary. + Vocabulary extensions MUST NOT define new keywords that begin with "$".
From b5ca87109ea60233a7a65ab0a6bd36bb85a01691 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 14 Mar 2023 10:37:27 +1300 Subject: [PATCH 459/780] add minimum open time action for PRs --- .github/workflows/minimum-open-time.yml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 .github/workflows/minimum-open-time.yml diff --git a/.github/workflows/minimum-open-time.yml b/.github/workflows/minimum-open-time.yml new file mode 100644 index 00000000..125af162 --- /dev/null +++ b/.github/workflows/minimum-open-time.yml @@ -0,0 +1,18 @@ +on: + - pull_request + - workflow_dispatch + # not sure about scheduling only on PRs. See https://github.com/orgs/community/discussions/49960 + # - schedule + # - cron: '0 * * * *' + +jobs: + require-minimum-open-time: + runs-on: ubuntu-latest + name: Require Minimum Open Time + steps: + - uses: actions/checkout@v2 + - uses: gregsdennis/minimum-open-time@main + with: + time: 2w # see below for options + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} \ No newline at end of file From 70e4ad06e2a736d80a34b136b96ff0a30e8d5374 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 14 Mar 2023 10:42:31 +1300 Subject: [PATCH 460/780] add action name --- .github/workflows/minimum-open-time.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/minimum-open-time.yml b/.github/workflows/minimum-open-time.yml index 125af162..a8f2c6b3 100644 --- a/.github/workflows/minimum-open-time.yml +++ b/.github/workflows/minimum-open-time.yml @@ -1,3 +1,4 @@ +name: PR Policy on: - pull_request - workflow_dispatch From b56a9d39edf3b1cbde6d9ad4a8ad52d5da683a9e Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 17 Mar 2023 11:33:15 +1300 Subject: [PATCH 461/780] update cron to once daily; add PR condition on job --- .github/workflows/minimum-open-time.yml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/.github/workflows/minimum-open-time.yml b/.github/workflows/minimum-open-time.yml index a8f2c6b3..b856bfce 100644 --- a/.github/workflows/minimum-open-time.yml +++ b/.github/workflows/minimum-open-time.yml @@ -2,12 +2,13 @@ name: PR Policy on: - pull_request - workflow_dispatch - # not sure about scheduling only on PRs. See https://github.com/orgs/community/discussions/49960 - # - schedule - # - cron: '0 * * * *' + # scheduling only on PRs is not directly supported. See https://github.com/orgs/community/discussions/49960 + - schedule + - cron: '0 0 * * *' # once daily jobs: require-minimum-open-time: + if: github.event_name == 'pull_request' runs-on: ubuntu-latest name: Require Minimum Open Time steps: From a88ac26aaadab6092d6793d7095ed6d06bf442fe Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 21 Mar 2023 08:44:54 +1300 Subject: [PATCH 462/780] move comment to different line --- .github/workflows/minimum-open-time.yml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/workflows/minimum-open-time.yml b/.github/workflows/minimum-open-time.yml index b856bfce..5c4cda13 100644 --- a/.github/workflows/minimum-open-time.yml +++ b/.github/workflows/minimum-open-time.yml @@ -4,7 +4,8 @@ on: - workflow_dispatch # scheduling only on PRs is not directly supported. See https://github.com/orgs/community/discussions/49960 - schedule - - cron: '0 0 * * *' # once daily + # once daily + - cron: '0 0 * * *' jobs: require-minimum-open-time: From b5b342f39cdf96dd3b9b8a5557fa049df5cacea8 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 21 Mar 2023 08:46:14 +1300 Subject: [PATCH 463/780] maybe just no comment --- .github/workflows/minimum-open-time.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/.github/workflows/minimum-open-time.yml b/.github/workflows/minimum-open-time.yml index 5c4cda13..7899ee64 100644 --- a/.github/workflows/minimum-open-time.yml +++ b/.github/workflows/minimum-open-time.yml @@ -4,7 +4,6 @@ on: - workflow_dispatch # scheduling only on PRs is not directly supported. See https://github.com/orgs/community/discussions/49960 - schedule - # once daily - cron: '0 0 * * *' jobs: From 810846a7d860c625d9b0376e164cda9ead408e5a Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 21 Mar 2023 08:49:15 +1300 Subject: [PATCH 464/780] maybe bad yaml? --- .github/workflows/minimum-open-time.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/workflows/minimum-open-time.yml b/.github/workflows/minimum-open-time.yml index 7899ee64..8ed95581 100644 --- a/.github/workflows/minimum-open-time.yml +++ b/.github/workflows/minimum-open-time.yml @@ -1,9 +1,9 @@ name: PR Policy on: - - pull_request - - workflow_dispatch + pull_request + workflow_dispatch # scheduling only on PRs is not directly supported. See https://github.com/orgs/community/discussions/49960 - - schedule + schedule - cron: '0 0 * * *' jobs: From 9fb69c5e1623c66c1247f19fadcdbcea4b45d34c Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 21 Mar 2023 09:02:37 +1300 Subject: [PATCH 465/780] maybe it doesn't like the comment there --- .github/workflows/minimum-open-time.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/minimum-open-time.yml b/.github/workflows/minimum-open-time.yml index 8ed95581..cfe9de47 100644 --- a/.github/workflows/minimum-open-time.yml +++ b/.github/workflows/minimum-open-time.yml @@ -1,8 +1,8 @@ name: PR Policy +# scheduling only on PRs is not directly supported. See https://github.com/orgs/community/discussions/49960 on: pull_request workflow_dispatch - # scheduling only on PRs is not directly supported. See https://github.com/orgs/community/discussions/49960 schedule - cron: '0 0 * * *' From 18e58d6452602d2edb7b50903150edbced8e76ca Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 21 Mar 2023 09:03:33 +1300 Subject: [PATCH 466/780] indention maybe? --- .github/workflows/minimum-open-time.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/minimum-open-time.yml b/.github/workflows/minimum-open-time.yml index cfe9de47..3354bf95 100644 --- a/.github/workflows/minimum-open-time.yml +++ b/.github/workflows/minimum-open-time.yml @@ -4,7 +4,7 @@ on: pull_request workflow_dispatch schedule - - cron: '0 0 * * *' + - cron: '0 0 * * *' jobs: require-minimum-open-time: From 1525761bacfd94d76dc6ec77a3fe5f06db5e4392 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 21 Mar 2023 09:08:35 +1300 Subject: [PATCH 467/780] colons --- .github/workflows/minimum-open-time.yml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/.github/workflows/minimum-open-time.yml b/.github/workflows/minimum-open-time.yml index 3354bf95..d2a99b60 100644 --- a/.github/workflows/minimum-open-time.yml +++ b/.github/workflows/minimum-open-time.yml @@ -1,10 +1,10 @@ name: PR Policy -# scheduling only on PRs is not directly supported. See https://github.com/orgs/community/discussions/49960 on: - pull_request - workflow_dispatch - schedule - - cron: '0 0 * * *' + - pull_request + - workflow_dispatch + # scheduling only on PRs is not directly supported. See https://github.com/orgs/community/discussions/49960 + - schedule: + - cron: '0 0 * * *' # once daily jobs: require-minimum-open-time: From e3ee2d6ac3d442b12f38ee8e68bc501f3aa80e95 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 21 Mar 2023 09:09:41 +1300 Subject: [PATCH 468/780] invalid type for 'on' --- .github/workflows/minimum-open-time.yml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/workflows/minimum-open-time.yml b/.github/workflows/minimum-open-time.yml index d2a99b60..f279bd8a 100644 --- a/.github/workflows/minimum-open-time.yml +++ b/.github/workflows/minimum-open-time.yml @@ -1,10 +1,10 @@ name: PR Policy on: - - pull_request - - workflow_dispatch + pull_request + workflow_dispatch # scheduling only on PRs is not directly supported. See https://github.com/orgs/community/discussions/49960 - - schedule: - - cron: '0 0 * * *' # once daily + schedule: + - cron: '0 0 * * *' # once daily jobs: require-minimum-open-time: From 2a7bd467289298469d66b1fde77046332fa6fd0e Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 21 Mar 2023 09:13:06 +1300 Subject: [PATCH 469/780] more colons --- .github/workflows/minimum-open-time.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/minimum-open-time.yml b/.github/workflows/minimum-open-time.yml index f279bd8a..0dfa1255 100644 --- a/.github/workflows/minimum-open-time.yml +++ b/.github/workflows/minimum-open-time.yml @@ -1,7 +1,7 @@ name: PR Policy on: - pull_request - workflow_dispatch + pull_request: + workflow_dispatch: # scheduling only on PRs is not directly supported. See https://github.com/orgs/community/discussions/49960 schedule: - cron: '0 0 * * *' # once daily From 4089b1ea26025d1b15373e0244804ea01c82810b Mon Sep 17 00:00:00 2001 From: Austin Wright Date: Fri, 16 Dec 2022 15:01:50 -0700 Subject: [PATCH 470/780] Add Use Cases and Requirements --- jsonschema-use-cases.xml | 310 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 310 insertions(+) create mode 100644 jsonschema-use-cases.xml diff --git a/jsonschema-use-cases.xml b/jsonschema-use-cases.xml new file mode 100644 index 00000000..55cb770d --- /dev/null +++ b/jsonschema-use-cases.xml @@ -0,0 +1,310 @@ + + + + + +]> + + + + + + + + + + + JSON Schema: Use Cases and Requirements + + +
+ aaa@bzfx.net +
+ + + + JSON Schema + JSON + Schema + Hyper Schema + Hypermedia + + + + To foster development of JSON Schema, this document contains a list of use cases and requirements that may be used to inform its development and evolution. + + + + + The issues list for this document can be found at + . + + + For additional information, see . + + + To provide feedback, use this issue tracker, the communication methods listed on the + homepage, or email the document editors. + + + + + +
+ + JSON Schema is a JSON media type for defining the structure of JSON data. JSON Schema + is intended to define validation, documentation, hyperlink navigation, and interaction + control of JSON data. + + + This document elaborates in detail what this means, and the specific use cases that shall be supported. + +
+ +
+ + Objectives specify the class of problems that are in the scope of the specification. + + + + Use Cases catalog a variety of personal objectives that users may have, due to various motivations and constraints, that the specification shall accommodate, but without prescribing a specific design or implementation. + + + + Requirements list functional, non-functional, and quality requirements, the use cases they may be derived from/related to, and reference how each use case is implemented. Requirements are not detailed at this time but may be specified in the future. + +
+ +
+ + JSON Schema shall be built to support the following objectives, supporting expansion into uses not currently described by any use case, but which fall within the objectives. + + +
+ + The first objective of JSON Schema is to describe sets of JSON documents; specifically, to notate a language of JSON documents using a machine-readable, set-builder notation. + This covers the key use case of validating input using a validator, as well as numerous other tools that depend on describing to each other which kinds of JSON documents are and are not acceptable. + +
+ +
+ + The second objective of JSON Schema is to map an input JSON document to an arbitrary output described by the user. + Annotations may be combined with validation (in the same schema) to specify the domain of inputs for which an output is defined. + This covers the key use case of documenting the meaning of properties and values in JSON documents, and other uses where the input document is being interpreted in some fashion. + +
+ +
+ + JSON is a technology standardized as a part of a larger ecosystem of Internet technology, and likewise, JSON Schema may also specify its role in this ecosystem; for example, use in HTTP, or the meaning of media type parameters. + +
+ +
+ + Use cases or requirements that do not advance these objectives are likely out of scope, and better suited in separate work that references JSON Schema. + + + For example, a method of describing an API interface would exceed the scope of JSON Schema, although JSON Schema may be used as a part of such a description, such as when the API is using JSON and needs a way to describe these JSON documents. + +
+ +
+ +
+ + JSON Schema shall be written to standardize these use cases, or shall accommodate implementations targeted at these uses. + + +
+ + Structural validation refers to the "structure" that a JSON document is supposed to follow, such as which properties must exist, what types of values are expected where, and what they must look like. Constraints cannot read values elsewhere in the document (e.g. to compare two values for equality), though constraints may depend on "where" the value is found (e.g. specific properties or array items must be a number). + + + More specifically, structural validation is any validation that can be performed with a context-free grammar that follows JSON semantics, such that any forms that are equal according to JSON will produce the same result. + + + Validators that support structural validation can entirely replace generic grammar languages such as ABNF, and will guarantee compliance with JSON semantics. Likewise, schemas whose validation rules are limited to structural validation can be executed using a deterministic pushdown automata, guaranteeing a result in proportional time without error. + + + The following features of JSON are structural validation: + + + JSON primitive type (string, object, etc) + Minimum or maximum in a linear range of values + Minimum or maximum lengths (number of characters, digits, items, or properties) + Literal/constant values or alternate/enumerated values + Pattern matching strings by a regular expression (including object keys) + Logic operators (union, intersection, difference) + Descent into object properties and array items (recursively) + + + Multiple forms that are value-equal according to JSON are not distinguishable under this use-case. This includes the ordering of properties in an object, character escapes in strings, and whitespace. + +
+ +
+ + There is a need to annotate values within a JSON document: for machine readability, and for documentation purposes. + Given a document and directions for annotating it, you should should be able to: + + + document the meaning of a property, + suggest a default value for new documents of a given type, + fill in missing values (in objects or arrays) with values of equivalent meaning, + generate a list of hyperlinks, + or declare relationships between data. + + + A schema may be used to describe a machine-readable profile of JSON document. Even when two schemas identify the same set of JSON documents; depending on the context, a given JSON document may be a profile of one but not the other. + +
+ +
+ + Developers may write an application that uses a JSON Schema internally as a domain-specific language, so that the schema is only used inside a single application by a single party. By using a declarative language, the application requirements can be optimized better than a human could do. + + + Application authors may use a schema to define custom hooks and processing for the JSON (without need for standardizing the customization). + + + The only interoperability consideration here is that updates to the validator library must not change the validation result of any JSON documents, unless the developer specifically opts into such a breaking change (e.g. by upgrading the library to a new major version number). + +
+ +
+ + A development team maintains two similar applications, but for different platforms, in different languages. The application downloads and reads from a common repository of JSON documents. They want to make sure that both applications accept or reject JSON with identical behavior, so they write a single JSON Schema and deploy it to both applications. + + + The only interoperability consideration here is that the two applications, given the same schema, must both be reasonably expected to support the same behavior and operate in the same manner. + +
+ +
+ + When a server declares constraints that a submission must meet, there is a need for the user interface to receive these constraints to provide model-driven validation of permissible values, making the form more accessible to the user. + + + For example, if a value is specified to be a date, the form field where the value is specified can provide immediate feedback if an invalid date is entered, and even offer a date picker to help the user input a correct value. + + + Weak interoperability requirements can hamper the user experience within this use case. If the schema is ambiguous in any way, or is up to the discretion of the customer's user-agent, some customers may have a difficult time submitting a correct request. + +
+ +
+ + Security applications need to generate examples of JSON documents within the valid set, and outside the valid set. + +
+ +
+ + A database that uses JSON may need a way to declare, enforce, or guarantee certain constraints on the JSON document being stored. The database may also use JSON Schema as a way to annotate certain fields as having a special meaning for uniqueness or indexing purposes. + +
+ +
+ + Due to technical limitations, some JSON parsers may only be able to understand a subset of the JSON value space, and it makes sense to validate the value read by the application, instead of the JSON document provided to the JSON parser. For example: + + + Many JSON parsers cast the arbitrary-precision decimal numbers to an IEEE floating point, validating the number after it has lost some precision. + Some programming languages cannot distinguish between an ordered array of values and a key-value map; or an empty array is identical to an empty object. + Other validators may have a limited amount of memory and cannot support assertions more complicated than a deterministic context-free grammar. + + + Users of these validators need a way to determine if the missing functionality is essential to correctly validating input, and if not, get a validation result that would be correct but-for the unimplemented functionality. + + + + There's two directions this can work: an application should be able to determine if a third-party schema is making a distinction that it does not support; and an application may want to publish a schema indicating it works in a reduced value space. + + +
+ +
+ + A Web server that offers a JSON document should be able to link to a profile document that describes the meaning of the data in a machine-readable form. + +
+ +
+ + Generic user-agents must be able to make use of the schema as it evolves, including Web browsers, spiders, and automated tooling. It should support loose coupling (like an HTML homepage); so a schema should be able to change, add, and remove features with minimal breakage for compatible clients. + +
+ +
+ + The party that is providing the schema and input may not be the same party that is performing the validation; in this case, there should be a standard way to abstract away the validator interface, and report the results of a validation operation (validation result, annotations, and errors). + +
+ +
+ + Not every feature needs to be supported by every implementation. + To accommodate a wide variety of niche audiences, it should be possible to specify features that are optional to implement. + This includes standardized features that are optional to implement, bespoke or user-defined features that are not standardized, and new features added to future publications of the specification. + For forward compatibility, implementations that do not support optional extensions must degrade in a predictable fashion. + +
+ +
+ + Authors may embed resources of other media types, such as text documents, or base64 or hex-encoded binary documents; and may wish to pass off validation of these documents to another software tool. + +
+ +
+ + A JSON document may carry relational data that must be internally consistent. Example constraints include: + +
    +
  • One-to-one calculations, like that children's birthdates come after their parent's birthdates;
    • +
  • One-to-many calculations, like a reference to an anchor points to an anchor defined somewhere in the same document.
    • +
+
+ +
+ + A JSON document may carry relational data that must be verified against outside data sources. Example constraints include: + +
    +
  • References to a user ID points to a user in a central users database.
    • +
  • A supplied email address has been verified by the user.
    • +
+
+ +
+ + Sometimes it's desirable to require formatting that does not impact the application-level meaning of the document, but instead specifies requirements purely for aesthetic or compatibility reasons. + + + For example, for security reasons, an application may want to verify a JSON document does not contain the string "</script" but is written instead with a character escape such as "<\/script". This would ensure that, if the JSON were to be embedded in a <script> tag, it could not close the tag and be interpreted as HTML. + + + This is not a standard part of JSON Schema because it may violate the semantics of JSON, by adding an ability to distinguish between encodings which are supposed to be equivalent to receiving applications. + +
+
+ +
+ + This document does not make any normative requirements. + +
+ + + + + + &RFC5234; + &RFC6906; + + + + From 9a0ba01085e422b7bd7748955818b36bb3fa7e49 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Mon, 27 Mar 2023 09:36:13 +0000 Subject: [PATCH 471/780] Bump certifi from 2022.6.15 to 2022.12.7 Bumps [certifi](https://github.com/certifi/python-certifi) from 2022.6.15 to 2022.12.7. - [Release notes](https://github.com/certifi/python-certifi/releases) - [Commits](https://github.com/certifi/python-certifi/compare/2022.06.15...2022.12.07) --- updated-dependencies: - dependency-name: certifi dependency-type: indirect ... Signed-off-by: dependabot[bot] --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 934c7d59..7539146f 100644 --- a/requirements.txt +++ b/requirements.txt @@ -6,7 +6,7 @@ # appdirs==1.4.4 # via xml2rfc -certifi==2022.6.15 +certifi==2022.12.7 # via requests charset-normalizer==2.1.0 # via requests From c636bd6a13ffc5ef9573a75acaa0a59642592dc5 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 8 Mar 2023 09:08:56 +1300 Subject: [PATCH 472/780] add section on explicit annotations; disallow unknown keywords --- jsonschema-core.xml | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 61d9fff3..531c54dd 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -624,12 +624,22 @@ for registering and implementing such handlers is implementation-dependent. +
+ + The values of keywords which begin with the "@" symbol MUST be + collected as annotations. + + + Consequently, the "@" symbol is reserved for this purpose, and + extension vocabularies which define keywords that start with "@" + MUST define them as annotation-only keywords. + +
+
- Implementations SHOULD treat keywords they do not recognize, or that - they recognize but do not support, as annotations, where the value of - the keyword is the value of the annotation. Whether an implementation - collects these annotations or not, they MUST otherwise ignore the keywords. + Implementations MUST refuse to process schemas which contain + unrecognized or unsupported keywords.
From b88d95efd6b273fd938fa074b058ad4db5fe0e5d Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 8 Mar 2023 09:50:25 +1300 Subject: [PATCH 473/780] tweak to more closely match existing wording --- jsonschema-core.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 531c54dd..4da99ea5 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -639,7 +639,8 @@
Implementations MUST refuse to process schemas which contain - unrecognized or unsupported keywords. + keywords which they do not recognize or which they recognize + but do not support.
From 33c113ca3b5911949ab25c44b0553480bf4079ea Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 8 Mar 2023 10:18:09 +1300 Subject: [PATCH 474/780] revert unrecognized keywords change --- jsonschema-core.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 4da99ea5..fe81ed4a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -638,9 +638,10 @@
- Implementations MUST refuse to process schemas which contain - keywords which they do not recognize or which they recognize - but do not support. + Implementations SHOULD treat keywords they do not recognize, or that + they recognize but do not support, as annotations, where the value of + the keyword is the value of the annotation. Whether an implementation + collects these annotations or not, they MUST otherwise ignore the keywords.
From 29ca11605522fef94e9147a34b3c2df047ff3026 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 17 Mar 2023 11:41:33 +1300 Subject: [PATCH 475/780] add 'annotation collection only' requirement --- jsonschema-core.xml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index fe81ed4a..cf5aa190 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -629,6 +629,10 @@ The values of keywords which begin with the "@" symbol MUST be collected as annotations. + + Keywords which begin with the "@" symbol MUST NOT affect evaluation + of a schema in any way other than annotation collection. + Consequently, the "@" symbol is reserved for this purpose, and extension vocabularies which define keywords that start with "@" From 01c8327de6bd294245659272a3133d30a53905ab Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 28 Mar 2023 18:08:55 +1300 Subject: [PATCH 476/780] update to x-; vocabs must not define x- keywords --- jsonschema-core.xml | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index cf5aa190..c8fc6123 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -626,17 +626,16 @@
- The values of keywords which begin with the "@" symbol MUST be - collected as annotations. + The values of keywords which begin with "x-" MUST be collected as annotations. - Keywords which begin with the "@" symbol MUST NOT affect evaluation + Keywords which begin with "x-" symbol MUST NOT affect evaluation of a schema in any way other than annotation collection. - Consequently, the "@" symbol is reserved for this purpose, and - extension vocabularies which define keywords that start with "@" - MUST define them as annotation-only keywords. + Consequently, the "x-" prefix is reserved for this purpose, and + extension vocabularies MUST NOT define any keywords which begin + with this prefix.
From 08a17b26681b82db4c5770012bbb321950a61248 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 4 Apr 2023 13:11:03 +1200 Subject: [PATCH 477/780] create ADR for SVA support --- adr/2023-04-sva-prefix.md | 101 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 adr/2023-04-sva-prefix.md diff --git a/adr/2023-04-sva-prefix.md b/adr/2023-04-sva-prefix.md new file mode 100644 index 00000000..ac8347e8 --- /dev/null +++ b/adr/2023-04-sva-prefix.md @@ -0,0 +1,101 @@ +# Supporting Single-Value Annotations via a Defined Prefix + +* Status: accepted +* Deciders: @relequestual, @gregsdennis, @jdesrosiers, @karenetheridge, @awwright, @julian +* Date: 2023-04-04 + +Related: + +- Discussions: + - Disallow Unknown Keywords - https://github.com/orgs/json-schema-org/discussions/241 + - Support SVAs - https://github.com/orgs/json-schema-org/discussions/329 +- PRs: + - https://github.com/json-schema-org/json-schema-spec/pull/1387 (proposal) + +## Context and Problem Statement + +Dropping support for unknown keywords was a necessary step toward providing stability guarantees. However, the community's reaction to this news was not encouraging. How can we still support keywords that are merely collected as annotations and provide no functionality (single-value annotations, or SVAs)? + +## Decision Drivers + +* Future-proofing - We want to ensure that we can still add keywords to the spec without breaking existing schemas. +* Implementation supportability - Is the proposal feasible to implement? +* Community preference + +## Considered Options + +1. A defined prefix or other convention for SVAs + 1. Optionally defined by a new `$sigil` keyword +1. Inlined vocabularies that can define SVAs +1. A new core keyword that lists SVAs, e.g. `$ignored` +1. A defined configuration option to allow/forbid unknown keywords +1. A new core keyword designed for "extra" data + +## Decision Outcome + +Chosen option: A defined prefix or other convention. + +This option was chosen because it solves the problem in a clean way that can be easily implemented. It was also the favorite solution among the team members as well as the community. + +Specifically, the prefix `x-` has been selected. + +### Positive Consequences + +* It solves the problem by allowing users to include custom data in their schemas. +* Many developers will be familiar with using `x-` for custom data. +* It's a simple way to differentiate SVAs from other keywords. + +### Negative Consequences + +* Some people preferred a different prefix as `x-` in some other contexts denotes "experimental" behavior. + +## Pros and Cons of the Options + +### Option 1 - A defined prefix or other convention for SVAs + +[Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-4988859) + +* Good, because it's simple and easy to understand. +* Good, because `x-` specifically is familiar to many developers as an identifying prefix for custom data. +* Good, because it's easily supportable by the meta-schema (i.e. `patterProperties`) +* Bad, because `x-` in some other contexts can denote "experimental" behavior, which is not our meaning. + +#### Option 1a - Optionally defined by a new `$sigil` keyword + +[Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-5357549) + +* Good, because it can give users flexibility for the prefix that they want to use. +* Bad, because it cannot be supported by the meta-schema without other changes, which may be difficult to define and/or implement. + +High level of effort + +### Option 2 - Inlined vocabularies that can define SVAs + +[Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-4988882) + +* Good, because it defines the SVAs in a vocabulary which means they are regarded as "known." +* Bad, because we don't have any support for inlined vocabularies at the moment and would have to build that. + +### Option 3 - A new core keyword that lists SVAs, e.g. `$ignored` + +[Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-4988904) + +* Good, because it provides a way to define SVAs. +* Good, because it cannot be supported by the meta-schema without other changes, which may be difficult to define and/or implement. + +High level of effort + +### Option 4 - A defined configuration option to allow/forbid unknown keywords + +[Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-4999789) + +* Good, because it returns previous functionality (i.e. allowing unknown keywords) to the user. +* Bad, because that previous functionality removes/circumvents stability guarantees. + +### Option 5 - A new core keyword designed for "extra" data + +[Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-5374873) + +* Good, because it provides a place for users to add extra data. +* Bad, because it's an extra depth level that users need to create. +* Bad, because it can only generate a single annotation instead of multiple. From 2f311bcd7f7a346271317d834f5106949eddc488 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 4 Apr 2023 13:38:35 +1200 Subject: [PATCH 478/780] fix typo Co-authored-by: Mike Ralphson --- adr/2023-04-sva-prefix.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/2023-04-sva-prefix.md b/adr/2023-04-sva-prefix.md index ac8347e8..495b59da 100644 --- a/adr/2023-04-sva-prefix.md +++ b/adr/2023-04-sva-prefix.md @@ -81,7 +81,7 @@ High level of effort [Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-4988904) * Good, because it provides a way to define SVAs. -* Good, because it cannot be supported by the meta-schema without other changes, which may be difficult to define and/or implement. +* Bad, because it cannot be supported by the meta-schema without other changes, which may be difficult to define and/or implement. High level of effort From e3c039821ce5546271d6d357d6f9d05a4521c1ac Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 4 Apr 2023 14:30:34 +1200 Subject: [PATCH 479/780] Update adr/2023-04-sva-prefix.md Co-authored-by: Jason Desrosiers --- adr/2023-04-sva-prefix.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/2023-04-sva-prefix.md b/adr/2023-04-sva-prefix.md index 495b59da..c398bc7a 100644 --- a/adr/2023-04-sva-prefix.md +++ b/adr/2023-04-sva-prefix.md @@ -57,7 +57,7 @@ Specifically, the prefix `x-` has been selected. * Good, because it's simple and easy to understand. * Good, because `x-` specifically is familiar to many developers as an identifying prefix for custom data. -* Good, because it's easily supportable by the meta-schema (i.e. `patterProperties`) +* Good, because it's easily supportable by the meta-schema (i.e. `patternProperties`) * Bad, because `x-` in some other contexts can denote "experimental" behavior, which is not our meaning. #### Option 1a - Optionally defined by a new `$sigil` keyword From 540da083d758b80efbf19307fd59870812d960ab Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 23 May 2023 11:31:45 +1200 Subject: [PATCH 480/780] update abnf per @eemeli suggestion --- relative-json-pointer.xml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 084a95e4..0572a790 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -98,8 +98,7 @@ The ABNF syntax of a Relative JSON Pointer is: Date: Tue, 23 May 2023 04:33:15 +0000 Subject: [PATCH 481/780] Bump requests from 2.28.1 to 2.31.0 Bumps [requests](https://github.com/psf/requests) from 2.28.1 to 2.31.0. - [Release notes](https://github.com/psf/requests/releases) - [Changelog](https://github.com/psf/requests/blob/main/HISTORY.md) - [Commits](https://github.com/psf/requests/compare/v2.28.1...v2.31.0) --- updated-dependencies: - dependency-name: requests dependency-type: indirect ... Signed-off-by: dependabot[bot] --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 7539146f..994c8a84 100644 --- a/requirements.txt +++ b/requirements.txt @@ -36,7 +36,7 @@ pyflakes==2.4.0 # via xml2rfc pyyaml==6.0 # via xml2rfc -requests==2.28.1 +requests==2.31.0 # via # google-i18n-address # xml2rfc From b75927e97f17bd5f58c37a4f498323af735a056f Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 6 Jun 2023 11:00:20 +1200 Subject: [PATCH 482/780] fix regex in example meta-schema with custom vocab --- jsonschema-core.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index c8fc6123..b1055ffb 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -4148,7 +4148,7 @@ https://example.com/schemas/common#/$defs/allOf/1 "properties": { "minDate": { "type": "string", - "pattern": "\d\d\d\d-\d\d-\d\d", + "pattern": "\\d\\d\\d\\d-\\d\\d-\\d\\d", "format": "date", } } From c0382ecdf9603ba3d695b3853d7f219fafed3315 Mon Sep 17 00:00:00 2001 From: Benjamin Granados <40007659+benjagm@users.noreply.github.com> Date: Tue, 20 Jun 2023 15:28:20 +0200 Subject: [PATCH 483/780] Update CONTRIBUTING.md to remove outdated information Summary: This file is a brand new version of the contributing file to remove outdate information. Related issue: https://github.com/json-schema-org/json-schema-spec/issues/1414 --- CONTRIBUTING.md | 77 ++++++++++++------------------------------------- 1 file changed, 19 insertions(+), 58 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 71cc8e8b..c58c5a7d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,20 +1,20 @@ # Guidelines for contributing to the JSON Schema project -## Issues +## Contributing to JSON Schema Specification -Issues should identify an problem, enhancement, or use case; and propose some course of action for the draft. For alternate support channels, [see the json-schema.org website](http://json-schema.org/) or the [jsonschema tag on stackoverflow](https://stackoverflow.com/tags/jsonschema). +Thanks for taking the time to contribute! 🎉👍 -## Milestones +JSON Schema is an evolving language. This repository contains the specification text as well as Pull Requests with suggested improvements and contributions. -Each milestone is an estimation of the work that will be done for the next draft. Milestones are typically named after the meta-schema draft number, and the *open* milestone with the lowest draft number is the current active project. +Contributions that do not change the interpretation of the spec but instead improve legibility, fix editorial errors, clear up ambiguity and improve examples are encouraged and are often merged by a spec editor with little process. -Issues may be removed from a milestoned due to lack of consensus, lack of anyone with the correct expertise to make a PR, or simply because we wish to publish a draft and defer the remaining issues to the next draft. +However, contributions that _do_ meaningfully change the interpretation of the spec must follow the Specification Development Process which is ⚠️already under discussion and development⚠️. -Numbered milestones other than the lowest-numbered one are used to tentatively organize future work, but may be completely reorganized once work on that draft actually begins. +## Issues -The `draft-future` milestone is for issues for which there is an agreement that they should be addressed, but no specific timeline. +Issues should identify an problem, enhancement, or use case; and propose some course of action for the draft. For alternate support channels, see the [json-schema.org website](http://json-schema.org/) or join our [Slack workspace](https://json-schema.org/slack)**. -## Pull requests +## Pull Requests We welcome pull requests, both for editorial suggestions and to resolve open issues. @@ -22,64 +22,25 @@ If the pull request would solve a particular issue, reference the issue in the p Changes that would affect implementation behavior should typically be opened as an issue first. -Generally, pull requests should be made to the `main` branch unless it is a -patch update and we are in a patch phase of the -[release process](https://github.com/json-schema-org/community/discussions/7). -In that case there will be a branch named something like `2020-12-patch` that -the PR should target instead. - -Most PRs, including all PRs that impact implementation behavior, will be left open for a minimum of 14 days. Minor wording fixes may be merged more quickly once approved by a project member. - -## Internet-Drafts and meta-schemas - -An Internet-Draft (I-D) publication replaces previous documents in their entirety. - -I-D updates that are purely editorial bug fixes (with no implementation-impacting changes) will continue to use the same meta-schemas as the version that they fix. - -I-D updates that impact behavior, whether as a bug fix or a new, changed, or removed feature, will have new meta-schemas published along with them. +Generally, pull requests should be made to the `main` branch unless it is a patch update and we are in a patch phase. In that case there will be a branch named something like `2020-12-patch` that the PR should target instead. -The meta-schema URI is used to differentiate between different vocabularies (currently only Validation and Hyper-Schema). +Most PRs, including all PRs that impact implementation behavior, will be left open for a minimum of 14 days. Minor wording fixes may be merged more quickly once approved by a project member. -The authority on JSON Schema behavior is the respective specification document, not the JSON meta-schema; the JSON version of the meta-schema is maintained in an informative capacity only. - -As an informative document, bugs in the meta-schema may be fixed in place to align them with the normative specification. Examples of in-place fixes include adding an accidentally omitted keyword or fixing an incorrect type. By definition, no correct schema should fail validation against the meta-schema after a bug fix, although previously validating incorrect schemas may start to (correctly) fail validation. - -## Conduct - -All official channels including the mailing list, GitHub organization, Slack server, and IRC channels, follow our [Code of Conduct](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md). - - -## Financial contributions - -We also welcome financial contributions in full transparency on our [open collective](https://opencollective.com/json-schema). -Anyone can file an expense. If the expense makes sense for the development of the community, it will be "merged" in the ledger of our open collective by the core contributors and the person who filed the expense will be reimbursed. - -## Credits +## Milestones -### Code Contributors +Each milestone is an estimation of the work that will be done for the next draft. Milestones are typically named after the meta-schema draft number, and the _open_ milestone with the lowest draft number is the current active project. -This project exists thanks to all the people who contribute. [[Contribute](CONTRIBUTING.md)]. - +Issues may be removed from a milestoned due to lack of consensus, lack of anyone with the correct expertise to make a PR, or simply because we wish to publish a draft and defer the remaining issues to the next draft. -### Financial Contributors +Numbered milestones other than the lowest-numbered one are used to tentatively organize future work, but may be completely reorganized once work on that draft actually begins. -Become a financial contributor and help us sustain our community. [[Contribute](https://opencollective.com/json-schema/contribute)] +The `draft-future` milestone is for issues for which there is an agreement that they should be addressed, but no specific timeline. -#### Individuals +## Code of Conduct - +All official channels including the mailing list, GitHub organization, Slack server, and IRC channels, follow our [Code of Conduct](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md). -#### Organizations +## Have Questions? -Support this project with your organization. Your logo will show up here with a link to your website. [[Contribute](https://opencollective.com/json-schema/contribute)] +You can join the `#specification` channel in our [Slack workspace](https://json-schema.org/slack)** to interact with other community members involved in the Specification development, share new ideas and ask questions. - - - - - - - - - - From 2e8634d6f7cd9e950b7c8a6b97a39db0f38b4a41 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Sat, 1 Jul 2023 12:54:47 -0700 Subject: [PATCH 484/780] Move myself from current to past author list --- jsonschema-core.xml | 9 ++------- jsonschema-validation.xml | 9 ++------- 2 files changed, 4 insertions(+), 14 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index b1055ffb..4c4b662a 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -32,12 +32,6 @@ - -
- andrews_henry@yahoo.com -
- - Postman
@@ -4245,7 +4239,8 @@ https://example.com/schemas/common#/$defs/allOf/1 Gary Court, Francis Galiegue, Kris Zyp, - and Geraint Luff + Geraint Luff, + and Henry Andrews for their work on the initial drafts of JSON Schema. diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 63475c2c..65902b4e 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -40,12 +40,6 @@
- -
- andrews_henry@yahoo.com -
- - Postman
@@ -1355,7 +1349,8 @@ Gary Court, Francis Galiegue, Kris Zyp, - and Geraint Luff + Geraint Luff, + and Henry Andrews for their work on the initial drafts of JSON Schema. From 66adf13db7e4068d39dfc0ed756140f59ef91d81 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Mon, 19 Jun 2023 21:21:46 -0700 Subject: [PATCH 485/780] Rename to avoid collision with past series. It turns out that it's not possible to continue the previous draft-handrews series due to the intervening draft-bhutton series. After consulting with IETF support, the recommendation was to use another variation on my name to start a new series. --- relative-json-pointer.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 0572a790..0a26e867 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -12,7 +12,7 @@ - + Relative JSON Pointers @@ -27,7 +27,7 @@
- +
andrews_henry@yahoo.com
@@ -324,7 +324,7 @@ - + Fix ABNF omission for using # with index manipulation Clarify handling of leading "0" From 67d1125114c2532a64f5ff10d5906567626546a9 Mon Sep 17 00:00:00 2001 From: "Henry H. Andrews" Date: Mon, 19 Jun 2023 21:31:15 -0700 Subject: [PATCH 486/780] IANA Considerations section is now required. The text added is what the IETF recommends when there are no IANA considerations. --- relative-json-pointer.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/relative-json-pointer.xml b/relative-json-pointer.xml index 0a26e867..cb8725f0 100644 --- a/relative-json-pointer.xml +++ b/relative-json-pointer.xml @@ -305,6 +305,12 @@ programming languages that use NUL to mark the end of a string.
+ +
+ + This document has no IANA actions. + +
From c1e17b33b313ef51b70900678f7404c0a35838f2 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Tue, 25 Jul 2023 21:29:16 +0000 Subject: [PATCH 487/780] Bump certifi from 2022.12.7 to 2023.7.22 Bumps [certifi](https://github.com/certifi/python-certifi) from 2022.12.7 to 2023.7.22. - [Commits](https://github.com/certifi/python-certifi/compare/2022.12.07...2023.07.22) --- updated-dependencies: - dependency-name: certifi dependency-type: indirect ... Signed-off-by: dependabot[bot] --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 994c8a84..c4cf1f03 100644 --- a/requirements.txt +++ b/requirements.txt @@ -6,7 +6,7 @@ # appdirs==1.4.4 # via xml2rfc -certifi==2022.12.7 +certifi==2023.7.22 # via requests charset-normalizer==2.1.0 # via requests From 6942b1fa65a218a2983dfabf30d3f36221167e8b Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 2 Aug 2023 14:11:57 +0100 Subject: [PATCH 488/780] Add security policy document --- .github/SECURITY.md | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 .github/SECURITY.md diff --git a/.github/SECURITY.md b/.github/SECURITY.md new file mode 100644 index 00000000..87b438e3 --- /dev/null +++ b/.github/SECURITY.md @@ -0,0 +1,11 @@ +# Reporting Security Issues + +The JSON Schema project does not house any implementation of JSON Schema itself. If you have found a security issue in any implementation of JSON Schema, please contact the appropriate maintainers, per the projects security reporting guidelines, if any. + +To report a security issue, please use the GitHub Security Advisory "https://github.com/json-schema-org/json-schema-spec/security/advisories/new" tab. + +If you find a security issue in relation to the JSON Schema specification or another repository within this GitHub organization, please use the above. + +The JSON Schema project TSC will review and respond to all security reports. Please follow [coordinated disclosure](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/about-coordinated-disclosure-of-security-vulnerabilities). + +If you are a maintainer of an implementation, please consider [adding a security policy](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository). If you need assistance in understanding a report, or remediation of a confirmed issue, please feel free to reach out to us on our Slack server, in the `#implementations` channel, and ask for a temporary private channel to discuss your situation or concerns. \ No newline at end of file From d8b46acab1073fbca70bfdfa34c0884a3fc5ef7b Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Fri, 28 Jul 2023 12:06:53 -0700 Subject: [PATCH 489/780] Convert core/validation specs to non-IETF markdown --- .gitignore | 3 + README.md | 76 +- build/build.js | 114 + build/remark-number-headings.js | 35 + jsonschema-core.md | 3317 +++++++++++++++++++++++ jsonschema-core.xml | 4406 ------------------------------- jsonschema-validation.md | 1046 ++++++++ jsonschema-validation.xml | 1492 ----------- package.json | 33 + 9 files changed, 4601 insertions(+), 5921 deletions(-) create mode 100644 build/build.js create mode 100644 build/remark-number-headings.js create mode 100644 jsonschema-core.md delete mode 100644 jsonschema-core.xml create mode 100644 jsonschema-validation.md delete mode 100644 jsonschema-validation.xml create mode 100644 package.json diff --git a/.gitignore b/.gitignore index f375fa6e..dc05e9da 100644 --- a/.gitignore +++ b/.gitignore @@ -7,3 +7,6 @@ relative-json-pointer.txt # For the Python enviornment .venv + +package-lock.json +node_modules/ diff --git a/README.md b/README.md index 58007547..73a6da2d 100644 --- a/README.md +++ b/README.md @@ -22,29 +22,59 @@ For the current status of issues and pull requests, please see the following lab Labels are assigned based on [Sensible Github Labels](https://github.com/Relequestual/sensible-github-labels). -## Contents - -* Makefile - scripts to build the Internet-Draft txt/html -* _Internet-Draft sources_ - * jsonschema-core.xml - source for JSON Schema's "core" I-D - * jsonschema-validation.xml - source for the validation vocabulary I-D - * relative-json-pointer.xml - source for the Relative JSON Pointer I-D -* _meta-schemas and recommended output formats_ - * schema.json - JSON Schema "core" and Validation meta-schema - -The Makefile will create the necessary Python venv for you as part of the regular make target. - -`make clean` will remove all output including the venv. To clean just the spec output and -keep the venv, use `make spec-clean`. - -If you want to run `xml2rfc` manually after running make for the first time, you will -need to activate the virtual environment: - -```sh -source .venv/bin/activate -``` - -The version of "xml2rfc" that this project uses is updated by modifying `requirements.in` and running `pip-compile requirements.in`. +## Authoring and Building + +### Specification +To build the spec files to HTML from the Markdown sources, run `npm run build`. +You can also build each individually with `npm run build-core` and `npm run +build-validation`. + +The spec is built using [Remark](https://remark.js.org/), a markdown engine with +good support for plugins and lots of existing plugins we can use. + +#### Plugins +The following is a not-necessarily-complete list of configured plugins and the +features they make available to you. + +- [remark-lint](https://github.com/remarkjs/remark-lint) -- Enforce markdown + styles guide. +- [remark-gfm](https://github.com/remarkjs/remark-gfm) -- Adds support for + Github Flavored Markdown specific markdown features such as autolink literals, + footnotes, strikethrough, tables, and tasklists. +- [remark-number-headings](/json-schema-org/json-schema-spec/blob/main/remark-number-headings.js) + -- Adds hierarchical section numbers to headings. +- [remark-toc](https://github.com/remarkjs/remark-toc) -- Adds a table of + contents in a section with a header called "Table of Contents". +- [remark-torchlight](https://github.com/torchlight-api/remark-torchlight) -- + Syntax highlighting and more using https://torchlight.dev. Features include + line numbers and line highlighting. +- [rehype-slug](https://github.com/rehypejs/rehype-slug) -- Adds `id` anchors to + header so they can be linked to with URI fragment syntax. +- [rehype-autolink-headings](https://github.com/rehypejs/rehype-autolink-headings) + -- Makes headings clickable. +- [remark-flexible-containers](https://github.com/ipikuka/remark-flexible-containers) + -- Add a callout box using the following syntax. Supported container types are + `warning`, `note`, and `experimental`. + + ``` + ::: {type} {title} + {content} + ::: + ``` + +### Internet-Drafts +To build components that are being maintained as IETF Internet-Drafts, run +`make`. The Makefile will create the necessary Python venv for you as part of +the regular make target. + +`make clean` will remove all output including the venv. To clean just the spec +output and keep the venv, use `make spec-clean`. + +If you want to run `xml2rfc` manually after running make for the first time, you +will need to activate the virtual environment: `source .venv/bin/activate`. + +The version of "xml2rfc" that this project uses is updated by modifying +`requirements.in` and running `pip-compile requirements.in`. Descriptions of the xml2rfc, I-D documents, and RFC processes: diff --git a/build/build.js b/build/build.js new file mode 100644 index 00000000..403d7660 --- /dev/null +++ b/build/build.js @@ -0,0 +1,114 @@ +/* eslint-disable no-console */ +import dotenv from "dotenv"; +import { readFileSync, writeFileSync } from "node:fs"; +import { reporter } from "vfile-reporter"; +import { remark } from "remark"; +import remarkPresetLintMarkdownStyleGuide from "remark-preset-lint-markdown-style-guide"; +import remarkGfm from "remark-gfm"; +import remarkToc from "remark-toc"; +import torchLight from "remark-torchlight"; +import remarkRehype from "remark-rehype"; +import rehypeSlug from "rehype-slug"; +import rehypeAutolinkHeadings from "rehype-autolink-headings"; +import rehypeStringify from "rehype-stringify"; +import remarkNumberHeadings from "./remark-number-headings.js"; +import remarkFlexibleContainers from "remark-flexible-containers"; + + +dotenv.config(); + +(async function () { + const md = readFileSync(0, "utf-8"); + const html = await remark() + .use(remarkPresetLintMarkdownStyleGuide) + .use(remarkGfm) + .use(remarkNumberHeadings, { startDepth: 2, skip: ["Abstract", "Note to Readers", "Table of Contents"] }) + .use(remarkToc, { tight: true, heading: "Table of Contents" }) + .use(torchLight) + .use(remarkFlexibleContainers) + .use(remarkRehype) + .use(rehypeSlug) + .use(rehypeAutolinkHeadings, { behavior: "wrap" }) + .use(rehypeStringify) + .process(md); + + writeFileSync(1, ` + + + + + + + + + ${String(html)} + +`); + + console.error(reporter(html)); +}()); diff --git a/build/remark-number-headings.js b/build/remark-number-headings.js new file mode 100644 index 00000000..8517e042 --- /dev/null +++ b/build/remark-number-headings.js @@ -0,0 +1,35 @@ +import { visit } from "unist-util-visit"; + + +const defaultOptions = { + startDepth: 1, + skip: [] +}; + +const remarkNumberHeadings = (options) => (tree) => { + options = { ...defaultOptions, ...options }; + + let sectionNumbers = []; + + visit(tree, "heading", (node) => { + if (node.depth < options.startDepth) { + return; + } + + visit(node, "text", (textNode) => { + const text = textNode.value ? textNode.value.trim() : ""; + + if (options.skip.includes(text)) { + return; + } + + sectionNumbers[node.depth] = (sectionNumbers[node.depth] ?? 0) + 1; + sectionNumbers = sectionNumbers.slice(0, node.depth + 1); + + const sectionNumber = sectionNumbers.slice(options.startDepth, node.depth + 1).join("."); + textNode.value = `${sectionNumber}. ${text}`; + }); + }); +}; + +export default remarkNumberHeadings; diff --git a/jsonschema-core.md b/jsonschema-core.md new file mode 100644 index 00000000..09ee2bcb --- /dev/null +++ b/jsonschema-core.md @@ -0,0 +1,3317 @@ +# JSON Schema: A Media Type for Describing JSON Documents + +## Abstract +JSON Schema defines the media type `application/schema+json`, a JSON-based +format for describing the structure of JSON data. JSON Schema asserts what a +JSON document must look like, ways to extract information from it, and how to +interact with it. The `application/schema-instance+json` media type provides +additional feature-rich integration with `application/schema+json` beyond what +can be offered for `application/json` documents. + +## Note to Readers +The issues list for this draft can be found at +. + +For additional information, see . + +To provide feedback, use this issue tracker, the communication methods listed on +the homepage, or email the document editors. + +## Table of Contents + +## Introduction +JSON Schema is a JSON media type for defining the structure of JSON data. JSON +Schema is intended to define validation, documentation, hyperlink navigation, +and interaction control of JSON data. + +This specification defines JSON Schema core terminology and mechanisms, +including pointing to another JSON Schema by reference, dereferencing a JSON +Schema reference, specifying the dialect being used, specifying a dialect's +vocabulary requirements, and defining the expected output. + +Other specifications define the vocabularies that perform assertions about +validation, linking, annotation, navigation, and interaction. + +## Conventions and Terminology +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in [RFC 2119](#rfc2119). + +The terms "JSON", "JSON text", "JSON value", "member", "element", "object", +"array", "number", "string", "boolean", "true", "false", and "null" in this +document are to be interpreted as defined in [RFC 8259](#rfc8259). + +## Overview +This document proposes a new media type `application/schema+json` to identify a +JSON Schema for describing JSON data. It also proposes a further optional media +type, `application/schema-instance+json`, to provide additional integration +features. JSON Schemas are themselves JSON documents. This, and related +specifications, define keywords allowing authors to describe JSON data in +several ways. + +JSON Schema uses keywords to assert constraints on JSON instances or annotate +those instances with additional information. Additional keywords are used to +apply assertions and annotations to more complex JSON data structures, or based +on some sort of condition. + +To facilitate re-use, keywords can be organized into vocabularies. A vocabulary +consists of a list of keywords, together with their syntax and semantics. A +dialect is defined as a set of vocabularies and their required support +identified in a meta-schema. + +JSON Schema can be extended either by defining additional vocabularies, or less +formally by defining additional keywords outside of any vocabulary. Unrecognized +individual keywords simply have their values collected as annotations, while the +behavior with respect to an unrecognized vocabulary can be controlled when +declaring which vocabularies are in use. + +This document defines a core vocabulary that MUST be supported by any +implementation, and cannot be disabled. Its keywords are each prefixed with a +"$" character to emphasize their required nature. This vocabulary is essential +to the functioning of the `application/schema+json` media type, and is used to +bootstrap the loading of other vocabularies. + +Additionally, this document defines a RECOMMENDED vocabulary of keywords for +applying subschemas conditionally, and for applying subschemas to the contents +of objects and arrays. Either this vocabulary or one very much like it is +required to write schemas for non-trivial JSON instances, whether those schemas +are intended for assertion validation, annotation, or both. While not part of +the required core vocabulary, for maximum interoperability this additional +vocabulary is included in this document and its use is strongly encouraged. + +Further vocabularies for purposes such as structural validation or hypermedia +annotation are defined in other documents. These other documents each define a +dialect collecting the standard sets of vocabularies needed to write schemas for +that document's purpose. + +## Definitions + +### JSON Document +A JSON document is an information resource (series of octets) described by the +`application/json` media type. + +In JSON Schema, the terms "JSON document", "JSON text", and "JSON value" are +interchangeable because of the data model it defines in +[Section 4.2.1](#421-instance-data-model). + +JSON Schema is only defined over JSON documents. However, any document or memory +structure that can be parsed into or processed according to the JSON Schema data +model can be interpreted against a JSON Schema, including media types like +[CBOR](#rfc7049). + +### Instance + +A JSON document to which a schema is applied is known as an "instance". + +JSON Schema is defined over `application/json` or compatible documents, +including media types with the `+json` structured syntax suffix. + +Among these, this specification defines the `application/schema-instance+json` +media type which defines handling for fragments in the IRI. + +#### Instance Data Model + +JSON Schema interprets documents according to a data model. A JSON value +interpreted according to this data model is called an "instance". + +An instance has one of six primitive types, and a range of possible values +depending on the type: + +null: A JSON "null" value + +boolean: A "true" or "false" value, from the JSON "true" or "false" value + +object: An unordered set of properties mapping a string to an instance, from the +JSON "object" value + +array: An ordered list of instances, from the JSON "array" value + +number: An arbitrary-precision, base-10 decimal number value, from the JSON +"number" value + +string: A string of Unicode code points, from the JSON "string" value + +Whitespace and formatting concerns, including different lexical representations +of numbers that are equal within the data model, are thus outside the scope of +JSON Schema. JSON Schema [vocabularies](#81-meta-schemas-and-vocabularies) that +wish to work with such differences in lexical representations SHOULD define +keywords to precisely interpret formatted strings within the data model rather +than relying on having the original JSON representation Unicode characters +available. + +Since an object cannot have two properties with the same key, behavior for a +JSON document that tries to define two properties with the same key in a single +object is undefined. + +Note that JSON Schema vocabularies are free to define their own extended type +system. This should not be confused with the core data model types defined +here. As an example, "integer" is a reasonable type for a vocabulary to define +as a value for a keyword, but the data model makes no distinction between +integers and other numbers. + +#### Instance Equality +Two JSON instances are said to be equal if and only if they are of the same type +and have the same value according to the data model. Specifically, this means: + +- both are null; or +- both are true; or +- both are false; or +- both are strings, and are the same codepoint-for-codepoint; or +- both are numbers, and have the same mathematical value; or +- both are arrays, and have an equal value item-for-item; or +- both are objects, and each property in one has exactly one property with +a key equal to the other's, and that other property has an equal value. + +Implied in this definition is that arrays must be the same length, objects must +have the same number of members, properties in objects are unordered, there is +no way to define multiple properties with the same key, and mere formatting +differences (indentation, placement of commas, trailing zeros) are +insignificant. + +#### Non-JSON Instances +It is possible to use JSON Schema with a superset of the JSON Schema data model, +where an instance may be outside any of the six JSON data types. + +In this case, annotations still apply; but most validation keywords will not be +useful, as they will always pass or always fail. + +A custom vocabulary may define support for a superset of the core data model. +The schema itself may only be expressible in this superset; for example, to make +use of the `const` keyword. + +### JSON Schema Documents +A JSON Schema document, or simply a schema, is a JSON document used to describe +an instance. A schema can itself be interpreted as an instance, but SHOULD +always be given the media type `application/schema+json` rather than +`application/schema-instance+json`. The `application/schema+json` media type is +defined to offer a superset of the fragment identifier syntax and semantics +provided by `application/schema-instance+json`. + +A JSON Schema MUST be an object or a boolean. + +#### JSON Schema Objects and Keywords +Object properties that are applied to the instance are called keywords, +or schema keywords. Broadly speaking, keywords fall into one of five +categories: + +identifiers: control schema identification through setting a IRI for the schema +and/or changing how the base IRI is determined + +assertions: produce a boolean result when applied to an instance + +annotations: attach information to an instance for application use + +applicators: apply one or more subschemas to a particular location in the +instance, and combine or modify their results + +reserved locations: do not directly affect results, but reserve a place for a +specific purpose to ensure interoperability + +Keywords may fall into multiple categories, although applicators SHOULD only +produce assertion results based on their subschemas' results. They should not +define additional constraints independent of their subschemas. + +Keywords which are properties within the same schema object are referred to as +adjacent keywords. + +Extension keywords, meaning those defined outside of this document and its +companions, are free to define other behaviors as well. + +A JSON Schema MAY contain properties which are not schema keywords or are not +recognized as schema keywords. The behavior of such keywords is governed by +[Section 6.5.2](#652-handling-of-unrecognized-or-unsupported-keywords). + +An empty schema is a JSON Schema with no properties. + +#### Boolean JSON Schemas +The boolean schema values `true` and `false` are trivial schemas that always +produce themselves as assertion results, regardless of the instance value. They +never produce annotation results. + +These boolean schemas exist to clarify schema author intent and facilitate +schema processing optimizations. They behave identically to the following +schema objects (where `not` is part of the subschema application vocabulary +defined in this document). + +`true`: Always passes validation, as if the empty schema `{}` + +`false`: Always fails validation, as if the schema `{ "not": {} }` + +While the empty schema object is unambiguous, there are many possible +equivalents to the `false` schema. Using the boolean values ensures that the +intent is clear to both human readers and implementations. + +#### Schema Vocabularies +A schema vocabulary, or simply a vocabulary, is a set of keywords, their syntax, +and their semantics. A vocabulary is generally organized around a particular +purpose. Different uses of JSON Schema, such as validation, hypermedia, or user +interface generation, will involve different sets of vocabularies. + +Vocabularies are the primary unit of re-use in JSON Schema, as schema authors +can indicate what vocabularies are required or optional in order to process the +schema. Since vocabularies are identified by IRIs in the meta-schema, generic +implementations can load extensions to support previously unknown vocabularies. +While keywords can be supported outside of any vocabulary, there is no analogous +mechanism to indicate individual keyword usage. + +A schema vocabulary can be defined by anything from an informal description to a +standards proposal, depending on the audience and interoperability expectations. +In particular, in order to facilitate vocabulary use within non-public +organizations, a vocabulary specification need not be published outside of its +scope of use. + +#### Meta-Schemas +A schema that itself describes a schema is called a meta-schema. Meta-schemas +are used to validate JSON Schemas and specify which vocabularies they are using. + +Typically, a meta-schema will specify a set of vocabularies, and validate +schemas that conform to the syntax of those vocabularies. However, meta-schemas +and vocabularies are separate in order to allow meta-schemas to validate schema +conformance more strictly or more loosely than the vocabularies' specifications +call for. Meta-schemas may also describe and validate additional keywords that +are not part of a formal vocabulary. + +#### Root Schema and Subschemas and Resources +A JSON Schema resource is a schema which is [canonically](#rfc6596) identified +by an [absolute IRI](#rfc3987). Schema resources MAY also be identified by IRIs, +including IRIs with fragments, if the resulting secondary resource (as defined +by [section 3.5 of RFC 3986](#rfc3986)) is identical to the primary resource. +This can occur with the empty fragment, or when one schema resource is embedded +in another. Any such IRIs with fragments are considered to be non-canonical. + +The root schema is the schema that comprises the entire JSON document in +question. The root schema is always a schema resource, where the IRI is +determined as described in [Section 9.1.1](#911-initial-base-iri).[^1] + +[^1]: Note that documents that embed schemas in another format will not have a +root schema resource in this sense. Exactly how such usages fit with the JSON +Schema document and resource concepts will be clarified in a future draft. + +Some keywords take schemas themselves, allowing JSON Schemas to be nested: + +```json +{ + "title": "root", + "items": { + "title": "array item" + } +} +``` + +In this example document, the schema titled "array item" is a subschema, and the +schema titled "root" is the root schema. + +As with the root schema, a subschema is either an object or a boolean. + +As discussed in [Section 8.2.1](#821-the-id-keyword), a JSON Schema document +can contain multiple JSON Schema resources. When used without qualification, +the term "root schema" refers to the document's root schema. In some cases, +resource root schemas are discussed. A resource's root schema is its top-level +schema object, which would also be a document root schema if the resource were +to be extracted to a standalone JSON Schema document. + +Whether multiple schema resources are embedded or linked with a reference, they +are processed in the same way, with the same available behaviors. + +## Fragment Identifiers +In accordance with section 3.1 of [RFC 6839](#rfc6839), the syntax and semantics +of fragment identifiers specified for any +json media type SHOULD be as +specified for `application/json`. (At publication of this document, there is no +fragment identification syntax defined for `application/json`.) + +Additionally, the `application/schema+json` media type supports two fragment +identifier structures: plain names and JSON Pointers. The +`application/schema-instance+json` media type supports one fragment identifier +structure: JSON Pointers. + +The use of JSON Pointers as IRI fragment identifiers is described in +[RFC 6901](#rfc6901). For `application/schema+json`, which supports two fragment +identifier syntaxes, fragment identifiers matching the JSON Pointer syntax, +including the empty string, MUST be interpreted as JSON Pointer fragment +identifiers. + +Per the W3C's [best practices for fragment +identifiers](#w3cwd-fragid-best-practices-20121025), plain name fragment +identifiers in `application/schema+json` are reserved for referencing locally +named schemas. + +Plain name fragments MUST start with a letter ([A-Za-z]) or underscore ("\_"), +followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores +("\_"), and periods ("."). This matches the US-ASCII part of XML's [NCName +production](#xml-names), which allows for compatibility with the recommended +plain name [syntax](#w3crec-xptr-framework-20030325) for XML-based media types. + +All fragment identifiers that do not match the JSON Pointer syntax MUST be +interpreted as plain name fragment identifiers. + +Defining and referencing a plain name fragment identifier within an +`application/schema+json` document are specified in the [`$anchor` +keyword](#822-defining-location-independent-identifiers) section. + +## General Considerations + +### Range of JSON Values +An instance may be any valid JSON value as defined by [JSON](#rfc8259). JSON +Schema imposes no restrictions on type: JSON Schema can describe any JSON value, +including, for example, null. + +### Programming Language Independence +JSON Schema is programming language agnostic, and supports the full range of +values described in the data model. Be aware, however, that some languages and +JSON parsers may not be able to represent in memory the full range of values +describable by JSON. + +### Mathematical Integers +Some programming languages and parsers use different internal representations +for floating point numbers than they do for integers. + +For consistency, integer JSON numbers SHOULD NOT be encoded with a fractional +part. + +### Regular Expressions +Keywords MAY use regular expressions to express constraints, or constrain the +instance value to be a regular expression. These regular expressions SHOULD be +valid according to the regular expression dialect described in [ECMA-262, +section 21.2.1](#ecma262). + +Unless otherwise specified by a keyword, regular expressions MUST NOT be +considered to be implicitly anchored at either end. All regular expression +keywords in this specification and its companion documents are un-anchored. + +Regular expressions SHOULD be built with the "u" flag (or equivalent) to provide +Unicode support, or processed in such a way which provides Unicode support as +defined by ECMA-262. + +Furthermore, given the high disparity in regular expression constructs support, +schema authors SHOULD limit themselves to the following regular expression +tokens: + +- individual Unicode characters, as defined by the [JSON +specification](#rfc8259); +- simple character classes ([abc]), range character classes ([a-z]); +- complemented character classes ([^abc], [^a-z]); +- simple quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or one), +and their lazy versions ("+?", "*?", "??"); +- range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at least x, at most +y, occurrences), {x,} (x occurrences or more), and their lazy versions; +- the beginning-of-input ("^") and end-of-input ("$") anchors; +- simple grouping ("(...)") and alternation ("|"). + +Finally, implementations MUST NOT take regular expressions to be anchored, +neither at the beginning nor at the end. This means, for instance, the pattern +"es" matches "expression". + +### Extending JSON Schema +Additional schema keywords and schema vocabularies MAY be defined by any entity. +Save for explicit agreement, schema authors SHALL NOT expect these additional +keywords and vocabularies to be supported by implementations that do not +explicitly document such support. + +Implementations MAY provide the ability to register or load handlers for +vocabularies that they do not support directly. The exact mechanism for +registering and implementing such handlers is implementation-dependent. + +#### Explicit annotation keywords +The values of keywords which begin with "x-" MUST be collected as annotations. + +Keywords which begin with "x-" symbol MUST NOT affect evaluation of a schema in +any way other than annotation collection. + +Consequently, the "x-" prefix is reserved for this purpose, and extension +vocabularies MUST NOT define any keywords which begin with this prefix. + +#### Handling of unrecognized or unsupported keywords +Implementations SHOULD treat keywords they do not recognize, or that they +recognize but do not support, as annotations, where the value of the keyword is +the value of the annotation. Whether an implementation collects these +annotations or not, they MUST otherwise ignore the keywords. + +## Keyword Behaviors +JSON Schema keywords fall into several general behavior categories. Assertions +validate that an instance satisfies constraints, producing a boolean result. +Annotations attach information that applications may use in any way they see +fit. Applicators apply subschemas to parts of the instance and combine their +results. + +Extension keywords SHOULD stay within these categories, keeping in mind that +annotations in particular are extremely flexible. Complex behavior is usually +better delegated to applications on the basis of annotation data than +implemented directly as schema keywords. However, extension keywords MAY define +other behaviors for specialized purposes. + +Evaluating an instance against a schema involves processing all of the keywords +in the schema against the appropriate locations within the instance. Typically, +applicator keywords are processed until a schema object with no applicators (and +therefore no subschemas) is reached. The appropriate location in the instance +is evaluated against the assertion and annotation keywords in the schema object. +The interactions of those keyword results to produce the schema object results +are governed by [Section 7.7.1.2](#7712-annotations-and-assertions), while the +relationship of subschema results to the results of the applicator keyword that +applied them is described by [Section 7.5](#75-applicators). + +Evaluation of a parent schema object can complete once all of its subschemas +have been evaluated, although in some circumstances evaluation may be +short-circuited due to assertion results. When annotations are being collected, +some assertion result short-circuiting is not possible due to the need to +examine all subschemas for annotation collection, including those that cannot +further change the assertion result. + +### Lexical Scope and Dynamic Scope + +While most JSON Schema keywords can be evaluated on their own, or at most need +to take into account the values or results of adjacent keywords in the same +schema object, a few have more complex behavior. + +The lexical scope of a keyword is determined by the nested JSON data structure +of objects and arrays. The largest such scope is an entire schema document. +The smallest scope is a single schema object with no subschemas. + +Keywords MAY be defined with a partial value, such as a IRI-reference, which +must be resolved against another value, such as another IRI-reference or a full +IRI, which is found through the lexical structure of the JSON document. The +`$id`, `$ref`, and `$dynamicRef` core keywords, and the "base" JSON Hyper-Schema +keyword, are examples of this sort of behavior. + +Note that some keywords, such as `$schema`, apply to the lexical scope of the +entire schema resource, and therefore MUST only appear in a schema resource's +root schema. + +Other keywords may take into account the dynamic scope that exists during the +evaluation of a schema, typically together with an instance document. The +outermost dynamic scope is the schema object at which processing begins, even if +it is not a schema resource root. The path from this root schema to any +particular keyword (that includes any `$ref` and `$dynamicRef` keywords that may +have been resolved) is considered the keyword's "evaluation path." + +Lexical and dynamic scopes align until a reference keyword is encountered. While +following the reference keyword moves processing from one lexical scope into a +different one, from the perspective of dynamic scope, following a reference is +no different from descending into a subschema present as a value. A keyword on +the far side of that reference that resolves information through the dynamic +scope will consider the originating side of the reference to be their dynamic +parent, rather than examining the local lexically enclosing parent. + +The concept of dynamic scope is primarily used with `$dynamicRef` and +`$dynamicAnchor`, and should be considered an advanced feature and used with +caution when defining additional keywords. It also appears when reporting +errors and collected annotations, as it may be possible to revisit the same +lexical scope repeatedly with different dynamic scopes. In such cases, it is +important to inform the user of the evaluation path that produced the error or +annotation. + +### Keyword Interactions +Keyword behavior MAY be defined in terms of the annotation results of +[subschemas](#435-root-schema-and-subschemas-and-resources) and/or adjacent +keywords (keywords within the same schema object) and their subschemas. Such +keywords MUST NOT result in a circular dependency. Keywords MAY modify their +behavior based on the presence or absence of another keyword in the same [schema +object](#43-json-schema-documents). + +### Default Behaviors +A missing keyword MUST NOT produce a false assertion result, MUST NOT produce +annotation results, and MUST NOT cause any other schema to be evaluated as part +of its own behavioral definition. However, given that missing keywords do not +contribute annotations, the lack of annotation results may indirectly change the +behavior of other keywords. + +In some cases, the missing keyword assertion behavior of a keyword is identical +to that produced by a certain value, and keyword definitions SHOULD note such +values where known. However, even if the value which produces the default +behavior would produce annotation results if present, the default behavior still +MUST NOT result in annotations. + +Because annotation collection can add significant cost in terms of both +computation and memory, implementations MAY opt out of this feature. Keywords +that are specified in terms of collected annotations SHOULD describe reasonable +alternate approaches when appropriate. This approach is demonstrated by the +[`items`](#10312-items) and +[`additionalProperties`](#10323-additionalproperties) keywords in this document. + +Note that when no such alternate approach is possible for a keyword, +implementations that do not support annotation collections will not be able to +support those keywords or vocabularies that contain them. + +### Identifiers +Identifiers define IRIs for a schema, or affect how such IRIs are resolved in +[references](#824-schema-references), or both. The Core vocabulary defined in +this document defines several identifying keywords, most notably `$id`. + +Canonical schema IRIs MUST NOT change while processing an instance, but keywords +that affect IRI-reference resolution MAY have behavior that is only fully +determined at runtime. + +While custom identifier keywords are possible, vocabulary designers should take +care not to disrupt the functioning of core keywords. For example, the +`$dynamicAnchor` keyword in this specification limits its IRI resolution effects +to the matching `$dynamicRef` keyword, leaving the behavior of `$ref` +undisturbed. + +### Applicators +Applicators allow for building more complex schemas than can be accomplished +with a single schema object. Evaluation of an instance against a [schema +document](#43-json-schema-documents) begins by applying the [root +schema](#435-root-schema-and-subschemas-and-resources) to the complete instance +document. From there, keywords known as applicators are used to determine which +additional schemas are applied. Such schemas may be applied in-place to the +current location, or to a child location. + +The schemas to be applied may be present as subschemas comprising all or part of +the keyword's value. Alternatively, an applicator may refer to a schema +elsewhere in the same schema document, or in a different one. The mechanism for +identifying such referenced schemas is defined by the keyword. + +Applicator keywords also define how subschema or referenced schema boolean +[assertion](#76-assertions) results are modified and/or combined to produce the +boolean result of the applicator. Applicators may apply any boolean logic +operation to the assertion results of subschemas, but MUST NOT introduce new +assertion conditions of their own. + +[Annotation](#77-annotations) results from subschemas are preserved in +accordance with [Section 7.7.1](#771-collecting-annotations) so that +applications can decide how to interpret multiple values. Applicator keywords +do not play a direct role in this preservation. + +#### Referenced and Referencing Schemas +As noted in [Section 7.5](#75-applicators), an applicator keyword may refer to a +schema to be applied, rather than including it as a subschema in the +applicator's value. In such situations, the schema being applied is known as +the referenced schema, while the schema containing the applicator keyword is the +referencing schema. + +While root schemas and subschemas are static concepts based on a schema's +position within a schema document, referenced and referencing schemas are +dynamic. Different pairs of schemas may find themselves in various referenced +and referencing arrangements during the evaluation of an instance against a +schema. + +For some by-reference applicators, such as +[`$ref`](#8241-direct-references-with-ref), the referenced schema can be +determined by static analysis of the schema document's lexical scope. Others, +such as `$dynamicRef` (with `$dynamicAnchor`), may make use of dynamic scoping, +and therefore only be resolvable in the process of evaluating the schema with an +instance. + +### Assertions +JSON Schema can be used to assert constraints on a JSON document, which either +passes or fails the assertions. This approach can be used to validate +conformance with the constraints, or document what is needed to satisfy them. + +JSON Schema implementations produce a single boolean result when evaluating an +instance against schema assertions. + +An instance can only fail an assertion that is present in the schema. + +#### Assertions and Instance Primitive Types +Most assertions only constrain values within a certain primitive type. When the +type of the instance is not of the type targeted by the keyword, the instance is +considered to conform to the assertion. + +For example, the `maxLength` keyword from the companion [validation +vocabulary](#json-schema-validation): will only restrict certain strings (that +are too long) from being valid. If the instance is a number, boolean, null, +array, or object, then it is valid against this assertion. + +This behavior allows keywords to be used more easily with instances that can be +of multiple primitive types. The companion validation vocabulary also includes +a `type` keyword which can independently restrict the instance to one or more +primitive types. This allows for a concise expression of use cases such as a +function that might return either a string of a certain length or a null value: + +```json +{ + "type": ["string", "null"], + "maxLength": 255 +} +``` + +If `maxLength` also restricted the instance type to be a string, then this would +be substantially more cumbersome to express because the example as written would +not actually allow null values. Each keyword is evaluated separately unless +explicitly specified otherwise, so if `maxLength` restricted the instance to +strings, then including `"null"` in `type` would not have any useful effect. + +### Annotations +JSON Schema can annotate an instance with information, whenever the instance +validates against the schema object containing the annotation, and all of its +parent schema objects. The information can be a simple value, or can be +calculated based on the instance contents. + +Annotations are attached to specific locations in an instance. Since many +subschemas can be applied to any single location, applications may need to +decide how to handle differing annotation values being attached to the same +instance location by the same schema keyword in different schema objects. + +Unlike assertion results, annotation data can take a wide variety of forms, +which are provided to applications to use as they see fit. JSON Schema +implementations are not expected to make use of the collected information on +behalf of applications. + +Unless otherwise specified, the value of an annotation keyword is the keyword's +value. However, other behaviors are possible. For example, [JSON +Hyper-Schema's](#json-hyper-schema) `links` keyword is a complex annotation that +produces a value based in part on the instance data. + +While "short-circuit" evaluation is possible for assertions, collecting +annotations requires examining all schemas that apply to an instance location, +even if they cannot change the overall assertion result. The only exception is +that subschemas of a schema object that has failed validation MAY be skipped, as +annotations are not retained for failing schemas. + +#### Collecting Annotations +Annotations are collected by keywords that explicitly define +annotation-collecting behavior. Note that boolean schemas cannot produce +annotations as they do not make use of keywords. + +A collected annotation MUST include the following information: + +- The name of the keyword that produces the annotation +- The instance location to which it is attached, as a JSON Pointer +- The evaluation path, indicating how reference keywords such as `$ref` were +followed to reach the absolute schema location. +- The absolute schema location of the attaching keyword, as a IRI. This MAY be +omitted if it is the same as the evaluation path from above. +- The attached value(s) + +##### Distinguishing Among Multiple Values +Applications MAY make decisions on which of multiple annotation values to use +based on the schema location that contributed the value. This is intended to +allow flexible usage. Collecting the schema location facilitates such usage. + +For example, consider this schema, which uses annotations and assertions from +the [Validation specification](#json-schema-validation): + +Note that some lines are wrapped for clarity. + +```json +{ + "title": "Feature list", + "type": "array", + "prefixItems": [ + { + "title": "Feature A", + "properties": { + "enabled": { + "$ref": "#/$defs/enabledToggle", + "default": true + } + } + }, + { + "title": "Feature B", + "properties": { + "enabled": { + "description": "If set to null, Feature B + inherits the enabled + value from Feature A", + "$ref": "#/$defs/enabledToggle" + } + } + } + ], + "$defs": { + "enabledToggle": { + "title": "Enabled", + "description": "Whether the feature is enabled (true), + disabled (false), or under + automatic control (null)", + "type": ["boolean", "null"], + "default": null + } + } +} +``` + +In this example, both Feature A and Feature B make use of the re-usable +"enabledToggle" schema. That schema uses the `title`, `description`, and +`default` annotations. Therefore the application has to decide how to handle +the additional `default` value for Feature A, and the additional `description` +value for Feature B. + +The application programmer and the schema author need to agree on the usage. For +this example, let's assume that they agree that the most specific `default` +value will be used, and any additional, more generic `default` values will be +silently ignored. Let's also assume that they agree that all `description` text +is to be used, starting with the most generic, and ending with the most +specific. This requires the schema author to write descriptions that work when +combined in this way. + +The application can use the evaluation path to determine which values are which. +The values in the feature's immediate "enabled" property schema are more +specific, while the values under the re-usable schema that is referenced to with +`$ref` are more generic. The evaluation path will show whether each value was +found by crossing a `$ref` or not. + +Feature A will therefore use a default value of true, while Feature B will use +the generic default value of null. Feature A will only have the generic +description from the "enabledToggle" schema, while Feature B will use that +description, and also append its locally defined description that explains how +to interpret a null value. + +Note that there are other reasonable approaches that a different application +might take. For example, an application may consider the presence of two +different values for `default` to be an error, regardless of their schema +locations. + +##### Annotations and Assertions +Schema objects that produce a false assertion result MUST NOT produce any +annotation results, whether from their own keywords or from keywords in +subschemas. + +Note that the overall schema results may still include annotations collected +from other schema locations. Given this schema: + +```json +{ + "oneOf": [ + { + "title": "Integer Value", + "type": "integer" + }, + { + "title": "String Value", + "type": "string" + } + ] +} +``` + +Against the instance `"This is a string"`, the title annotation "Integer Value" +is discarded because the type assertion in that schema object fails. The title +annotation "String Value" is kept, as the instance passes the string type +assertions. + +### Reserved Locations +A fourth category of keywords simply reserve a location to hold re-usable +components or data of interest to schema authors that is not suitable for +re-use. These keywords do not affect validation or annotation results. Their +purpose in the core vocabulary is to ensure that locations are available for +certain purposes and will not be redefined by extension keywords. + +While these keywords do not directly affect results, as explained in [Section +9.4.2](#942-references-to-possible-non-schemas) unrecognized extension keywords +that reserve locations for re-usable schemas may have undesirable interactions +with references in certain circumstances. + +### Loading Instance Data +While none of the vocabularies defined as part of this or the associated +documents define a keyword which may target and/or load instance data, it is +possible that other vocabularies may wish to do so. + +Keywords MAY be defined to use JSON Pointers or Relative JSON Pointers to +examine parts of an instance outside the current evaluation location. + +Keywords that allow adjusting the location using a Relative JSON Pointer SHOULD +default to using the current location if a default is desireable. + +## The JSON Schema Core Vocabulary +Keywords declared in this section, which all begin with "$", make up the JSON +Schema Core vocabulary. These keywords are either required in order to process +any schema or meta-schema, including those split across multiple documents, or +exist to reserve keywords for purposes that require guaranteed interoperability. + +The Core vocabulary MUST be considered mandatory at all times, in order to +bootstrap the processing of further vocabularies. Meta-schemas that use the +[`$vocabulary`](#81-meta-schemas-and-vocabularies) keyword to declare the +vocabularies in use MUST explicitly list the Core vocabulary, which MUST have a +value of true indicating that it is required. + +The behavior of a false value for this vocabulary (and only this vocabulary) is +undefined, as is the behavior when `$vocabulary` is present but the Core +vocabulary is not included. However, it is RECOMMENDED that implementations +detect these cases and raise an error when they occur. It is not meaningful to +declare that a meta-schema optionally uses Core. + +Meta-schemas that do not use `$vocabulary` MUST be considered to require the +Core vocabulary as if its IRI were present with a value of true. + +The current IRI for the Core vocabulary is: +`https://json-schema.org/draft/next/vocab/core`. + +The current IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/core`. + +The "$" prefix is reserved for use by the Core vocabulary. Vocabulary extensions +MUST NOT define new keywords that begin with "$". + +### Meta-Schemas and Vocabularies +Two concepts, meta-schemas and vocabularies, are used to inform an +implementation how to interpret a schema. Every schema has a meta-schema, which +can be declared using the `$schema` keyword. + +The meta-schema serves two purposes: + +Declaring the vocabularies in use: The `$vocabulary` keyword, when it appears in +a meta-schema, declares which vocabularies are available to be used in schemas +that refer to that meta-schema. Vocabularies define keyword semantics, as well +as their general syntax. + +Describing valid schema syntax: A schema MUST successfully validate against its +meta-schema, which constrains the syntax of the available keywords. The syntax +described is expected to be compatible with the vocabularies declared; while it +is possible to describe an incompatible syntax, such a meta-schema would be +unlikely to be useful. + +Meta-schemas are separate from vocabularies to allow for vocabularies to be +combined in different ways, and for meta-schema authors to impose additional +constraints such as forbidding certain keywords, or performing unusually strict +syntactical validation, as might be done during a development and testing cycle. +Each vocabulary typically identifies a meta-schema consisting only of the +vocabulary's keywords. + +Meta-schema authoring is an advanced usage of JSON Schema, so the design of +meta-schema features emphasizes flexibility over simplicity. + +#### The $schema Keyword +The `$schema` keyword is both used as a JSON Schema dialect identifier and as +the identifier of a resource which is itself a JSON Schema, which describes the +set of valid schemas written for this particular dialect. + +The value of this keyword MUST be a [IRI](#rfc3987) (containing a scheme) and +this IRI MUST be normalized. The current schema MUST be valid against the +meta-schema identified by this IRI. + +If this IRI identifies a retrievable resource, that resource SHOULD be of media +type `application/schema+json`. + +The `$schema` keyword SHOULD be used in the document root schema object, and MAY +be used in the root schema objects of embedded schema resources. It MUST NOT +appear in non-resource root schema objects. If absent from the document root +schema, the resulting behavior is implementation-defined, but MUST fall within +the following options: + +- Refuse to process the schema, as with unsupported required vocabularies +- Assume a specific, documented meta-schema +- Document the process by which it examines the schema and determines which of a +specific set of meta-schemas to assume + +Values for this property are defined elsewhere in this and other documents, and +by other parties. + +#### The $vocabulary Keyword +The `$vocabulary` keyword is used in meta-schemas to identify the vocabularies +available for use in schemas described by that meta-schema, and whether each +vocabulary is required or optional. Together, this information forms a dialect. + +The value of this keyword MUST be an object. The property names in the object +MUST be IRIs (containing a scheme) and each IRI MUST be normalized. Each IRI +that appears as a property name identifies a specific set of keywords and their +semantics. + +The IRI MAY be a URL, but the nature of the retrievable resource is currently +undefined, and reserved for future use. Vocabulary authors MAY use the URL of +the vocabulary specification, in a human-readable media type such as `text/html` +or `text/plain`, as the vocabulary IRI.[^2] + +[^2]: Vocabulary documents may be added in forthcoming drafts. For now, +identifying the keyword set is deemed sufficient as that, along with meta-schema +validation, is how the current "vocabularies" work today. Any future vocabulary +document format will be specified as a JSON document, so using `text/html` or +other non-JSON formats in the meantime will not produce any future ambiguity. + +The values of the object properties MUST be booleans. If the value is true, then +the vocabulary MUST be considered to be required. If the value is false, then +the vocabulary MUST be considered to be optional. + +##### Required, optional, and omitted vocabularies +A schema is said to use a dialect and its constituent vocabularies if it is +associated with a meta-schema defining the dialect with `$vocabulary`, either +through `$schema`, through appropriately defined media type parameters or link +relation types, or through documented default implementation-defined behavior in +the absence of an explicit meta-schema. If a meta-schema does not contain +`$vocabulary`, the set of vocabularies in use is determined according to +[Section 8.1.2.4](#8124-default-vocabularies). + +Any vocabulary in use by a schema and understood by the implementation MUST be +processed in a manner consistent with the semantic definitions contained within +the vocabulary, regardless of whether that vocabulary is required or optional. + +Any vocabulary that is not present in `$vocabulary` MUST NOT be made available +for use in schemas described by that meta-schema, except for the core vocabulary +as specified by the introduction to [Section +8](#8-the-json-schema-core-vocabulary). + +Implementations that do not support a vocabulary required by a schema MUST +refuse to process that schema. + +Implementations that do not support a vocabulary that is optionally used by a +schema SHOULD proceed with processing the schema. The keywords will be +considered to be unrecognized keywords as addressed by [Section +6.5.2](#652-handling-of-unrecognized-or-unsupported-keywords). Note that since +the recommended behavior for such keywords is to collect them as annotations, +vocabularies consisting only of annotations will have the same behavior when +used optionally whether the implementation supports them or not. This allows +annotation-only vocabularies to be supported without custom code, even in +implementations that do not support providing custom code for extension +vocabularies. + +##### Vocabularies are schema resource-scoped +The `$vocabulary` keyword SHOULD be used in the root schema of any schema +resource intended for use as a meta-schema. It MUST NOT appear in subschemas. + +The `$vocabulary` keyword MUST be ignored in schema resources that are not being +processed as a meta-schema. This allows validating a meta-schema M against its +own meta-schema M' without requiring the validator to understand the +vocabularies declared by M. + +##### Vocabulary and non-vocabulary keywords +Keywords from different vocabularies, as well as non-vocabulary extension +keywords, can have identical names. These are not considered to be the same +keyword from the perspective of enabling or disabling them through +`$vocabulary`. + +In particular the keywords defined in this specification and its companion +documents MUST be considered to be vocabulary keywords, with availability +governed by `$vocabulary` even in implementations that do not support any +extension vocabularies. + +Guidance regarding vocabularies with identically-named keywords is provided in +[Appendix D.1](#d1-best-practices-for-vocabulary-and-meta-schema-authors). + +##### Default vocabularies +If `$vocabulary` is absent, an implementation MAY determine behavior based on +the meta-schema if it is recognized from the IRI value of the referring schema's +`$schema` keyword. This is how behavior (such as Hyper-Schema usage) has been +recognized prior to the existence of vocabularies. + +If the meta-schema, as referenced by the schema, is not recognized, or is +missing, then the behavior is implementation-defined. If the implementation +proceeds with processing the schema, it MUST assume the use of the core +vocabulary. If the implementation is built for a specific purpose, then it +SHOULD assume the use of all of the most relevant vocabularies for that purpose. + +For example, an implementation that is a validator SHOULD assume the use of all +vocabularies in this specification and the companion Validation specification. + +##### Non-inheritability of vocabularies +Note that the processing restrictions on `$vocabulary` mean that meta-schemas +that reference other meta-schemas using `$ref` or similar keywords do not +automatically inherit the vocabulary declarations of those other meta-schemas. +All such declarations must be repeated in the root of each schema document +intended for use as a meta-schema. This is demonstrated in [the example +meta-schema](#d2-example-meta-schema-with-vocabulary-declarations).[^3] + +[^3]: This requirement allows implementations to find all vocabulary requirement +information in a single place for each meta-schema. As schema extensibility +means that there are endless potential ways to combine more fine-grained +meta-schemas by reference, requiring implementations to anticipate all +possibilities and search for vocabularies in referenced meta-schemas would be +overly burdensome. + +#### Updates to Meta-Schema and Vocabulary IRIs +Updated vocabulary and meta-schema IRIs MAY be published between specification +drafts in order to correct errors. Implementations SHOULD consider IRIs dated +after this specification draft and before the next to indicate the same syntax +and semantics as those listed here. + +### Base IRI, Anchors, and Dereferencing +To differentiate between schemas in a vast ecosystem, schemas are identified by +[IRI](#rfc3987), and can embed references to other schemas by specifying their +IRI. + +Several keywords can accept a relative [IRI-reference](#rfc3987), or a value +used to construct a relative IRI-reference. For these keywords, it is necessary +to establish a base IRI in order to resolve the reference. + +#### The $id Keyword +The `$id` keyword identifies a schema resource with its [canonical](#rfc6596) +IRI. + +Note that this IRI is an identifier and not necessarily a network locator. In +the case of a network-addressable URL, a schema need not be downloadable from +its canonical IRI. + +If present, the value for this keyword MUST be a string, and MUST represent a +valid [IRI-reference](#rfc3987). This IRI-reference SHOULD be normalized, and +MUST resolve to an [absolute-IRI](#rfc3987) (without a fragment). + +The resulting absolute-IRI serves as the base IRI for relative IRI-references in +keywords within the schema resource, in accordance with [RFC 3987 section +6.5](#rfc3987) and [RFC 3986 section 5.1.1](#rfc3986) regarding base IRIs +embedded in content. + +The presence of `$id` in a subschema indicates that the subschema constitutes a +distinct schema resource within a single schema document. Furthermore, in +accordance with [RFC 3987 section 6.5](#rfc3987) and [RFC 3986 section +5.1.2](#rfc3986) regarding encapsulating entities, if an `$id` in a subschema is +a relative IRI-reference, the base IRI for resolving that reference is the IRI +of the parent schema resource. Note that an `$id` consisting of an empty IRI or +of the empty fragment only will result in the embedded resource having the same +IRI as the encapsulating resource, which SHOULD be considered an error per +[Section 8.2.3](#823-duplicate-schema-identifiers). + +If no parent schema object explicitly identifies itself as a resource with +`$id`, the base IRI is that of the entire document, as established by the steps +given in the [previous section.](#911-initial-base-iri) + +##### Identifying the root schema +The root schema of a JSON Schema document SHOULD contain an `$id` keyword with +an [absolute-IRI](#rfc3987) (containing a scheme, but no fragment). + +#### Defining location-independent identifiers +Using JSON Pointer fragments requires knowledge of the structure of the schema. +When writing schema documents with the intention to provide re-usable schemas, +it may be preferable to use a plain name fragment that is not tied to any +particular structural location. This allows a subschema to be relocated without +requiring JSON Pointer references to be updated. + +The `$anchor` and `$dynamicAnchor` keywords are used to specify such fragments. +They are identifier keywords that can only be used to create plain name +fragments, rather than absolute IRIs as seen with `$id`. + +The base IRI to which the resulting fragment is appended is the canonical IRI of +the schema resource containing the `$anchor` or `$dynamicAnchor` in question. +As discussed in the previous section, this is either the nearest `$id` in the +same or parent schema object, or the base IRI for the document as determined +according to [RFC 3987](#rfc3987) and [RFC 3986](#rfc3986). + +Separately from the usual usage of IRIs, `$dynamicAnchor` indicates that the +fragment is an extension point when used with the `$dynamicRef` keyword. This +low-level, advanced feature makes it easier to extend recursive schemas such as +the meta-schemas, without imposing any particular semantics on that extension. +See the section on [`$dynamicRef`](#8242-dynamic-references-with-dynamicref) +for details. + +In most cases, the normal fragment behavior both suffices and is more intuitive. +Therefore it is RECOMMENDED that `$anchor` be used to create plain name +fragments unless there is a clear need for `$dynamicAnchor`. + +If present, the value of these keywords MUST be a string and MUST conform to the +plain name fragment identifier syntax defined in [Section +5](#5-fragment-identifiers).[^4] + +[^4]: Note that the anchor string does not include the "#" character, as it is +not a IRI-reference. An `$anchor`: "foo" becomes the fragment `#foo` when used +in a IRI. See below for full examples. + +#### Duplicate schema identifiers +A schema MAY (and likely will) have multiple IRIs, but there is no way for an +IRI to identify more than one schema. When multiple schemas attempt to identify +as the same IRI through the use of `$id`, `$anchor`, `$dynamicAnchor`, or any +other mechanism, implementations SHOULD raise an error condition. Otherwise the +result is undefined, and even if documented will not be interoperable. + +#### Schema References +Several keywords can be used to reference a schema which is to be applied to the +current instance location. `$ref` and `$dynamicRef` are applicator keywords, +applying the referenced schema to the instance. + +As the values of `$ref` and `$dynamicRef` are IRI References, this allows the +possibility to externalise or divide a schema across multiple files, and +provides the ability to validate recursive structures through self-reference. + +The resolved IRI produced by these keywords is not necessarily a network +locator, only an identifier. A schema need not be downloadable from the address +if it is a network-addressable URL, and implementations SHOULD NOT assume they +should perform a network operation when they encounter a network-addressable +IRI. + +##### Direct References with $ref +The `$ref` keyword is an applicator that is used to reference a statically +identified schema. Its results are the results of the referenced schema.[^5] + +[^5]: Note that this definition of how the results are determined means that +other keywords can appear alongside of `$ref` in the same schema object. + +The value of the `$ref` keyword MUST be a string which is a IRI-Reference. +Resolved against the current IRI base, it produces the IRI of the schema to +apply. This resolution is safe to perform on schema load, as the process of +evaluating an instance cannot change how the reference resolves. + +##### Dynamic References with $dynamicRef +The `$dynamicRef` keyword is an applicator that allows for deferring the full +resolution until runtime, at which point it is resolved each time it is +encountered while evaluating an instance. + +Together with `$dynamicAnchor`, `$dynamicRef` implements a cooperative extension +mechanism that is primarily useful with recursive schemas (schemas that +reference themselves). The extension point is defined with `$dynamicAnchor` and +only exhibits runtime dynamic behavior when referenced with `$dynamicRef`. + +The value of the `$dynamicRef` property MUST be a string which is a +IRI-Reference that contains a valid [plain name +fragment](#822-defining-location-independent-identifiers). Resolved against the +current IRI base, it indicates the schema resource used as the starting point +for runtime resolution. This initial resolution is safe to perform on schema +load. + +The schema to apply is the outermost schema resource in the [dynamic +scope](#71-lexical-scope-and-dynamic-scope) that defines a `$dynamicAnchor` that +matches the plain name fragment in the initially resolved IRI. + +For a full example using these keyword, see [Appendix +C](#appendix-c-example-of-recursive-schema-extension).[^6] + +[^6]: The difference between the hyper-schema meta-schema in pre-2019 drafts and +an this draft dramatically demonstrates the utility of these keywords. + +#### Schema Re-Use With $defs +The `$defs` keyword reserves a location for schema authors to inline re-usable +JSON Schemas into a more general schema. The keyword does not directly affect +the validation result. + +This keyword's value MUST be an object. Each member value of this object MUST be +a valid JSON Schema. + +As an example, here is a schema describing an array of positive integers, where +the positive integer constraint is a subschema in `$defs`: + +```json +{ + "type": "array", + "items": { "$ref": "#/$defs/positiveInteger" }, + "$defs": { + "positiveInteger": { + "type": "integer", + "exclusiveMinimum": 0 + } + } +} +``` + +### Comments With $comment +This keyword reserves a location for comments from schema authors to readers or +maintainers of the schema. + +The value of this keyword MUST be a string. Implementations MUST NOT present +this string to end users. Tools for editing schemas SHOULD support displaying +and editing this keyword. The value of this keyword MAY be used in debug or +error output which is intended for developers making use of schemas. + +Schema vocabularies SHOULD allow `$comment` within any object containing +vocabulary keywords. Implementations MAY assume `$comment` is allowed unless +the vocabulary specifically forbids it. Vocabularies MUST NOT specify any +effect of `$comment` beyond what is described in this specification. + +Tools that translate other media types or programming languages to and from +`application/schema+json` MAY choose to convert that media type or programming +language's native comments to or from `$comment` values. The behavior of such +translation when both native comments and `$comment` properties are present is +implementation-dependent. + +Implementations MAY strip `$comment` values at any point during processing. In +particular, this allows for shortening schemas when the size of deployed schemas +is a concern. + +Implementations MUST NOT take any other action based on the presence, absence, +or contents of `$comment` properties. In particular, the value of `$comment` +MUST NOT be collected as an annotation result. + +## Loading and Processing Schemas + +### Loading a Schema + +#### Initial Base IRI +[RFC 3987 Section 6.5](#rfc3987) and [RFC 3986 Section 5.1](#rfc3986) defines +how to determine the default base IRI of a document. + +Informatively, the initial base IRI of a schema is the IRI at which it was +found, whether that was a network location, a local filesystem, or any other +situation identifiable by a IRI of any known scheme. + +If a schema document defines no explicit base IRI with `$id` (embedded in +content), the base IRI is that determined per [RFC 3987 Section 6.5](#rfc3987) +and [RFC 3986 section 5](#rfc3986). + +If no source is known, or no IRI scheme is known for the source, a suitable +implementation-specific default IRI MAY be used as described in [RFC 3987 +Section 6.5](#rfc3987) and [RFC 3986 Section 5.1.4](#rfc3986). It is +RECOMMENDED that implementations document any default base IRI that they assume. + +If a schema object is embedded in a document of another media type, then the +initial base IRI is determined according to the rules of that media type. + +Unless the `$id` keyword described in an earlier section is present in the root +schema, this base IRI SHOULD be considered the canonical IRI of the schema +document's root schema resource. + +#### Loading a referenced schema +The use of IRIs to identify remote schemas does not necessarily mean anything is +downloaded, but instead JSON Schema implementations SHOULD understand ahead of +time which schemas they will be using, and the IRIs that identify them. + +When schemas are downloaded, for example by a generic user-agent that does not +know until runtime which schemas to download, see [Usage for +Hypermedia](#951-usage-for-hypermedia). + +Implementations SHOULD be able to associate arbitrary IRIs with an arbitrary +schema and/or automatically associate a schema's `$id`-given IRI, depending on +the trust that the validator has in the schema. Such IRIs and schemas can be +supplied to an implementation prior to processing instances, or may be noted +within a schema document as it is processed, producing associations as shown in +[Appendix A](#appendix-a-schema-identification-examples). + +#### Detecting a Meta-Schema +Implementations MUST recognize a schema as a meta-schema if it is being examined +because it was identified as such by another schema's `$schema` keyword. This +means that a single schema document might sometimes be considered a regular +schema, and other times be considered a meta-schema. + +In the case of examining a schema which is its own meta-schema, when an +implementation begins processing it as a regular schema, it is processed under +those rules. However, when loaded a second time as a result of checking its own +`$schema` value, it is treated as a meta-schema. So the same document is +processed both ways in the course of one session. + +Implementations MAY allow a schema to be explicitly passed as a meta-schema, for +implementation-specific purposes, such as pre-loading a commonly used +meta-schema and checking its vocabulary support requirements up front. +Meta-schema authors MUST NOT expect such features to be interoperable across +implementations. + +### Dereferencing +Schemas can be identified by any IRI that has been given to them, including a +JSON Pointer or their IRI given directly by `$id`. In all cases, dereferencing +a `$ref` reference involves first resolving its value as a IRI reference against +the current base IRI per [RFC 3986](#rfc3986). + +If the resulting IRI identifies a schema within the current document, or within +another schema document that has been made available to the implementation, then +that schema SHOULD be used automatically. + +For example, consider this schema: + +```json +{ + "$id": "https://example.net/root.json", + "type": "array", + "items": { "$ref": "#item" }, + "$defs": { + "single": { + "$anchor": "item", + "type": "object", + "additionalProperties": { "$ref": "other.json" } + } + } +} +``` + +When an implementation encounters the `#/$defs/single` schema, it resolves the +`$anchor` value as a fragment name against the current base IRI to form +`https://example.net/root.json#item`. + +When an implementation then looks inside the `#/items` schema, it encounters the +`#item` reference, and resolves this to `https://example.net/root.json#item`, +which it has seen defined in this same document and can therefore use +automatically. + +When an implementation encounters the reference to "other.json", it resolves +this to `https://example.net/other.json`, which is not defined in this document. +If a schema with that identifier has otherwise been supplied to the +implementation, it can also be used automatically.[^7] + +[^7]: What should implementations do when the referenced schema is not known? +Are there circumstances in which automatic network dereferencing is allowed? A +same origin policy? A user-configurable option? In the case of an evolving API +described by Hyper-Schema, it is expected that new schemas will be added to the +system dynamically, so placing an absolute requirement of pre-loading schema +documents is not feasible. + +#### JSON Pointer fragments and embedded schema resources +Since JSON Pointer IRI fragments are constructed based on the structure of the +schema document, an embedded schema resource and its subschemas can be +identified by JSON Pointer fragments relative to either its own canonical IRI, +or relative to any containing resource's IRI. + +Conceptually, a set of linked schema resources should behave identically whether +each resource is a separate document connected with [schema +references](#824-schema-references), or is structured as a single document with +one or more schema resources embedded as subschemas. + +Since IRIs involving JSON Pointer fragments relative to the parent schema +resource's IRI cease to be valid when the embedded schema is moved to a separate +document and referenced, applications and schemas SHOULD NOT use such IRIs to +identify embedded schema resources or locations within them. + +Consider the following schema document that contains another schema resource +embedded within it: + +```json +{ + "$id": "https://example.com/foo", + "items": { + "$id": "https://example.com/bar", + "additionalProperties": { } + } +} +``` + +The IRI `https://example.com/foo#/items` points to the `items` schema, which is +an embedded resource. The canonical IRI of that schema resource, however, is +`https://example.com/bar`. + +For the `additionalProperties` schema within that embedded resource, the IRI +`https://example.com/foo#/items/additionalProperties` points to the correct +object, but that object's IRI relative to its resource's canonical IRI is +`https://example.com/bar#/additionalProperties`. + +Now consider the following two schema resources linked by reference using a IRI +value for `$ref`: + +```json +{ + "$id": "https://example.com/foo", + "items": { + "$ref": "bar" + } +} +``` + +```json +{ + "$id": "https://example.com/bar", + "additionalProperties": { } +} +``` + +Here we see that `https://example.com/bar#/additionalProperties`, using a JSON +Pointer fragment appended to the canonical IRI of the "bar" schema resource, is +still valid, while `https://example.com/foo#/items/additionalProperties`, which +relied on a JSON Pointer fragment appended to the canonical IRI of the "foo" +schema resource, no longer resolves to anything. + +Note also that `https://example.com/foo#/items` is valid in both arrangements, +but resolves to a different value. This IRI ends up functioning similarly to a +retrieval IRI for a resource. While this IRI is valid, it is more robust to use +the `$id` of the embedded or referenced resource unless it is specifically +desired to identify the object containing the `$ref` in the second +(non-embedded) arrangement. + +An implementation MAY choose not to support addressing schema resource contents +by IRIs using a base other than the resource's canonical IRI, plus a JSON +Pointer fragment relative to that base. Therefore, schema authors SHOULD NOT +rely on such IRIs, as using them may reduce interoperability.[^8] + +[^8]: This is to avoid requiring implementations to keep track of a whole stack +of possible base IRIs and JSON Pointer fragments for each, given that all but +one will be fragile if the schema resources are reorganized. Some have argued +that this is easy so there is no point in forbidding it, while others have +argued that it complicates schema identification and should be forbidden. +Feedback on this topic is encouraged. After some discussion, we feel that we +need to remove the use of "canonical" in favour of talking about JSON Pointers +which reference across schema resource boundaries as undefined or even forbidden +behavior (, +) + +Further examples of such non-canonical IRI construction, as well as the +appropriate canonical IRI-based fragments to use instead, are provided in +[Appendix A](#appendix-a-schema-identification-examples). + +### Compound Documents +A Compound Schema Document is defined as a JSON document (sometimes called a +"bundled" schema) which has multiple embedded JSON Schema Resources bundled into +the same document to ease transportation. + +Each embedded Schema Resource MUST be treated as an individual Schema Resource, +following standard schema loading and processing requirements, including +determining vocabulary support. + +#### Bundling +The bundling process for creating a Compound Schema Document is defined as +taking references (such as `$ref`) to an external Schema Resource and embedding +the referenced Schema Resources within the referring document. Bundling SHOULD +be done in such a way that all IRIs (used for referencing) in the base document +and any referenced/embedded documents do not require altering. + +Each embedded JSON Schema Resource MUST identify itself with a IRI using the +`$id` keyword, and SHOULD make use of the `$schema` keyword to identify the +dialect it is using, in the root of the schema resource. It is RECOMMENDED that +the IRI identifier value of `$id` be an Absolute IRI. + +When the Schema Resource referenced by a by-reference applicator is bundled, it +is RECOMMENDED that the Schema Resource be located as a value of a `$defs` +object at the containing schema's root. The key of the `$defs` for the now +embedded Schema Resource MAY be the `$id` of the bundled schema or some other +form of application defined unique identifer (such as a UUID). This key is not +intended to be referenced in JSON Schema, but may be used by an application to +aid the bundling process. + +A Schema Resource MAY be embedded in a location other than `$defs` where the +location is defined as a schema value. + +A Bundled Schema Resource MUST NOT be bundled by replacing the schema object +from which it was referenced, or by wrapping the Schema Resource in other +applicator keywords. + +In order to produce identical output, references in the containing schema +document to the previously external Schema Resources MUST NOT be changed, and +now resolve to a schema using the `$id` of an embedded Schema Resource. Such +identical output includes validation evaluation and IRIs or paths used in +resulting annotations or errors. + +While the bundling process will often be the main method for creating a Compound +Schema Document, it is also possible and expected that some will be created by +hand, potentially without individual Schema Resources existing on their own +previously. + +#### Differing and Default Dialects +When multiple schema resources are present in a single document, schema +resources which do not define with which dialect they should be processed MUST +be processed with the same dialect as the enclosing resource. + +Since any schema that can be referenced can also be embedded, embedded schema +resources MAY specify different processing dialects using the `$schema` values +from their enclosing resource. + +#### Validating +Given that a Compound Schema Document may have embedded resources which identify +as using different dialects, these documents SHOULD NOT be validated by applying +a meta-schema to the Compound Schema Document as an instance. It is RECOMMENDED +that an alternate validation process be provided in order to validate Schema +Documents. Each Schema Resource SHOULD be separately validated against its +associated meta-schema.[^9] + +[^9]: If you know a schema is what's being validated, you can identify if the +schemas is a Compound Schema Document or not, by way of use of `$id`, which +identifies an embedded resource when used not at the document's root. + +A Compound Schema Document in which all embedded resources identify as using the +same dialect, or in which `$schema` is omitted and therefore defaults to that of +the enclosing resource, MAY be validated by applying the appropriate +meta-schema. + +### Caveats + +#### Guarding Against Infinite Recursion +A schema MUST NOT be run into an infinite loop against an instance. For example, +if two schemas `#alice` and `#bob` both have an `allOf` property that refers to +the other, a naive validator might get stuck in an infinite recursive loop +trying to validate the instance. Schemas SHOULD NOT make use of infinite +recursive nesting like this; the behavior is undefined. + +#### References to Possible Non-Schemas +Subschema objects (or booleans) are recognized by their use with known +applicator keywords or with location-reserving keywords such as +[`$defs`](#825-schema-re-use-with-defs) that take one or more subschemas as a +value. These keywords may be `$defs` and the standard applicators from this +document, or extension keywords from a known vocabulary, or +implementation-specific custom keywords. + +Multi-level structures of unknown keywords are capable of introducing nested +subschemas, which would be subject to the processing rules for `$id`. Therefore, +having a reference target in such an unrecognized structure cannot be reliably +implemented, and the resulting behavior is undefined. Similarly, a reference +target under a known keyword, for which the value is known not to be a schema, +results in undefined behavior in order to avoid burdening implementations with +the need to detect such targets.[^10] + +[^10]: These scenarios are analogous to fetching a schema over HTTP but +receiving a response with a Content-Type other than `application/schema+json`. +An implementation can certainly try to interpret it as a schema, but the origin +server offered no guarantee that it actually is any such thing. Therefore, +interpreting it as such has security implication and may produce unpredictable +results. + +Note that single-level custom keywords with identical syntax and semantics to +`$defs` do not allow for any intervening `$id` keywords, and therefore will +behave correctly under implementations that attempt to use any reference target +as a schema. However, this behavior is implementation-specific and MUST NOT be +relied upon for interoperability. + +### Associating Instances and Schemas + +#### Usage for Hypermedia +JSON has been adopted widely by HTTP servers for automated APIs and robots. This +section describes how to enhance processing of JSON documents in a more RESTful +manner when used with protocols that support media types and [Web +linking](#rfc8288). + +##### Linking to a Schema +It is RECOMMENDED that instances described by a schema provide a link to a +downloadable JSON Schema using the link relation "describedby", as defined by +[Linked Data Protocol 1.0, section 8.1](#w3crec-ldp-20150226). + +In HTTP, such links can be attached to any response using the [Link +header](#rfc8288). An example of such a header would be: + +``` +Link: ; rel="describedby" +``` + +##### Usage Over HTTP +When used for hypermedia systems over a network, [HTTP](#rfc7231) is frequently +the protocol of choice for distributing schemas. Misbehaving clients can pose +problems for server maintainers if they pull a schema over the network more +frequently than necessary, when it's instead possible to cache a schema for a +long period of time. + +HTTP servers SHOULD set long-lived caching headers on JSON Schemas. HTTP clients +SHOULD observe caching headers and not re-request documents within their +freshness period. Distributed systems SHOULD make use of a shared cache and/or +caching proxy. + +Clients SHOULD set or prepend a User-Agent header specific to the JSON Schema +implementation or software product. Since symbols are listed in decreasing order +of significance, the JSON Schema library name/version should precede the more +generic HTTP library name (if any). For example: + +``` +User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0 +``` + +Clients SHOULD be able to make requests with a "From" header so that server +operators can contact the owner of a potentially misbehaving script. + +## A Vocabulary for Applying Subschemas +This section defines a vocabulary of applicator keywords that are RECOMMENDED +for use as the basis of other vocabularies. + +Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this +vocabulary as if its IRI were present with a value of true. + +The current IRI for this vocabulary, known as the Applicator vocabulary, is: +`https://json-schema.org/draft/next/vocab/applicator`. + +The current IRI for the corresponding meta-schema is: `https://json-schema.org/draft/next/meta/applicator`. + +### Keyword Independence +Schema keywords typically operate independently, without affecting each other's +outcomes. + +For schema author convenience, there are some exceptions among the keywords in +this vocabulary: + +- `additionalProperties`, whose behavior is defined in terms of `properties` and +`patternProperties` +- `items`, whose behavior is defined in terms of `prefixItems` +- `contains`, whose behavior is affected by the presence and value of +`minContains` + +### Keywords for Applying Subschemas in Place +These keywords apply subschemas to the same location in the instance as the +parent schema is being applied. They allow combining or modifying the subschema +results in various ways. + +Subschemas of these keywords evaluate the instance completely independently such +that the results of one such subschema MUST NOT impact the results of sibling +subschemas. Therefore subschemas may be applied in any order. + +#### Keywords for Applying Subschemas With Logic +These keywords correspond to logical operators for combining or modifying the +boolean assertion results of the subschemas. They have no direct impact on +annotation collection, although they enable the same annotation keyword to be +applied to an instance location with different values. Annotation keywords +define their own rules for combining such values. + +##### allOf +This keyword's value MUST be a non-empty array. Each item of the array MUST be a +valid JSON Schema. + +An instance validates successfully against this keyword if it validates +successfully against all schemas defined by this keyword's value. + +##### anyOf +This keyword's value MUST be a non-empty array. Each item of the array MUST be a +valid JSON Schema. + +An instance validates successfully against this keyword if it validates +successfully against at least one schema defined by this keyword's value. Note +that when annotations are being collected, all subschemas MUST be examined so +that annotations are collected from each subschema that validates successfully. + +##### oneOf +This keyword's value MUST be a non-empty array. Each item of the array MUST be a +valid JSON Schema. + +An instance validates successfully against this keyword if it validates +successfully against exactly one schema defined by this keyword's value. + +##### not +This keyword's value MUST be a valid JSON Schema. + +An instance is valid against this keyword if it fails to validate successfully +against the schema defined by this keyword. + +#### Keywords for Applying Subschemas Conditionally +Three of these keywords work together to implement conditional application of a +subschema based on the outcome of another subschema. The fourth is a shortcut +for a specific conditional case. + +`if`, `then`, and `else` MUST NOT interact with each other across subschema +boundaries. In other words, an `if` in one branch of an `allOf` MUST NOT have +an impact on a `then` or `else` in another branch. + +There is no default behavior for `if`, `then`, or `else` when they are not +present. In particular, they MUST NOT be treated as if present with an empty +schema, and when `if` is not present, both `then` and `else` MUST be entirely +ignored. + +##### if +This keyword's value MUST be a valid JSON Schema. + +This validation outcome of this keyword's subschema has no direct effect on the +overall validation result. Rather, it controls which of the `then` or `else` +keywords are evaluated. + +Instances that successfully validate against this keyword's subschema MUST also +be valid against the subschema value of the `then` keyword, if present. + +Instances that fail to validate against this keyword's subschema MUST also be +valid against the subschema value of the `else` keyword, if present. + +If [annotations](#77-annotations) are being collected, they are collected from +this keyword's subschema in the usual way, including when the keyword is present +without either `then` or `else`. + +##### then +This keyword's value MUST be a valid JSON Schema. + +When `if` is present, and the instance successfully validates against its +subschema, then validation succeeds against this keyword if the instance also +successfully validates against this keyword's subschema. + +This keyword has no effect when `if` is absent, or when the instance fails to +validate against its subschema. Implementations MUST NOT evaluate the instance +against this keyword, for either validation or annotation collection purposes, +in such cases. + +##### else +This keyword's value MUST be a valid JSON Schema. + +When `if` is present, and the instance fails to validate against its subschema, +then validation succeeds against this keyword if the instance successfully +validates against this keyword's subschema. + +This keyword has no effect when `if` is absent, or when the instance +successfully validates against its subschema. Implementations MUST NOT evaluate +the instance against this keyword, for either validation or annotation +collection purposes, in such cases. + +##### dependentSchemas +This keyword specifies subschemas that are evaluated if the instance is an +object and contains a certain property. + +This keyword's value MUST be an object. Each value in the object MUST be a valid +JSON Schema. + +If the object key is a property in the instance, the entire instance must +validate against the subschema. Its use is dependent on the presence of the +property. + +Omitting this keyword has the same behavior as an empty object. + +##### propertyDependencies +This keyword specifies subschemas that are evaluated if the instance is an +object and contains a certain property with a certain string value. + +This keyword's value MUST be an object. Each value in the object MUST be an +object whose values MUST be valid JSON Schemas. + +If the outer object key is a property in the instance and the inner object key +is equal to the value of that property, the entire instance must validate +against the schema. Its use is dependent on the presence and value of the +property. + +Omitting this keyword has the same behavior as an empty object. + +### Keywords for Applying Subschemas to Child Instances +Each of these keywords defines a rule for applying its subschema(s) to child +instances, specifically object properties and array items, and combining their +results. + +#### Keywords for Applying Subschemas to Arrays + +##### prefixItems +The value of "prefixItems` MUST be a non-empty array of valid JSON Schemas. + +Validation succeeds if each element of the instance validates against the +subschema at the same position, if any. This keyword does not constrain the +length of the array. Only array positions present in both the keyword's value +and the instance value are affected by this keyword. + +This keyword produces an annotation value which is the largest index to which +this keyword applied a subschema. The value MAY be a boolean true if a subschema +was applied to every index of the instance, such as is produced by the `items` +keyword. This annotation affects the behavior of `items` and +`unevaluatedItems`. + +Omitting this keyword has the same assertion behavior as an empty array. + +##### items +The value of `items` MUST be a valid JSON Schema. + +This keyword applies its subschema to all instance elements at indexes greater +than the length of the `prefixItems` array in the same schema object, as +reported by the annotation result of that `prefixItems` keyword. If no such +annotation result exists, `items` applies its subschema to all instance array +elements.[^11] + +[^11]: Note that the behavior of `items` without `prefixItems` is identical to +that of the schema form of `items` in prior drafts. When `prefixItems` is +present, the behavior of `items` is identical to the former `additionalItems` +keyword. + +If the `items` subschema is applied to any positions within the instance array, +it produces an annotation result of boolean true, indicating that all remaining +array elements have been evaluated against this keyword's subschema. This +annotation affects the behavior of `unevaluatedItems` in the Unevaluated +vocabulary. + +Omitting this keyword has the same assertion behavior as an empty schema. + +Implementations MAY choose to implement or optimize this keyword in another way +that produces the same effect, such as by directly checking for the presence and +size of a `prefixItems` array. Implementations that do not support annotation +collection MUST do so. + +#### Keywords for Applying Subschemas to Objects + +##### properties +The value of `properties` MUST be an object. Each value of this object MUST be a +valid JSON Schema. + +Validation succeeds if, for each name that appears in both the instance and as a +name within this keyword's value, the child instance for that name successfully +validates against the corresponding schema. + +The annotation result of this keyword is the set of instance property names +which are also present under this keyword. This annotation affects the behavior +of `additionalProperties` (in this vocabulary) and `unevaluatedProperties` in +the Unevaluated vocabulary. + +Omitting this keyword has the same assertion behavior as an empty object. + +##### patternProperties +The value of `patternProperties` MUST be an object. Each property name of this +object SHOULD be a valid regular expression, according to the ECMA-262 regular +expression dialect. Each property value of this object MUST be a valid JSON +Schema. + +Validation succeeds if, for each instance name that matches any regular +expressions that appear as a property name in this keyword's value, the child +instance for that name successfully validates against each schema that +corresponds to a matching regular expression. Recall: regular expressions are +not implicitly anchored. + +The annotation result of this keyword is the set of instance property names +matched by at least one property under this keyword. This annotation affects the +behavior of `additionalProperties` (in this vocabulary) and +`unevaluatedProperties` (in the Unevaluated vocabulary). + +Omitting this keyword has the same assertion behavior as an empty object. + +##### additionalProperties +The value of `additionalProperties` MUST be a valid JSON Schema. + +The behavior of this keyword depends on the presence and annotation results of +`properties` and `patternProperties` within the same schema object. Validation +with `additionalProperties` applies only to the child values of instance names +that do not appear in the annotation results of either `properties` or +`patternProperties`. + +For all such properties, validation succeeds if the child instance validates +against the `additionalProperties` schema. + +The annotation result of this keyword is the set of instance property names +validated by this keyword's subschema. This annotation affects the behavior of +`unevaluatedProperties` in the Unevaluated vocabulary. + +Omitting this keyword has the same assertion behavior as an empty schema. + +Implementations MAY choose to implement or optimize this keyword in another way +that produces the same effect, such as by directly checking the names in +`properties` and the patterns in `patternProperties` against the instance +property set. Implementations that do not support annotation collection MUST do +so.[^12] + +[^12]: In defining this option, it seems there is the potential for ambiguity in +the output format. The ambiguity does not affect validation results, but it does +affect the resulting output format. The ambiguity allows for multiple valid +output results depending on whether annotations are used or a solution that +"produces the same effect" as draft-07. It is understood that annotations from +failing schemas are dropped. See our [Decision +Record](https://github.com/json-schema-org/json-schema-spec/tree/HEAD/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md) +for further details. + +##### propertyNames +The value of `propertyNames` MUST be a valid JSON Schema. + +If the instance is an object, this keyword validates if every property name in +the instance validates against the provided schema. Note the property name that +the schema is testing will always be a string. + +Omitting this keyword has the same behavior as an empty schema. + +#### Other Keywords for Applying Subschemas + +##### maxContains +The value of this keyword MUST be a non-negative integer. + +This keyword modifies the behavior of `contains` within the same schema object, +as described below in the section for that keyword. + +Validation MUST always succeed against this keyword. The value of this keyword +is used as its annotation result. + +##### minContains +The value of this keyword MUST be a non-negative integer. + +This keyword modifies the behavior of `contains` within the same schema object, +as described below in the section for that keyword. + +Validation MUST always succeed against this keyword. The value of this keyword +is used as its annotation result. + +Per [Section 7.3](#73-default-behaviors), omitted keywords MUST NOT produce +annotation results. However, as described in the section for `contains`, the +absence of this keyword's annotation causes `contains` to assume a minimum value +of 1. + +##### contains +The value of this keyword MUST be a valid JSON Schema. + +This keyword applies its subschema to array elements or object property values. + +An instance is valid against `contains` if the number of elements or property +values that are valid against its subschema is with the inclusive range of the +minimum and (if any) maximum number of occurrences. + +The maximum number of occurrences is provided by the `maxContains` keyword +within the same schema object as `contains`. If `maxContains` is absent, the +maximum number of occurrences MUST be unbounded. + +The minimum number of occurrences is provided by the `minContains` keyword +within the same schema object as `contains`. If `minContains` is absent, the +minimum number of occurrences MUST be 1. + +Implementations MAY implement the dependency on `minContians` and `maxContains` +by inspecting their values rather than reading annotations produced by those +keywords. + +This keyword produces an annotation value which is an array of the indexes or +property names to which this keyword validates successfully when applying its +subschema, in ascending order. The value MAY be a boolean `true` if the +subschema validates successfully when applied to every index or property value +of the instance. The annotation MUST be present if the instance array or object +to which this keyword's schema applies is empty. + +This annotation affects the behavior of `unevaluatedItems` in the Unevaluated +vocabulary. + +The subschema MUST be applied to every array element or object property value +even after the first match has been found, in order to collect annotations for +use by other keywords. This is to ensure that all possible annotations are +collected. + +## A Vocabulary for Unevaluated Locations +The purpose of these keywords is to enable schema authors to apply subschemas to +array items or object properties that have not been successfully evaluated +against any dynamic-scope subschema of any adjacent keywords. + +These instance items or properties may have been unsuccessfully evaluated +against one or more adjacent keyword subschemas, such as when an assertion in a +branch of an `anyOf` fails. Such failed evaluations are not considered to +contribute to whether or not the item or property has been evaluated. Only +successful evaluations are considered. + +If an item in an array or an object property is "successfully evaluated", it is +logically considered to be valid in terms of the representation of the object or +array that's expected. For example if a subschema represents a car, which +requires between 2-4 wheels, and the value of "wheels" is 6, the instance object +is not "evaluated" to be a car, and the "wheels" property is considered +"unevaluated (successfully as a known thing)", and does not retain any +annotations. + +Recall that adjacent keywords are keywords within the same schema object, and +that the dynamic-scope subschemas include reference targets as well as lexical +subschemas. + +The behavior of these keywords depend on the annotation results of adjacent +keywords that apply to the instance location being validated. + +Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this +vocabulary as if its IRI were present with a value of true. + +The current IRI for this vocabulary, known as the Unevaluated Applicator +vocabulary, is: `https://json-schema.org/draft/next/vocab/unevaluated`. + +The current IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/unevaluated`. + +### Keyword Independence +Schema keywords typically operate independently, without affecting each other's +outcomes. However, the keywords in this vocabulary are notable exceptions: + +- `unevaluatedItems`, whose behavior is defined in terms of annotations from +`prefixItems`, `items`, `contains`, and itself +- `unevaluatedProperties`, whose behavior is defined in terms of annotations +from `properties`, `patternProperties`, `additionalProperties`, `contains`, and +itself + +### unevaluatedItems +The value of `unevaluatedItems` MUST be a valid JSON Schema. + +The behavior of this keyword depends on the annotation results of adjacent +keywords that apply to the instance location being validated. Specifically, the +annotations from `prefixItems`, `items`, and `contains`, which can come from +those keywords when they are adjacent to the `unevaluatedItems` keyword. Those +three annotations, as well as `unevaluatedItems`, can also result from any and +all adjacent [in-place +applicator](#102-keywords-for-applying-subschemas-in-place) keywords. This +includes but is not limited to the in-place applicators defined in this +document. + +If no relevant annotations are present, the `unevaluatedItems` subschema MUST be +applied to all locations in the array. If a boolean true value is present from +any of the relevant annotations, `unevaluatedItems` MUST be ignored. Otherwise, +the subschema MUST be applied to any index greater than the largest annotation +value for `prefixItems`, which does not appear in any annotation value for +`contains`. + +This means that `prefixItems`, `items`, `contains`, and all in-place applicators +MUST be evaluated before this keyword can be evaluated. Authors of extension +keywords MUST NOT define an in-place applicator that would need to be evaluated +after this keyword. + +If the `unevaluatedItems` subschema is applied to any positions within the +instance array, it produces an annotation result of boolean true, analogous to +the behavior of `items`. This annotation affects the behavior of +`unevaluatedItems` in parent schemas. + +Omitting this keyword has the same assertion behavior as an empty schema. + +### unevaluatedProperties +The value of `unevaluatedProperties` MUST be a valid JSON Schema. + +The behavior of this keyword depends on the annotation results of adjacent +keywords that apply to the instance location being validated. Specifically, the +annotations from `properties`, `patternProperties`, `contains`, and +`additionalProperties`, which can come from those keywords when they are +adjacent to the `unevaluatedProperties` keyword. Those four annotations, as well +as `unevaluatedProperties`, can also result from any and all adjacent [in-place +applicator](#102-keywords-for-applying-subschemas-in-place) keywords. This +includes but is not limited to the in-place applicators defined in this +document. + +Validation with `unevaluatedProperties` applies only to the child values of +instance names that do not appear in the `properties`, `patternProperties`, +`additionalProperties`, `contains`, or `unevaluatedProperties` annotation +results that apply to the instance location being validated. + +For all such properties, validation succeeds if the child instance validates +against the `unevaluatedProperties` schema. + +This means that `properties`, `patternProperties`, `additionalProperties`, +`contains` and all in-place applicators MUST be evaluated before this keyword +can be evaluated. Authors of extension keywords MUST NOT define an in-place +applicator that would need to be evaluated after this keyword. + +The annotation result of this keyword is the set of instance property names +validated by this keyword's subschema. This annotation affects the behavior of +`unevaluatedProperties` in parent schemas. + +Omitting this keyword has the same assertion behavior as an empty schema. + +## Output Formatting +JSON Schema is defined to be platform-independent. As such, to increase +compatibility across platforms, implementations SHOULD conform to a standard +validation output format. This section describes the minimum requirements that +consumers will need to properly interpret validation results. + +### Format +JSON Schema output is defined using the JSON Schema data instance model as +described in section 4.2.1. Implementations MAY deviate from this as supported +by their specific languages and platforms, however it is RECOMMENDED that the +output be convertible to the JSON format defined herein via serialization or +other means. + +### Output Formats +This specification defines three output formats. See the "Output Structure" +section for the requirements of each format. + +Flag: A boolean which simply indicates the overall validation result with no +further details. + +List: Provides validation information in a flat list structure. + +Hierarchical: Provides validation information in a hierarchical structure that +follows the evaluation paths generated while processing the schema. + +An implementation MUST provide the "flag" format and SHOULD provide at least one +of the "list" or "hierarchical" formats. Implementations SHOULD specify in their +documentation which formats they support. + +### Minimum Information +Beyond the simplistic "flag" output, additional information is useful to aid in +debugging a schema or instance. Each sub-result SHOULD contain the information +contained within this section at a minimum. + +A single object that contains all of these components is considered an output +unit. + +Implementations MAY elect to provide additional information. + +#### Evaluation path +The evaluation path to the schema object that produced the output unit. The +value MUST be expressed as a JSON Pointer, and it MUST include any by-reference +applicators such as `$ref` or `$dynamicRef`.[^13] + +[^13]: The schema may not actually have a value at the location indicated by +this pointer. It is provided as an indication of the traversal path only. + +``` +/properties/width/$ref/allOf/1 +``` + +Note that this pointer may not be resolvable by the normal JSON Pointer process +due to the inclusion of these by-reference applicator keywords. + +The JSON key for this information is "evaluationPath". + +#### Schema Location +The absolute, dereferenced location of the schema object that produced the +output unit. The value MUST be expressed using the canonical IRI of the +relevant schema resource plus a JSON Pointer fragment that indicates the schema +object that produced the output. It MUST NOT include by-reference applicators +such as `$ref` or `$dynamicRef`.[^14] + +[^14]: Note that "absolute" here is in the sense of "absolute filesystem path" +(meaning the complete location) rather than the "absolute-IRI" terminology from +RFC 3987 (meaning with scheme and without fragment). Schema locations will have +a fragment in order to identify the specific schema object. + +``` +https://example.com/schemas/common#/$defs/allOf/1 +``` + +The JSON key for this information is "schemaLocation". + +#### Instance Location +The location of the JSON value within the instance being validated. The value +MUST be expressed as a JSON Pointer. + +The JSON key for this information is "instanceLocation". + +#### Errors +Any errors produced by the validation. This property MUST NOT be included if the +validation was successful. The value for this property MUST be an object where +the keys are the names of keywords and the values are the error message produced +by the associated keyword. + +If the subschema itself is producing the error, that error MUST be listed with +an empty string key.[^15] + +[^15]: Although there may be other cases where a subschema can produce an error, +the most common case is the `false` schema. In cases like these, there is no +keyword that produces the error, so there is nothing to use as a key. Thus the +empty string is used instead. + +The specific wording for the message is not defined by this specification. +Implementations will need to provide this. + +The JSON key for this information is "errors". + +#### Annotations +Any annotations produced by the evaluation. This property MUST NOT be included +if the validation result of the containing subschema was unsuccessful. + +The value for this property MUST be an object where the keys are the names of +keywords and the values are the annotations produced by the associated keyword. + +Each keyword defines its own annotation data type (e.g. `properties` produces a +list of keywords, whereas `title` produces a string). + +The JSON key for this information is "annotations". + +#### Dropped Annotations +Any annotations produced and subsequently dropped by the evaluation due to an +unsuccessful validation result of the containing subschema. This property MAY be +included if the validation result of the containing subschema was unsuccessful. +It MUST NOT be included if the local validation result of the containing +subschema was successful. + +Implementations that wish to provide these annotations MUST NOT provide them as +their default behavior. These annotations MUST only be included by explicitly +configuring the implementation to do so. + +The value for this property MUST be an object where the keys are the names of +keywords and the values are the annotations produced by the associated keyword. + +Each keyword defines its own annotation data type (e.g. `properties` produces a +list of keywords, whereas `title` produces a string). + +The JSON key for this information is "droppedAnnotations". + +#### Results from Subschemas +Evaluation results generated by applying a subschema to the instance or a child +of the instance. Keywords which have multiple subschemas (e.g. `anyOf`) will +generally generate an output unit for each subschema. In order to accommodate +potentially multiple results, the value of this property MUST be an array of +output units, even if only a single output unit is produced. + +For "list", this property will appear only at the root output unit and will hold +all output units in a flat list. + +For "hierarchical", this property will contain results in a tree structure where +each output unit may itself have further nested results. + +The sequence of output units within this list is not specified and MAY be +determined by the implementation. Sets of output units are considered equivalent +if they contain the same units, in any order. + +The JSON key for these additional results is "details". + +### 12.4. Output Structure + +The output MUST be an object containing a boolean property named "valid". When +additional information about the result is required, the output MUST also +contain "details" as described below. + +valid: a boolean value indicating the overall validation success or failure + +details: the collection of results produced by subschemas + +For these examples, the following schema and instances will be used. + +Schema +```json +{ + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/schemas/example", + "type": "object", + "title": "root", + "properties": { + "foo": { + "allOf": [ + { "required": [ "unspecified-prop" ] }, + { + "type": "object", + "title": "foo-title", + "properties": { + "foo-prop": { + "const": 1, + "title": "foo-prop-title" + } + }, + "additionalProperties": { "type": "boolean" } + } + ] + }, + "bar": { + "$ref": "#/$defs/bar" + } + }, + "$defs": { + "bar": { + "type": "object", + "title": "bar-title", + "properties": { + "bar-prop": { + "type": "integer", + "minimum": 10, + "title": "bar-prop-title" + } + } + } + } +} +``` + +Failing instance +```json +{ + "foo": {"foo-prop": "not 1", "other-prop": false}, + "bar": {"bar-prop": 2} +} +``` + +Passing instance +```json +{ + "foo": { + "foo-prop": 1, + "unspecified-prop": true + }, + "bar": {"bar-prop": 20} +} +``` + +The failing instance will produce the following errors: + +- The value at `/foo` evaluated at `/properties/foo/allOf/0` by following the +path `/properties/foo/allOf/0` by the `required` keyword is missing the property +`unspecified-prop`. +- The value at `/foo/foo-prop` evaluated at +`/properties/foo/allOf/1/properties/foo-prop` by following the path +`/properties/foo/allOf/1/properties/foo-prop` by the `const` keyword is not the +constant value 1. +- The value at `/bar/bar-prop` evaluated at `/$defs/bar/properties/bar-prop` by +following the path `/properties/bar/$ref/properties/bar-prop` by the `type` +keyword is not a number.[^16][^17] + +[^16]: `minimum` doesn't produce an error because it only operates on instances +that are numbers. + +[^17]: Note that the error message wording as depicted in the examples below is +not a requirement of this specification. Implementations SHOULD craft error +messages tailored for their audience or provide a templating mechanism that +allows their users to craft their own messages. + +The passing instance will produce the following annotations: + +- The keyword `title` evaluated at `` by following the path `` will produce +`"root"`. +- The keyword `properties` evaluated at `` by following the path `` will produce +`["foo", "bar"]`. +- The keyword `title` evaluated at `/properties/foo` by following the path +`/properties/foo` will produce `"foo-title"`. +- The keyword `properties` evaluated at `/properties/foo/allOf/1` by following +the path `/properties/foo/allOf/1` will produce `["foo-prop"]`. +- The keyword `additionalProperties` evaluated at `/properties/foo/allOf/1` by +following the path `/properties/foo/allOf/1` will produce +`["unspecified-prop"]`. +- The keyword `title` evaluated at `/properties/foo/allOf/1/properties/foo-prop` +by following the path `/properties/foo/allOf/1/properties/foo-prop` will produce +`"foo-prop-title"`. +- The keyword `title` evaluated at `/$defs/bar` by following the path +`/properties/bar/$ref` will produce `"bar-title"`. +- The keyword `properties` evaluated at `/$defs/bar` by following the path +`/properties/var/$ref` will produce `["bar-prop"]`. +- The keyword `title` evaluated at `/$defs/bar/properties/bar-prop` by following +the path `/properties/bar/$ref/properties/bar-prop` will produce +`"bar-prop-title"`. + +#### Flag +In the simplest case, merely the boolean result for the "valid" valid property +needs to be fulfilled. For this format, all other information is explicitly +omitted. + +```json +{ + "valid": false +} +``` + +Because no errors or annotations are returned with this format, it is +RECOMMENDED that implementations use short-circuiting logic to return failure or +success as soon as the outcome can be determined. For example, if an `anyOf` +keyword contains five subschemas, and the second one passes, there is no need to +check the other three. The logic can simply return with success. + +#### List +The "List" structure is a flat list of output units contained within a root +output unit. + +The root output unit contains "valid" for the overall result and "details" for +the list of specific results. All other information is explicitly omitted from +the root output unit. If the root schema produces errors or annotations, then +the output node for the root MUST be present within the root output unit's +"details" list with those errors or annotations. + +Output units which do not contain errors or annotations SHOULD be excluded from +this format, however implementations MAY choose to include them for +completeness. + +Failing results +```json +{ + "valid": false, + "details": [ + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/0", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/0", + "instanceLocation": "/foo", + "errors": { + "required": "Required properties [\"unspecified-prop\"] were not present" + } + }, + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "errors": { + "const": "Expected \"1\"" + } + }, + { + "valid": false, + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "errors": { + "minimum": "2 is less than or equal to 10" + } + } + ] +} +``` + +Passing results +```json +{ + "valid": true, + "details": [ + { + "valid": true, + "evaluationPath": "", + "schemaLocation": "https://json-schema.org/schemas/example#", + "instanceLocation": "", + "annotations": { + "title": "root", + "properties": [ + "foo", + "bar" + ] + } + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1", + "instanceLocation": "/foo", + "annotations": { + "title": "foo-title", + "properties": [ + "foo-prop" + ], + "additionalProperties": [ + "unspecified-prop" + ] + } + }, + { + "valid": true, + "evaluationPath": "/properties/bar/$ref", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar", + "instanceLocation": "/bar", + "annotations": { + "title": "bar-title", + "properties": [ + "bar-prop" + ] + } + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "annotations": { + "title": "foo-prop-title" + } + }, + { + "valid": true, + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "annotations": { + "title": "bar-prop-title" + } + } + ] +} +``` + +#### Hierarchical +The "Hierarchical" structure is a tree structure that follows the evaluation +path during the validation process. Typically, it will resemble the schema as if +all referenced schemas were inlined in place of their associated by-reference +keywords. + +All output units are included in this format. + +The location properties of the root output unit MAY be omitted. + +Failing results (errors) +```json +{ + "valid": false, + "evaluationPath": "", + "schemaLocation": "https://json-schema.org/schemas/example#", + "instanceLocation": "", + "details": [ + { + "valid": false, + "evaluationPath": "/properties/foo", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo", + "instanceLocation": "/foo", + "details": [ + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/0", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/0", + "instanceLocation": "/foo", + "errors": { + "required": "Required properties [\"unspecified-prop\"] were not present" + } + }, + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/1", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1", + "instanceLocation": "/foo", + "droppedAnnotations": { + "properties": [ "foo-prop" ], + "title": "foo-title" + }, + "details": [ + { + "valid": false, + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "errors": { + "const": "Expected \"1\"" + }, + "droppedAnnotations": { + "title": "foo-prop-title" + } + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1/additionalProperties", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/additionalProperties", + "instanceLocation": "/foo/other-prop" + } + ] + } + ] + }, + { + "valid": false, + "evaluationPath": "/properties/bar", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/bar", + "instanceLocation": "/bar", + "details": [ + { + "valid": false, + "evaluationPath": "/properties/bar/$ref", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar", + "instanceLocation": "/bar", + "droppedAnnotations": { + "properties": [ "bar-prop" ], + "title": "bar-title" + }, + "details": [ + { + "valid": false, + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "errors": { + "minimum": "2 is less than or equal to 10" + }, + "droppedAnnotations": { + "title": "bar-prop-title" + } + } + ] + } + ] + } + ] +} +``` + +Passing results (annotations) +```json +{ + "valid": true, + "evaluationPath": "", + "schemaLocation": "https://json-schema.org/schemas/example#", + "instanceLocation": "", + "annotations": { + "title": "root", + "properties": [ + "foo", + "bar" + ] + }, + "details": [ + { + "valid": true, + "evaluationPath": "/properties/foo", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo", + "instanceLocation": "/foo", + "details": [ + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/0", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/0", + "instanceLocation": "/foo" + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1", + "instanceLocation": "/foo", + "annotations": { + "title": "foo-title", + "properties": [ + "foo-prop" + ], + "additionalProperties": [ + "unspecified-prop" + ] + }, + "details": [ + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1/properties/foo-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/properties/foo-prop", + "instanceLocation": "/foo/foo-prop", + "annotations": { + "title": "foo-prop-title" + } + }, + { + "valid": true, + "evaluationPath": "/properties/foo/allOf/1/additionalProperties", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/foo/allOf/1/additionalProperties", + "instanceLocation": "/foo/unspecified-prop" + } + ] + } + ] + }, + { + "valid": true, + "evaluationPath": "/properties/bar", + "schemaLocation": "https://json-schema.org/schemas/example#/properties/bar", + "instanceLocation": "/bar", + "details": [ + { + "valid": true, + "evaluationPath": "/properties/bar/$ref", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar", + "instanceLocation": "/bar", + "annotations": { + "title": "bar-title", + "properties": [ + "bar-prop" + ] + }, + "details": [ + { + "valid": true, + "evaluationPath": "/properties/bar/$ref/properties/bar-prop", + "schemaLocation": "https://json-schema.org/schemas/example#/$defs/bar/properties/bar-prop", + "instanceLocation": "/bar/bar-prop", + "annotations": { + "title": "bar-prop-title" + } + } + ] + } + ] + } + ] +} +``` + +#### Output validation schemas +For convenience, JSON Schema has been provided to validate output generated by +implementations. Its IRI is: . + +## Security Considerations +Both schemas and instances are JSON values. As such, all security considerations +defined in [RFC 8259](#rfc8259) apply. + +Instances and schemas are both frequently written by untrusted third parties, to +be deployed on public Internet servers. Implementations should take care that +the parsing and evaluating against schemas does not consume excessive system +resources. Implementations MUST NOT fall into an infinite loop. + +A malicious party could cause an implementation to repeatedly collect a copy of +a very large value as an annotation. Implementations SHOULD guard against +excessive consumption of system resources in such a scenario. + +Servers MUST ensure that malicious parties cannot change the functionality of +existing schemas by uploading a schema with a pre-existing or very similar +`$id`. + +Individual JSON Schema vocabularies are liable to also have their own security +considerations. Consult the respective specifications for more information. + +Schema authors should take care with `$comment` contents, as a malicious +implementation can display them to end-users in violation of a spec, or fail to +strip them if such behavior is expected. + +A malicious schema author could place executable code or other dangerous +material within a `$comment`. Implementations MUST NOT parse or otherwise take +action based on `$comment` contents. + +## IANA Considerations + +### application/schema+json +The proposed MIME media type for JSON Schema is defined as follows: + +Type name:: application + +Subtype name:: schema+json + +Required parameters:: N/A + +Encoding considerations:: Encoding considerations are identical to those +specified for the `application/json` media type. See [JSON](#rfc8259). + +Security considerations:: See [Section 13](#13-security-considerations) above. + +Interoperability considerations:: See Sections +[6.2](#62-programming-language-independence), [6.3](#63-mathematical-integers), +and [6.4](#64-regular-expressions) above. + +Fragment identifier considerations:: See [Section 5](#5-fragment-identifiers) + +### application/schema-instance+json +The proposed MIME media type for JSON Schema Instances that require a JSON +Schema-specific media type is defined as follows: + +Type name:: application + +Subtype name:: schema-instance+json + +Required parameters:: N/A + +Encoding considerations:: Encoding considerations are identical to those +specified for the `application/json` media type. See [JSON](#rfc8259). + +Security considerations:: See [Section 13](#13-security-considerations) above. + +Interoperability considerations:: See Sections +[6.2](#62-programming-language-independence), [6.3](#63-mathematical-integers), +and [6.4](#64-regular-expressions) above. + +Fragment identifier considerations:: See [Section 5](#5-fragment-identifiers) + +## References + +### Normative References + +#### [RFC2119] +Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, +RFC 2119, DOI 10.17487/RFC2119, March 1997, +<>. + +#### [RFC3986] +Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier +(URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, +<>. + +#### [RFC3987] +Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC +3987, DOI 10.17487/RFC3987, January 2005, +<>. + +#### [RFC6839] +Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", +RFC 6839, DOI 10.17487/RFC6839, January 2013, +<>. + +#### [RFC6901] +Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation +(JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, +<>. + +#### [RFC8259] +Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", +STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, +<>. + +#### [W3C.REC-ldp-20150226] +Malhotra, A., Ed., Arwe, J., Ed., and S. Speicher, Ed., "Linked Data Platform +1.0", W3C REC REC-ldp-20150226, W3C REC-ldp-20150226, 26 February 2015, +<>. + +#### [ecma262] +"ECMA-262, 11th edition specification", June 2020, +<>. + +### Informative References + +#### [RFC6596] +Ohye, M. and J. Kupke, "The Canonical Link Relation", RFC 6596, DOI +10.17487/RFC6596, April 2012, <>. + +#### [RFC7049] +Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC +7049, DOI 10.17487/RFC7049, October 2013, +<>. + +#### [RFC7231] +Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): +Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, +<>. + +#### [RFC8288] +Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, +<>. + +#### [W3C.WD-fragid-best-practices-20121025] +Tennison, J., Ed., "Best Practices for Fragment Identifiers and Media Type +Definitions", W3C WD WD-fragid-best-practices-20121025, W3C +WD-fragid-best-practices-20121025, 25 October 2012, +<>. + +#### [W3C.REC-xptr-framework-20030325] +Maler, E., Ed., Marsh, J., Ed., Walsh, N., Ed., and P. Grosso, Ed., "XPointer +Framework", W3C REC REC-xptr-framework-20030325, W3C +REC-xptr-framework-20030325, 25 March 2003, +<>. + +#### [json-schema-validation] +Wright, A., Andrews, H., and B. Hutton, "JSON Schema Validation: A Vocabulary +for Structural Validation of JSON", Work in Progress, Internet-Draft, +draft-bhutton-json-schema-validation-01, June 2022, +<>. + +#### [json-hyper-schema] +Andrews, H. and A. Wright, "JSON Hyper-Schema: A Vocabulary for Hypermedia +Annotation of JSON", Work in Progress, Internet-Draft, +draft-handrews-json-schema-hyperschema-02, November 2017, +<>. + +#### [xml-names] +Bray, T., Ed., Hollander, D., Ed., Layman, A., Ed., and R. Tobin, Ed., +"Namespaces in XML 1.1 (Second Edition)", August 2006, +<>. + +## Appendix A. Schema identification examples +Consider the following schema, which shows `$id` being used to identify both the +root schema and various subschemas, and `$anchor` being used to define plain +name fragment identifiers. + +```json +{ + "$id": "https://example.com/root.json", + "$defs": { + "A": { "$anchor": "foo" }, + "B": { + "$id": "other.json", + "$defs": { + "X": { "$anchor": "bar" }, + "Y": { + "$id": "t/inner.json", + "$anchor": "bar" + } + } + }, + "C": { + "$id": "urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f" + } + } +} +``` + +The schemas at the following IRI-encoded [JSON Pointers](#rfc6901) (relative to +the root schema) have the following base IRIs, and are identifiable by any +listed IRI in accordance with [Section 5](#5-fragment-identifiers) and [Section +9.2.1](#921-json-pointer-fragments-and-embedded-schema-resources) above. + +`#` (document root): canonical (and base) IRI: `https://example.com/root.json` +canonical resource IRI plus pointer fragment: `https://example.com/root.json#` + +`#/$defs/A`: base IRI: `https://example.com/root.json` canonical resource IRI +plus plain fragment: `https://example.com/root.json#foo` canonical resource IRI +plus pointer fragment: `https://example.com/root.json#/$defs/A` + +`#/$defs/B`: canonical (and base) `IRI: https://example.com/other.json` +canonical resource IRI plus pointer fragment: `https://example.com/other.json#` +base IRI of enclosing (root.json) resource plus fragment: +`https://example.com/root.json#/$defs/B` + +`#/$defs/B/$defs/X`: base IRI: `https://example.com/other.json` canonical +resource IRI plus plain fragment: `https://example.com/other.json#bar` canonical +resource IRI plus pointer fragment: `https://example.com/other.json#/$defs/X` +base IRI of enclosing (root.json) resource plus fragment: +`https://example.com/root.json#/$defs/B/$defs/X` + +`#/$defs/B/$defs/Y`: canonical (and base) IRI: +`https://example.com/t/inner.json` canonical IRI plus plain fragment: +`https://example.com/t/inner.json#bar` canonical IRI plus pointer fragment: +`https://example.com/t/inner.json#` base IRI of enclosing (other.json) resource +plus fragment: `https://example.com/other.json#/$defs/Y` base IRI of enclosing +(root.json) resource plus fragment: +`https://example.com/root.json#/$defs/B/$defs/Y` + +`#/$defs/C`: canonical (and base) IRI: +`urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f` canonical IRI plus pointer +fragment: `urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f#` base IRI of enclosing +(root.json) resource plus fragment: `https://example.com/root.json#/$defs/C` + +Note: The fragment part of the IRI does not make it canonical or non-canonical, +rather, the base IRI used (as part of the full IRI with any fragment) is what +determines the canonical nature of the resulting full IRI.[^18] + +[^18]: Multiple "canonical" IRIs? We Acknowledge this is potentially confusing, +and direct you to read the CREF located in the [JSON Pointer fragments and +embedded schema +resources](#921-json-pointer-fragments-and-embedded-schema-resources) section +for futher comments. + +## Appendix B. Manipulating schema documents and references +Various tools have been created to rearrange schema documents based on how and +where references (`$ref`) appear. This appendix discusses which use cases and +actions are compliant with this specification. + +### B.1. Bundling schema resources into a single document +A set of schema resources intended for use together can be organized with each +in its own schema document, all in the same schema document, or any granularity +of document grouping in between. + +Numerous tools exist to perform various sorts of reference removal. A common +case of this is producing a single file where all references can be resolved +within that file. This is typically done to simplify distribution, or to +simplify coding so that various invocations of JSON Schema libraries do not have +to keep track of and load a large number of resources. + +This transformation can be safely and reversibly done as long as all static +references (e.g. `$ref`) use IRI-references that resolve to IRIs using the +canonical resource IRI as the base, and all schema resources have an +absolute-IRI as the `$id` in their root schema. + +With these conditions met, each external resource can be copied under `$defs`, +without breaking any references among the resources' schema objects, and without +changing any aspect of validation or annotation results. The names of the +schemas under `$defs` do not affect behavior, assuming they are each unique, as +they do not appear in the canonical IRIs for the embedded resources. + +### B.2. Reference removal is not always safe +Attempting to remove all references and produce a single schema document does +not, in all cases, produce a schema with identical behavior to the original +form. + +Since `$ref` is now treated like any other keyword, with other keywords allowed +in the same schema objects, fully supporting non-recursive `$ref` removal in all +cases can require relatively complex schema manipulations. It is beyond the +scope of this specification to determine or provide a set of safe `$ref` removal +transformations, as they depend not only on the schema structure but also on the +intended usage. + +## Appendix C. Example of recursive schema extension +Consider the following two schemas describing a simple recursive tree structure, +where each node in the tree can have a "data" field of any type. The first +schema allows and ignores other instance properties. The second is more strict +and only allows the "data" and "children" properties. An example instance with +"data" misspelled as "daat" is also shown. + +Tree schema, extensible +```json +{ + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://example.com/tree", + "$dynamicAnchor": "node", + + "type": "object", + "properties": { + "data": true, + "children": { + "type": "array", + "items": { + "$dynamicRef": "#node" + } + } + } +} +``` + +Strict-tree schema, guards against misspelled properties +```json +{ + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://example.com/strict-tree", + "$dynamicAnchor": "node", + + "$ref": "tree", + "unevaluatedProperties": false +} +``` + +Instance with misspelled field +```json +{ + "children": [ { "daat": 1 } ] +} +``` + +When we load these two schemas, we will notice the `$dynamicAnchor` named "node" +(note the lack of "#" as this is just the name) present in each, resulting in +the following full schema IRIs: + +- `https://example.com/tree#node` +- `https://example.com/strict-tree#node` + +In addition, JSON Schema implementations keep track of the fact that these +fragments were created with `$dynamicAnchor`. + +If we apply the "strict-tree" schema to the instance, we will follow the `$ref` +to the "tree" schema, examine its "children" subschema, and find the +`$dynamicRef`: to "#node" (note the `#` for IRI fragment syntax) in its `items` +subschema. That reference resolves to `https://example.com/tree#node`, which is +a IRI with a fragment created by `$dynamicAnchor`. Therefore we must examine the +dynamic scope before following the reference. + +At this point, the evaluation path is +`#/$ref/properties/children/items/$dynamicRef`, with a dynamic scope containing +(from the outermost scope to the innermost): + +1. `https://example.com/strict-tree#` +1. `https://example.com/tree#` +1. `https://example.com/tree#/properties/children` +1. `https://example.com/tree#/properties/children/items` + +Since we are looking for a plain name fragment, which can be defined anywhere +within a schema resource, the JSON Pointer fragments are irrelevant to this +check. That means that we can remove those fragments and eliminate consecutive +duplicates, producing: + +1. `https://example.com/strict-tree` +1. `https://example.com/tree` + +In this case, the outermost resource also has a "node" fragment defined by +`$dynamicAnchor`. Therefore instead of resolving the `$dynamicRef` to +`https://example.com/tree#node`, we resolve it to +`https://example.com/strict-tree#node`. + +This way, the recursion in the "tree" schema recurses to the root of +"strict-tree", instead of only applying "strict-tree" to the instance root, but +applying "tree" to instance children. + +This example shows both `$dynamicAnchor`s in the same place in each schema, +specifically the resource root schema. Since plain-name fragments are +independent of the JSON structure, this would work just as well if one or both +of the node schema objects were moved under `$defs`. It is the matching +`$dynamicAnchor` values which tell us how to resolve the dynamic reference, not +any sort of correlation in JSON structure. + +## Appendix D. Working with vocabularies + +### D.1. Best practices for vocabulary and meta-schema authors +Vocabulary authors should take care to avoid keyword name collisions if the +vocabulary is intended for broad use, and potentially combined with other +vocabularies. JSON Schema does not provide any formal namespacing system, but +also does not constrain keyword names, allowing for any number of namespacing +approaches. + +Vocabularies may build on each other, such as by defining the behavior of their +keywords with respect to the behavior of keywords from another vocabulary, or by +using a keyword from another vocabulary with a restricted or expanded set of +acceptable values. Not all such vocabulary re-use will result in a new +vocabulary that is compatible with the vocabulary on which it is built. +Vocabulary authors should clearly document what level of compatibility, if any, +is expected. + +Meta-schema authors should not use `$vocabulary` to combine multiple +vocabularies that define conflicting syntax or semantics for the same keyword. +As semantic conflicts are not generally detectable through schema validation, +implementations are not expected to detect such conflicts. If conflicting +vocabularies are declared, the resulting behavior is undefined. + +Vocabulary authors SHOULD provide a meta-schema that validates the expected +usage of the vocabulary's keywords on their own. Such meta-schemas SHOULD not +forbid additional keywords, and MUST not forbid any keywords from the Core +vocabulary. + +It is recommended that meta-schema authors reference each vocabulary's +meta-schema using the [`allOf`](#10211-allof) keyword, although other mechanisms +for constructing the meta-schema may be appropriate for certain use cases. + +The recursive nature of meta-schemas makes the `$dynamicAnchor` and +`$dynamicRef` keywords particularly useful for extending existing meta-schemas, +as can be seen in the JSON Hyper-Schema meta-schema which extends the Validation +meta-schema. + +Meta-schemas may impose additional constraints, including describing keywords +not present in any vocabulary, beyond what the meta-schemas associated with the +declared vocabularies describe. This allows for restricting usage to a subset of +a vocabulary, and for validating locally defined keywords not intended for +re-use. + +However, meta-schemas should not contradict any vocabularies that they declare, +such as by requiring a different JSON type than the vocabulary expects. The +resulting behavior is undefined. + +Meta-schemas intended for local use, with no need to test for vocabulary support +in arbitrary implementations, can safely omit `$vocabulary` entirely. + +### D.2. Example meta-schema with vocabulary declarations +This meta-schema explicitly declares both the Core and Applicator vocabularies, +together with an extension vocabulary, and combines their meta-schemas with an +`allOf`. The extension vocabulary's meta-schema, which describes only the +keywords in that vocabulary, is shown after the main example meta-schema. + +The main example meta-schema also restricts the usage of the Unevaluated +vocabulary by forbidding the keywords prefixed with "unevaluated", which are +particularly complex to implement. This does not change the semantics or set of +keywords defined by the other vocabularies. It just ensures that schemas using +this meta-schema that attempt to use the keywords prefixed with "unevaluated" +will fail validation against this meta-schema. + +Finally, this meta-schema describes the syntax of a keyword, "localKeyword", +that is not part of any vocabulary. Presumably, the implementors and users of +this meta-schema will understand the semantics of "localKeyword". JSON Schema +does not define any mechanism for expressing keyword semantics outside of +vocabularies, making them unsuitable for use except in a specific environment in +which they are understood. + +This meta-schema combines several vocabularies for general use. + +```json +{ + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://example.com/meta/general-use-example", + "$dynamicAnchor": "meta", + "$vocabulary": { + "https://json-schema.org/draft/next/vocab/core": true, + "https://json-schema.org/draft/next/vocab/applicator": true, + "https://json-schema.org/draft/next/vocab/validation": true, + "https://example.com/vocab/example-vocab": true + }, + "allOf": [ + {"$ref": "https://json-schema.org/draft/next/meta/core"}, + {"$ref": "https://json-schema.org/draft/next/meta/applicator"}, + {"$ref": "https://json-schema.org/draft/next/meta/validation"}, + {"$ref": "https://example.com/meta/example-vocab", + ], + "patternProperties": { + "^unevaluated": false + }, + "properties": { + "localKeyword": { + "$comment": "Not in vocabulary, but validated if used", + "type": "string" + } + } +} +``` + +This meta-schema describes only a single extension vocabulary. + +```json +{ + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://example.com/meta/example-vocab", + "$dynamicAnchor": "meta", + "$vocabulary": { + "https://example.com/vocab/example-vocab": true, + }, + "type": ["object", "boolean"], + "properties": { + "minDate": { + "type": "string", + "pattern": "\\d\\d\\d\\d-\\d\\d-\\d\\d", + "format": "date", + } + } +} +``` + +As shown above, even though each of the single-vocabulary meta-schemas +referenced in the general-use meta-schema's `allOf` declares its corresponding +vocabulary, this new meta-schema must re-declare them. + +The standard meta-schemas that combine all vocabularies defined by the Core and +Validation specification, and that combine all vocabularies defined by those +specifications as well as the Hyper-Schema specification, demonstrate additional +complex combinations. These IRIs for these meta-schemas may be found in the +Validation and Hyper-Schema specifications, respectively. + +While the general-use meta-schema can validate the syntax of `minDate`, it is +the vocabulary that defines the logic behind the semantic meaning of `minDate`. +Without an understanding of the semantics (in this example, that the instance +value must be a date equal to or after the date provided as the keyword's value +in the schema), an implementation can only validate the syntactic usage. In this +case, that means validating that it is a date-formatted string (using `pattern` +to ensure that it is validated even when `format` functions purely as an +annotation, as explained in the [Validation +specification](#json-schema-validation). + +## Appendix E. References and generative use cases +While the presence of references is expected to be transparent to validation +results, generative use cases such as code generators and UI renderers often +consider references to be semantically significant. + +To make such use case-specific semantics explicit, the best practice is to +create an annotation keyword for use in the same schema object alongside of a +reference keyword such as `$ref`. + +For example, here is a hypothetical keyword for determining whether a code +generator should consider the reference target to be a distinct class, and how +those classes are related. Note that this example is solely for illustrative +purposes, and is not intended to propose a functional code generation keyword. + +```json +{ + "allOf": [ + { + "classRelation": "is-a", + "$ref": "classes/base.json" + }, + { + "$ref": "fields/common.json" + } + ], + "properties": { + "foo": { + "classRelation": "has-a", + "$ref": "classes/foo.json" + }, + "date": { + "$ref": "types/dateStruct.json", + } + } +} +``` + +Here, this schema represents some sort of object-oriented class. The first +reference in the `allOf` is noted as the base class. The second is not assigned +a class relationship, meaning that the code generator should combine the +target's definition with this one as if no reference were involved. + +Looking at the properties, "foo" is flagged as object composition, while the +"date" property is not. It is simply a field with sub-fields, rather than an +instance of a distinct class. + +This style of usage requires the annotation to be in the same object as the +reference, which must be recognizable as a reference. + +## Appendix F. Acknowledgments +Thanks to Gary Court, Francis Galiegue, Kris Zyp, Geraint Luff, and Henry +Andrews for their work on the initial drafts of JSON Schema. + +Thanks to Jason Desrosiers, Daniel Perrett, Erik Wilde, Evgeny Poberezkin, Brad +Bowman, Gowry Sankar, Donald Pipowitch, Dave Finlay, Denis Laxalde, Phil +Sturgeon, Shawn Silverman, and Karen Etheridge for their submissions and patches +to the document. + +## Appendix G. Change Log[^19] +[^19]: This section to be removed before leaving Internet-Draft status. + +### G.1. draft-bhutton-json-schema-next +- `contains` now applies to objects as well as arrays +- Use IRIs instead of URIs +- Remove bookending requirement for `$dynamicRef` +- Add `propertyDependencies` keyword + +### G.2. draft-bhutton-json-schema-01 +- Improve and clarify the `type`, `contains`, `unevaluatedProperties`, and +`unevaluatedItems` keyword explanations +- Clarify various aspects of "canonical URIs" +- Comment on ambiguity around annotations and `additionalProperties` +- Clarify Vocabularies need not be formally defined +- Remove references to remaining media-type parameters +- Fix multiple examples + +### G.3. draft-bhutton-json-schema-00 +- `$schema` MAY change for embedded resources +- Array-value `items` functionality is now `prefixItems` +- `items` subsumes the old function of `additionalItems` +- `contains` annotation behavior, and `contains` and `unevaluatedItems` +interactions now specified +- Rename $recursive* to $dynamic*, with behavior modification +- $dynamicAnchor defines a fragment like $anchor +- $dynamic* (previously $recursive) no longer use runtime base URI determination +- Define Compound Schema Documents (bundle) and processing +- Reference ECMA-262, 11th edition for regular expression support +- Regular expression should support unicode +- Remove media type parameters +- Specify Unknown keywords are collected as annotations +- Moved `unevaluatedItems` and `unevaluatedProperties` from core into their own +vocabulary + +### G.4. draft-handrews-json-schema-02 +- Update to RFC 8259 for JSON specification +- Moved `definitions` from the Validation specification here as `$defs` +- Moved applicator keywords from the Validation specification as their own +vocabulary +- Moved the schema form of `dependencies` from the Validation specification as +`dependentSchemas` +- Formalized annotation collection +- Specified recommended output formats +- Defined keyword interactions in terms of annotation and assertion results +- Added `unevaluatedProperties` and `unevaluatedItems` +- Define `$ref` behavior in terms of the assertion, applicator, and annotation +model +- Allow keywords adjacent to `$ref` +- Note undefined behavior for `$ref` targets involving unknown keywords +- Add recursive referencing, primarily for meta-schema extension +- Add the concept of formal vocabularies, and how they can be recognized through +meta-schemas +- Additional guidance on initial base URIs beyond network retrieval +- Allow "schema" media type parameter for `application/schema+json` +- Better explanation of media type parameters and the HTTP Accept header +- Use `$id` to establish canonical and base absolute-URIs only, no fragments +- Replace plain-name-fragment-only form of `$id` with `$anchor` +- Clarified that the behavior of JSON Pointers across `$id` boundary is +unreliable + +### G.5. draft-handrews-json-schema-01 +- This draft is purely a clarification with no functional changes +- Emphasized annotations as a primary usage of JSON Schema +- Clarified $id by use cases +- Exhaustive schema identification examples +- Replaced "external referencing" with how and when an implementation might know +of a schema from another document +- Replaced "internal referencing" with how an implementation should recognized +schema identifiers during parsing +- Dereferencing the former "internal" or "external" references is always the +same process +- Minor formatting improvements + +### G.6. draft-handrews-json-schema-00 +- Make the concept of a schema keyword vocabulary more clear +- Note that the concept of "integer" is from a vocabulary, not the data model +- Classify keywords as assertions or annotations and describe their general +behavior +- Explain the boolean schemas in terms of generalized assertions +- Reserve `$comment` for non-user-visible notes about the schema +- Wording improvements around `$id` and fragments +- Note the challenges of extending meta-schemas with recursive references +- Add `application/schema-instance+json` media type +- Recommend a "schema" link relation / parameter instead of "profile" + +### G.7. draft-wright-json-schema-01 +- Updated intro +- Allowed for any schema to be a boolean +- `$schema` SHOULD NOT appear in subschemas, although that may change +- Changed `id` to `$id`; all core keywords prefixed with "$" +- Clarify and formalize fragments for `application/schema+json` +- Note applicability to formats such as CBOR that can be represented in the JSON +data model + +### G.8. draft-wright-json-schema-00 +- Updated references to JSON +- Updated references to HTTP +- Updated references to JSON Pointer +- Behavior for `id` is now specified in terms of RFC3986 +- Aligned vocabulary usage for URIs with RFC3986 +- Removed reference to draft-pbryan-zyp-json-ref-03 +- Limited use of `$ref` to wherever a schema is expected +- Added definition of the "JSON Schema data model" +- Added additional security considerations +- Defined use of subschema identifiers for `id` +- Rewrote section on usage with HTTP +- Rewrote section on usage with rel="describedBy" and rel="profile" +- Fixed numerous invalid examples + +### G.9. draft-zyp-json-schema-04 +- Salvaged from draft v3. +- Split validation keywords into separate document. +- Split hypermedia keywords into separate document. +- Initial post-split draft. +- Mandate the use of JSON Reference, JSON Pointer. +- Define the role of `id`. Define URI resolution scope. +- Add interoperability considerations. + +### G.10. draft-zyp-json-schema-00 +- Initial draft. + +## Authors' Addresses + +### Austin Wright (*editor*) +Email: + +### Ben Hutton (*editor*) +Postman + +Email: + +URI: + +### Greg Dennis + +Email: + +URI: diff --git a/jsonschema-core.xml b/jsonschema-core.xml deleted file mode 100644 index 4c4b662a..00000000 --- a/jsonschema-core.xml +++ /dev/null @@ -1,4406 +0,0 @@ - - - - - - - - - - - - - - -]> - - - - - - - - - - - JSON Schema: A Media Type for Describing JSON Documents - - -
- aaa@bzfx.net -
- - - - Postman -
- ben@jsonschema.dev - https://jsonschema.dev -
- - - -
- gregsdennis@yahoo.com - https://github.com/gregsdennis -
- - - - Internet Engineering Task Force - JSON - Schema - Hyper Schema - Hypermedia - - - - JSON Schema defines the media type "application/schema+json", a JSON-based format - for describing the structure of JSON data. - JSON Schema asserts what a JSON document must look like, - ways to extract information from it, - and how to interact with it. - The "application/schema-instance+json" media type provides additional - feature-rich integration with "application/schema+json" beyond what can be offered - for "application/json" documents. - - - - - The issues list for this draft can be found at - . - - - For additional information, see . - - - To provide feedback, use this issue tracker, the communication methods listed on the - homepage, or email the document editors. - - - - - -
- - JSON Schema is a JSON media type for defining the structure of JSON data. JSON Schema - is intended to define validation, documentation, hyperlink navigation, and interaction - control of JSON data. - - - This specification defines JSON Schema core terminology and mechanisms, including - pointing to another JSON Schema by reference, - dereferencing a JSON Schema reference, - specifying the dialect being used, - specifying a dialect's vocabulary requirements, - and defining the expected output. - - - Other specifications define the vocabularies that perform assertions about validation, - linking, annotation, navigation, and interaction. - -
- -
- - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", - "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be - interpreted as described in RFC 2119. - - - - The terms "JSON", "JSON text", "JSON value", "member", "element", "object", "array", - "number", "string", "boolean", "true", "false", and "null" in this document are to - be interpreted as defined in RFC 8259. - -
- -
- - This document proposes a new media type "application/schema+json" to identify a JSON - Schema for describing JSON data. - It also proposes a further optional media type, "application/schema-instance+json", - to provide additional integration features. - JSON Schemas are themselves JSON documents. - This, and related specifications, define keywords allowing authors to describe JSON - data in several ways. - - - JSON Schema uses keywords to assert constraints on JSON instances or annotate those - instances with additional information. Additional keywords are used to apply - assertions and annotations to more complex JSON data structures, or based on - some sort of condition. - - - To facilitate re-use, keywords can be organized into vocabularies. A vocabulary - consists of a list of keywords, together with their syntax and semantics. - A dialect is defined as a set of vocabularies and their required support - identified in a meta-schema. - - - JSON Schema can be extended either by defining additional vocabularies, - or less formally by defining additional keywords outside of any vocabulary. - Unrecognized individual keywords simply have their values collected as annotations, - while the behavior with respect to an unrecognized vocabulary can be controlled - when declaring which vocabularies are in use. - - - This document defines a core vocabulary that MUST be supported by any - implementation, and cannot be disabled. Its keywords are each prefixed - with a "$" character to emphasize their required nature. This vocabulary - is essential to the functioning of the "application/schema+json" media - type, and is used to bootstrap the loading of other vocabularies. - - - Additionally, this document defines a RECOMMENDED vocabulary of keywords - for applying subschemas conditionally, and for applying subschemas to - the contents of objects and arrays. Either this vocabulary or one very - much like it is required to write schemas for non-trivial JSON instances, - whether those schemas are intended for assertion validation, annotation, - or both. While not part of the required core vocabulary, for maximum - interoperability this additional vocabulary is included in this document - and its use is strongly encouraged. - - - Further vocabularies for purposes such as structural validation or - hypermedia annotation are defined in other documents. These other - documents each define a dialect collecting the standard sets of - vocabularies needed to write schemas for that document's purpose. - -
- -
- -
- - A JSON document is an information resource (series of octets) described by the - application/json media type. - - - In JSON Schema, the terms "JSON document", "JSON text", and "JSON value" are - interchangeable because of the data model it defines in . - - - JSON Schema is only defined over JSON documents. However, any document or memory - structure that can be parsed into or processed according to the JSON Schema data - model can be interpreted against a JSON Schema, including media types like - CBOR. - -
- -
- - A JSON document to which a schema is applied is known as an "instance". - - - JSON Schema is defined over "application/json" or compatible documents, - including media types with the "+json" structured syntax suffix. - - - Among these, this specification defines the "application/schema-instance+json" - media type which defines handling for fragments in the IRI. - - -
- - JSON Schema interprets documents according to a data model. A JSON value - interpreted according to this data model is called an "instance". - - - An instance has one of six primitive types, and a range of possible values - depending on the type: - -
-
null
A JSON "null" value
-
boolean
A "true" or "false" value, from the JSON "true" or "false" value
-
object
An unordered set of properties mapping a string to an instance, from the JSON "object" value
-
array
An ordered list of instances, from the JSON "array" value
-
number
An arbitrary-precision, base-10 decimal number value, from the JSON "number" value
-
string
A string of Unicode code points, from the JSON "string" value
-
- - - Whitespace and formatting concerns, including different lexical - representations of numbers that are equal within the data model, are thus - outside the scope of JSON Schema. JSON Schema - vocabularies that wish - to work with such differences in lexical representations SHOULD define - keywords to precisely interpret formatted strings within the data model - rather than relying on having the original JSON representation Unicode - characters available. - - - Since an object cannot have two properties with the same key, behavior for a - JSON document that tries to define two properties with - the same key in a single object is undefined. - - - Note that JSON Schema vocabularies are free to define their own extended - type system. This should not be confused with the core data model types - defined here. As an example, "integer" is a reasonable type for a - vocabulary to define as a value for a keyword, but the data model - makes no distinction between integers and other numbers. - -
- -
- - Two JSON instances are said to be equal if and only if they are of the same type - and have the same value according to the data model. Specifically, this means: - -
    -
  • both are null; or
    • -
  • both are true; or
    • -
  • both are false; or
    • -
  • both are strings, and are the same codepoint-for-codepoint; or
    • -
  • both are numbers, and have the same mathematical value; or
    • -
  • both are arrays, and have an equal value item-for-item; or
    • -
  • both are objects, and each property in one has exactly one property with - a key equal to the other's, and that other property has an equal - value.
    • -
- - - Implied in this definition is that arrays must be the same length, - objects must have the same number of members, - properties in objects are unordered, - there is no way to define multiple properties with the same key, - and mere formatting differences (indentation, placement of commas, trailing - zeros) are insignificant. - -
- -
- - It is possible to use JSON Schema with a superset of the JSON Schema data model, - where an instance may be outside any of the six JSON data types. - - - In this case, annotations still apply; but most validation keywords will not be useful, - as they will always pass or always fail. - - - A custom vocabulary may define support for a superset of the core data model. - The schema itself may only be expressible in this superset; - for example, to make use of the "const" keyword. - -
-
- -
- - A JSON Schema document, or simply a schema, is a JSON document used to describe - an instance. - A schema can itself be interpreted as an instance, but SHOULD always be given - the media type "application/schema+json" rather than - "application/schema-instance+json". The "application/schema+json" media - type is defined to offer a superset of the - fragment identifier syntax and semantics provided by - "application/schema-instance+json". - - - A JSON Schema MUST be an object or a boolean. - -
- - Object properties that are applied to the instance are called keywords, - or schema keywords. Broadly speaking, keywords fall into one - of five categories: - -
-
identifiers
-
- control schema identification through setting a IRI - for the schema and/or changing how the base IRI is determined -
-
assertions
-
- produce a boolean result when applied to an instance -
-
annotations
-
- attach information to an instance for application use -
-
applicators
-
- apply one or more subschemas to a particular location - in the instance, and combine or modify their results -
-
reserved locations
-
- do not directly affect results, but reserve a place - for a specific purpose to ensure interoperability -
-
- - Keywords may fall into multiple categories, although applicators - SHOULD only produce assertion results based on their subschemas' - results. They should not define additional constraints independent - of their subschemas. - - - Keywords which are properties within the same schema object are referred to as adjacent keywords. - - - Extension keywords, meaning those defined outside of this document - and its companions, are free to define other behaviors as well. - - - A JSON Schema MAY contain properties which are not schema keywords or are not recognized as schema keywords. - The behavior of such keywords is governed by . - - - An empty schema is a JSON Schema with no properties. - -
-
- - The boolean schema values "true" and "false" are trivial schemas that - always produce themselves as assertion results, regardless of the - instance value. They never produce annotation results. - - - These boolean schemas exist to clarify schema author intent and - facilitate schema processing optimizations. They behave identically - to the following schema objects (where "not" is part of the - subschema application vocabulary defined in this document). - -
-
true
-
- Always passes validation, as if the empty schema {} -
- -
false
-
- Always fails validation, as if the schema { "not": {} } -
-
- - While the empty schema object is unambiguous, there are many - possible equivalents to the "false" schema. Using the boolean - values ensures that the intent is clear to both human readers - and implementations. - -
-
- - A schema vocabulary, or simply a vocabulary, is a set of keywords, - their syntax, and their semantics. A vocabulary is generally organized - around a particular purpose. Different uses of JSON Schema, such - as validation, hypermedia, or user interface generation, will - involve different sets of vocabularies. - - - Vocabularies are the primary unit of re-use in JSON Schema, as schema - authors can indicate what vocabularies are required or optional in - order to process the schema. Since vocabularies are identified by IRIs - in the meta-schema, generic implementations can load extensions to support - previously unknown vocabularies. While keywords can be supported outside - of any vocabulary, there is no analogous mechanism to indicate individual - keyword usage. - - - A schema vocabulary can be defined by anything from an informal description - to a standards proposal, depending on the audience and interoperability - expectations. In particular, in order to facilitate vocabulary use within - non-public organizations, a vocabulary specification need not be published - outside of its scope of use. - -
-
- - A schema that itself describes a schema is called a meta-schema. - Meta-schemas are used to validate JSON Schemas and specify which vocabularies - they are using. - - - Typically, a meta-schema will specify a set of vocabularies, and validate - schemas that conform to the syntax of those vocabularies. However, meta-schemas - and vocabularies are separate in order to allow meta-schemas to validate - schema conformance more strictly or more loosely than the vocabularies' - specifications call for. Meta-schemas may also describe and validate - additional keywords that are not part of a formal vocabulary. - -
-
- - A JSON Schema resource is a schema which is - canonically identified by an - absolute IRI. Schema resources MAY - also be identified by IRIs, including IRIs with fragments, - if the resulting secondary resource (as defined by - section 3.5 of RFC 3986) is identical - to the primary resource. This can occur with the empty fragment, - or when one schema resource is embedded in another. Any such IRIs - with fragments are considered to be non-canonical. - - - The root schema is the schema that comprises the entire JSON document - in question. The root schema is always a schema resource, where the - IRI is determined as described in . - - Note that documents that embed schemas in another format will not - have a root schema resource in this sense. Exactly how such usages - fit with the JSON Schema document and resource concepts will be - clarified in a future draft. - - - - Some keywords take schemas themselves, allowing JSON Schemas to be nested: - - - - In this example document, the schema titled "array item" is a subschema, - and the schema titled "root" is the root schema. - - - As with the root schema, a subschema is either an object or a boolean. - - - As discussed in , a JSON Schema document - can contain multiple JSON Schema resources. When used without qualification, - the term "root schema" refers to the document's root schema. In some - cases, resource root schemas are discussed. A resource's root schema - is its top-level schema object, which would also be a document root schema - if the resource were to be extracted to a standalone JSON Schema document. - - - Whether multiple schema resources are embedded or linked with a reference, - they are processed in the same way, with the same available behaviors. - -
-
- -
- -
- - In accordance with section 3.1 of RFC 6839, - the syntax and semantics of fragment identifiers specified for - any +json media type SHOULD be as specified for "application/json". - (At publication of this document, there is no fragment identification - syntax defined for "application/json".) - - - Additionally, the "application/schema+json" media type supports two - fragment identifier structures: plain names and JSON Pointers. - The "application/schema-instance+json" media type supports one - fragment identifier structure: JSON Pointers. - - - The use of JSON Pointers as IRI fragment identifiers is described in - RFC 6901. - For "application/schema+json", which supports two fragment identifier syntaxes, - fragment identifiers matching the JSON Pointer syntax, including the empty string, - MUST be interpreted as JSON Pointer fragment identifiers. - - - Per the W3C's - best practices for fragment identifiers, - plain name fragment identifiers in "application/schema+json" are reserved for referencing - locally named schemas. - - - Plain name fragments MUST start with a letter ([A-Za-z]) or underscore ("_"), - followed by any number of letters, digits ([0-9]), hyphens ("-"), - underscores ("_"), and periods ("."). This matches the US-ASCII part of XML's - NCName production, which allows for compatibility - with the recommended plain name syntax for - XML-based media types. - - - All fragment identifiers that do - not match the JSON Pointer syntax MUST be interpreted as - plain name fragment identifiers. - - - Defining and referencing a plain name fragment identifier within an - "application/schema+json" document are specified - in the "$anchor" keyword section. - -
- -
- -
- - An instance may be any valid JSON value as defined by JSON. - JSON Schema imposes no restrictions on type: JSON Schema can describe any JSON - value, including, for example, null. - -
- -
- - JSON Schema is programming language agnostic, and supports the full range of - values described in the data model. - Be aware, however, that some languages and JSON parsers may not be able to - represent in memory the full range of values describable by JSON. - -
- -
- - Some programming languages and parsers use different internal representations - for floating point numbers than they do for integers. - - - For consistency, integer JSON numbers SHOULD NOT be encoded with a fractional - part. - -
- -
- - Keywords MAY use regular expressions to express constraints, or constrain - the instance value to be a regular expression. - These regular expressions SHOULD be valid according to the regular expression - dialect described in ECMA-262, section 21.2.1. - - - Unless otherwise specified by a keyword, regular expressions MUST NOT be - considered to be implicitly anchored at either end. All regular expression - keywords in this specification and its companion documents are un-anchored. - - - Regular expressions SHOULD be built with the "u" flag (or equivalent) to provide - Unicode support, or processed in such a way which provides Unicode support as - defined by ECMA-262. - - - Furthermore, given the high disparity in regular expression constructs support, - schema authors SHOULD limit themselves to the following regular expression - tokens: - -
    -
  • individual Unicode characters, as defined by the JSON specification;
    • -
  • simple character classes ([abc]), range character classes ([a-z]);
    • -
  • complemented character classes ([^abc], [^a-z]);
    • -
  • simple quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or - one), and their lazy versions ("+?", "*?", "??");
    • -
  • range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at least x, at - most y, occurrences), {x,} (x occurrences or more), and their lazy - versions;
    • -
  • the beginning-of-input ("^") and end-of-input ("$") anchors;
    • -
  • simple grouping ("(...)") and alternation ("|").
    • -
- - - Finally, implementations MUST NOT take regular expressions to be - anchored, neither at the beginning nor at the end. This means, for instance, - the pattern "es" matches "expression". - -
- -
- - Additional schema keywords and schema vocabularies MAY be defined - by any entity. Save for explicit agreement, schema authors SHALL NOT - expect these additional keywords and vocabularies to be supported by - implementations that do not explicitly document such support. - - - Implementations MAY provide the ability to register or load handlers - for vocabularies that they do not support directly. The exact mechanism - for registering and implementing such handlers is implementation-dependent. - - -
- - The values of keywords which begin with "x-" MUST be collected as annotations. - - - Keywords which begin with "x-" symbol MUST NOT affect evaluation - of a schema in any way other than annotation collection. - - - Consequently, the "x-" prefix is reserved for this purpose, and - extension vocabularies MUST NOT define any keywords which begin - with this prefix. - -
- -
- - Implementations SHOULD treat keywords they do not recognize, or that - they recognize but do not support, as annotations, where the value of - the keyword is the value of the annotation. Whether an implementation - collects these annotations or not, they MUST otherwise ignore the keywords. - -
-
- -
- -
- - JSON Schema keywords fall into several general behavior categories. - Assertions validate that an instance satisfies constraints, producing - a boolean result. Annotations attach information that applications - may use in any way they see fit. - Applicators apply subschemas to parts of the instance and combine - their results. - - - Extension keywords SHOULD stay within these categories, keeping in mind - that annotations in particular are extremely flexible. Complex behavior - is usually better delegated to applications on the basis of annotation - data than implemented directly as schema keywords. However, extension - keywords MAY define other behaviors for specialized purposes. - - - Evaluating an instance against a schema involves processing all of the - keywords in the schema against the appropriate locations within the instance. - Typically, applicator keywords are processed until a schema object with no - applicators (and therefore no subschemas) is reached. The appropriate - location in the instance is evaluated against the assertion and - annotation keywords in the schema object. The interactions of those - keyword results to produce the schema object results are governed by - , while the - relationship of subschema results to the results of the applicator - keyword that applied them is described by . - - - Evaluation of a parent schema object can complete once all of its - subschemas have been evaluated, although in some circumstances evaluation - may be short-circuited due to assertion results. When annotations are - being collected, some assertion result short-circuiting is not possible - due to the need to examine all subschemas for annotation collection, including - those that cannot further change the assertion result. - -
- - While most JSON Schema keywords can be evaluated on their own, - or at most need to take into account the values or results of - adjacent keywords in the same schema object, a few have more - complex behavior. - - - The lexical scope of a keyword is determined by the nested JSON - data structure of objects and arrays. The largest such scope - is an entire schema document. The smallest scope is a single - schema object with no subschemas. - - - Keywords MAY be defined with a partial value, such as a IRI-reference, - which must be resolved against another value, such as another - IRI-reference or a full IRI, which is found through the lexical - structure of the JSON document. The "$id", "$ref", and - "$dynamicRef" core keywords, and the "base" JSON Hyper-Schema - keyword, are examples of this sort of behavior. - - - Note that some keywords, such as "$schema", apply to the lexical - scope of the entire schema resource, and therefore MUST only - appear in a schema resource's root schema. - - - Other keywords may take into account the dynamic scope that - exists during the evaluation of a schema, typically together - with an instance document. - The outermost dynamic scope is the schema object at - which processing begins, even if it is not a schema resource root. - The path from this root schema to any particular keyword (that - includes any "$ref" and "$dynamicRef" keywords that may have - been resolved) is considered the keyword's "evaluation path." - - - Lexical and dynamic scopes align until a reference keyword - is encountered. While following the reference keyword moves processing - from one lexical scope into a different one, from the perspective - of dynamic scope, following a reference is no different from descending - into a subschema present as a value. A keyword on the far side of - that reference that resolves information through the dynamic scope - will consider the originating side of the reference to be their - dynamic parent, rather than examining the local lexically enclosing parent. - - - The concept of dynamic scope is primarily used with "$dynamicRef" and - "$dynamicAnchor", and should be considered an advanced feature - and used with caution when defining additional keywords. It also appears - when reporting errors and collected annotations, as it may be possible - to revisit the same lexical scope repeatedly with different dynamic - scopes. In such cases, it is important to inform the user of the - evaluation path that produced the error or annotation. - -
-
- - Keyword behavior MAY be defined in terms of the annotation results - of subschemas and/or adjacent keywords - (keywords within the same schema object) and their subschemas. - Such keywords MUST NOT result in a circular dependency. - Keywords MAY modify their behavior based on the presence or absence - of another keyword in the same - schema object. - -
-
- - A missing keyword MUST NOT produce a false assertion result, MUST - NOT produce annotation results, and MUST NOT cause any other schema - to be evaluated as part of its own behavioral definition. - However, given that missing keywords do not contribute annotations, - the lack of annotation results may indirectly change the behavior - of other keywords. - - - In some cases, the missing keyword assertion behavior of a keyword is - identical to that produced by a certain value, and keyword definitions - SHOULD note such values where known. However, even if the value which - produces the default behavior would produce annotation results if - present, the default behavior still MUST NOT result in annotations. - - - Because annotation collection can add significant cost in terms of both - computation and memory, implementations MAY opt out of this feature. - Keywords that are specified in terms of collected annotations SHOULD - describe reasonable alternate approaches when appropriate. - This approach is demonstrated by the - "" and - "" keywords in this - document. - - - Note that when no such alternate approach is possible for a keyword, - implementations that do not support annotation collections will not - be able to support those keywords or vocabularies that contain them. - -
-
- - Identifiers define IRIs for a schema, or affect how such IRIs are - resolved in references, or both. - The Core vocabulary defined in this document defines several - identifying keywords, most notably "$id". - - - Canonical schema IRIs MUST NOT change while processing an instance, but - keywords that affect IRI-reference resolution MAY have behavior that - is only fully determined at runtime. - - - While custom identifier keywords are possible, vocabulary designers should - take care not to disrupt the functioning of core keywords. For example, - the "$dynamicAnchor" keyword in this specification limits its IRI resolution - effects to the matching "$dynamicRef" keyword, leaving the behavior - of "$ref" undisturbed. - -
-
- - Applicators allow for building more complex schemas than can be accomplished - with a single schema object. Evaluation of an instance against a - schema document begins by applying - the root schema to the complete instance - document. From there, keywords known as applicators are used to determine - which additional schemas are applied. Such schemas may be applied in-place - to the current location, or to a child location. - - - The schemas to be applied may be present as subschemas comprising all or - part of the keyword's value. Alternatively, an applicator may refer to - a schema elsewhere in the same schema document, or in a different one. - The mechanism for identifying such referenced schemas is defined by the - keyword. - - - Applicator keywords also define how subschema or referenced schema - boolean assertion - results are modified and/or combined to produce the boolean result - of the applicator. Applicators may apply any boolean logic operation - to the assertion results of subschemas, but MUST NOT introduce new - assertion conditions of their own. - - - Annotation results from subschemas - are preserved in accordance with so that applications - can decide how to interpret multiple values. Applicator keywords - do not play a direct role in this preservation. - -
- - As noted in , an applicator keyword may - refer to a schema to be applied, rather than including it as a - subschema in the applicator's value. In such situations, the - schema being applied is known as the referenced schema, while - the schema containing the applicator keyword is the referencing schema. - - - While root schemas and subschemas are static concepts based on a - schema's position within a schema document, referenced and referencing - schemas are dynamic. Different pairs of schemas may find themselves - in various referenced and referencing arrangements during the evaluation - of an instance against a schema. - - - For some by-reference applicators, such as - "$ref", the referenced schema can be determined - by static analysis of the schema document's lexical scope. Others, - such as "$dynamicRef" (with "$dynamicAnchor"), may make use of dynamic - scoping, and therefore only be resolvable in the process of evaluating - the schema with an instance. - -
-
- -
- - JSON Schema can be used to assert constraints on a JSON document, which - either passes or fails the assertions. This approach can be used to validate - conformance with the constraints, or document what is needed to satisfy them. - - - JSON Schema implementations produce a single boolean result when evaluating - an instance against schema assertions. - - - An instance can only fail an assertion that is present in the schema. - - -
- - Most assertions only constrain values within a certain - primitive type. When the type of the instance is not of the type - targeted by the keyword, the instance is considered to conform - to the assertion. - - - For example, the "maxLength" keyword from the companion - validation vocabulary: - will only restrict certain strings - (that are too long) from being valid. If the instance is a number, - boolean, null, array, or object, then it is valid against this assertion. - - - This behavior allows keywords to be used more easily with instances - that can be of multiple primitive types. The companion validation - vocabulary also includes a "type" keyword which can independently - restrict the instance to one or more primitive types. This allows - for a concise expression of use cases such as a function that might - return either a string of a certain length or a null value: - - - - If "maxLength" also restricted the instance type to be a string, - then this would be substantially more cumbersome to express because - the example as written would not actually allow null values. - Each keyword is evaluated separately unless explicitly specified - otherwise, so if "maxLength" restricted the instance to strings, - then including "null" in "type" would not have any useful effect. - -
-
- -
- - JSON Schema can annotate an instance with information, whenever the instance - validates against the schema object containing the annotation, and all of its - parent schema objects. The information can be a simple value, or can be - calculated based on the instance contents. - - - Annotations are attached to specific locations in an instance. - Since many subschemas can be applied to any single - location, applications may need to decide how to handle differing - annotation values being attached to the same instance location by - the same schema keyword in different schema objects. - - - Unlike assertion results, annotation data can take a wide variety of forms, - which are provided to applications to use as they see fit. JSON Schema - implementations are not expected to make use of the collected information - on behalf of applications. - - - Unless otherwise specified, the value of an annotation keyword - is the keyword's value. However, other behaviors are possible. - For example, JSON Hyper-Schema's - "links" keyword is a complex annotation that produces a value based - in part on the instance data. - - - While "short-circuit" evaluation is possible for assertions, collecting - annotations requires examining all schemas that apply to an instance - location, even if they cannot change the overall assertion result. - The only exception is that subschemas of a schema object that has - failed validation MAY be skipped, as annotations are not retained - for failing schemas. - - -
- - Annotations are collected by keywords that explicitly define - annotation-collecting behavior. Note that boolean schemas cannot - produce annotations as they do not make use of keywords. - - - A collected annotation MUST include the following information: - -
    -
  • - The name of the keyword that produces the annotation -
    • -
  • - The instance location to which it is attached, as a JSON Pointer -
    • -
  • - The evaluation path, indicating how reference keywords - such as "$ref" were followed to reach the absolute schema location. -
    • -
  • - The absolute schema location of the attaching keyword, as a IRI. - This MAY be omitted if it is the same as the evaluation path - from above. -
    • -
  • - The attached value(s) -
    • -
-
- - Applications MAY make decisions on which of multiple annotation values - to use based on the schema location that contributed the value. - This is intended to allow flexible usage. Collecting the schema location - facilitates such usage. - - - For example, consider this schema, which uses annotations and assertions from - the Validation specification: - - - Note that some lines are wrapped for clarity. - - - - In this example, both Feature A and Feature B make use of the re-usable - "enabledToggle" schema. That schema uses the "title", "description", - and "default" annotations. Therefore the application has to decide how - to handle the additional "default" value for Feature A, and the additional - "description" value for Feature B. - - - The application programmer and the schema author need to agree on the - usage. For this example, let's assume that they agree that the most - specific "default" value will be used, and any additional, more generic - "default" values will be silently ignored. Let's also assume that they - agree that all "description" text is to be used, starting with the most - generic, and ending with the most specific. This requires the schema - author to write descriptions that work when combined in this way. - - - The application can use the evaluation path to determine which - values are which. The values in the feature's immediate "enabled" - property schema are more specific, while the values under the re-usable - schema that is referenced to with "$ref" are more generic. The evaluation - path will show whether each value was found by crossing a - "$ref" or not. - - - Feature A will therefore use a default value of true, while Feature B - will use the generic default value of null. Feature A will only - have the generic description from the "enabledToggle" schema, while - Feature B will use that description, and also append its locally - defined description that explains how to interpret a null value. - - - Note that there are other reasonable approaches that a different application - might take. For example, an application may consider the presence of - two different values for "default" to be an error, regardless of their - schema locations. - -
-
- - Schema objects that produce a false assertion result MUST NOT - produce any annotation results, whether from their own keywords - or from keywords in subschemas. - - - Note that the overall schema results may still include annotations - collected from other schema locations. Given this schema: - - - - Against the instance "This is a string", the - title annotation "Integer Value" is discarded because the type assertion - in that schema object fails. The title annotation "String Value" - is kept, as the instance passes the string type assertions. - -
-
-
-
- - A fourth category of keywords simply reserve a location to hold re-usable - components or data of interest to schema authors that is not suitable - for re-use. These keywords do not affect validation or annotation results. - Their purpose in the core vocabulary is to ensure that locations are - available for certain purposes and will not be redefined by extension - keywords. - - - While these keywords do not directly affect results, as explained in - unrecognized - extension keywords that reserve locations for re-usable schemas may have - undesirable interactions with references in certain circumstances. - -
-
- - While none of the vocabularies defined as part of this or the associated documents - define a keyword which may target and/or load instance data, it is possible that - other vocabularies may wish to do so. - - - Keywords MAY be defined to use JSON Pointers or Relative JSON Pointers to examine - parts of an instance outside the current evaluation location. - - - Keywords that allow adjusting the location using a Relative JSON Pointer SHOULD - default to using the current location if a default is desireable. - -
-
-
- - Keywords declared in this section, which all begin with "$", make up - the JSON Schema Core vocabulary. These keywords are either required in - order to process any schema or meta-schema, including those split across - multiple documents, or exist to reserve keywords for purposes that - require guaranteed interoperability. - - - The Core vocabulary MUST be considered mandatory at all times, in order - to bootstrap the processing of further vocabularies. Meta-schemas - that use the "$vocabulary" keyword - to declare the vocabularies in use MUST explicitly list the Core vocabulary, - which MUST have a value of true indicating that it is required. - - - The behavior of a false value for this vocabulary (and only this - vocabulary) is undefined, as is the behavior when "$vocabulary" - is present but the Core vocabulary is not included. However, it - is RECOMMENDED that implementations detect these cases and raise - an error when they occur. It is not meaningful to declare that - a meta-schema optionally uses Core. - - - Meta-schemas that do not use "$vocabulary" MUST be considered to - require the Core vocabulary as if its IRI were present with a value of true. - - - The current IRI for the Core vocabulary is: - <https://json-schema.org/draft/next/vocab/core>. - - - The current IRI for the corresponding meta-schema is: - . - - - The "$" prefix is reserved for use by the Core vocabulary. - Vocabulary extensions MUST NOT define new keywords that begin with "$". - - -
- - Two concepts, meta-schemas and vocabularies, are used to inform an implementation - how to interpret a schema. Every schema has a meta-schema, which can be declared - using the "$schema" keyword. - - - The meta-schema serves two purposes: - -
-
Declaring the vocabularies in use
-
- The "$vocabulary" keyword, when it appears in a meta-schema, declares - which vocabularies are available to be used in schemas that refer - to that meta-schema. Vocabularies define keyword semantics, - as well as their general syntax. -
-
Describing valid schema syntax
-
- A schema MUST successfully validate against its meta-schema, which - constrains the syntax of the available keywords. The syntax described - is expected to be compatible with the vocabularies declared; while - it is possible to describe an incompatible syntax, such a meta-schema - would be unlikely to be useful. -
-
- - Meta-schemas are separate from vocabularies to allow for - vocabularies to be combined in different ways, and for meta-schema authors - to impose additional constraints such as forbidding certain keywords, or - performing unusually strict syntactical validation, as might be done - during a development and testing cycle. Each vocabulary typically identifies - a meta-schema consisting only of the vocabulary's keywords. - - - Meta-schema authoring is an advanced usage of JSON Schema, so the design of - meta-schema features emphasizes flexibility over simplicity. - -
- - The "$schema" keyword is both used as a JSON Schema dialect identifier and - as the identifier of a resource which is itself a JSON Schema, which describes the - set of valid schemas written for this particular dialect. - - - The value of this keyword MUST be a IRI - (containing a scheme) and this IRI MUST be normalized. - The current schema MUST be valid against the meta-schema identified by this IRI. - - - If this IRI identifies a retrievable resource, that resource SHOULD be of - media type "application/schema+json". - - - The "$schema" keyword SHOULD be used in the document root schema object, - and MAY be used in the root schema objects of embedded schema resources. - It MUST NOT appear in non-resource root schema objects. If absent from - the document root schema, the resulting behavior is implementation-defined, - but MUST fall within the following options: -
    -
  • Refuse to process the schema, as with unsupported required - vocabularies
    • -
  • Assume a specific, documented meta-schema
    • -
  • Document the process by which it examines the schema and determines - which of a specific set of meta-schemas to assume
    • -
- - - Values for this property are defined elsewhere in this and other documents, - and by other parties. - -
-
- - The "$vocabulary" keyword is used in meta-schemas to identify the - vocabularies available for use in schemas described by that meta-schema, - and whether each vocabulary is required or optional. Together, this - information forms a dialect. - - - The value of this keyword MUST be an object. The property names in the - object MUST be IRIs (containing a scheme) and each IRI MUST be normalized. - Each IRI that appears as a property name identifies a specific set of - keywords and their semantics. - - - The IRI MAY be a URL, but the nature of the retrievable resource is - currently undefined, and reserved for future use. Vocabulary authors - MAY use the URL of the vocabulary specification, in a human-readable - media type such as text/html or text/plain, as the vocabulary IRI. - - Vocabulary documents may be added in forthcoming drafts. - For now, identifying the keyword set is deemed sufficient as that, - along with meta-schema validation, is how the current "vocabularies" - work today. Any future vocabulary document format will be specified - as a JSON document, so using text/html or other non-JSON formats - in the meantime will not produce any future ambiguity. - - - - The values of the object properties MUST be booleans. - If the value is true, then the vocabulary MUST be considered to be required. - If the value is false, then the vocabulary MUST be considered to be optional. - -
- - A schema is said to use a dialect and its constituent vocabularies if it is - associated with a meta-schema defining the dialect with "$vocabulary", - either through "$schema", through appropriately defined media type parameters - or link relation types, or through documented default implementation-defined - behavior in the absence of an explicit meta-schema. If a meta-schema - does not contain "$vocabulary", the set of vocabularies in use is determined - according to . - - - Any vocabulary in use by a schema and understood by the implementation - MUST be processed in a manner consistent with the semantic definitions - contained within the vocabulary, regardless of whether that vocabulary - is required or optional. - - - Any vocabulary that is not present in "$vocabulary" MUST NOT be made - available for use in schemas described by that meta-schema, except for - the core vocabulary as specified by the introduction to - . - - - Implementations that do not support a vocabulary required by a schema - MUST refuse to process that schema. - - - Implementations that do not support a vocabulary that is optionally used - by a schema SHOULD proceed with processing the schema. The keywords will - be considered to be unrecognized keywords as addressed by - . Note that since - the recommended behavior for such keywords is to collect them as - annotations, vocabularies consisting only of annotations will have - the same behavior when used optionally whether the implementation - supports them or not. This allows annotation-only vocabularies to - be supported without custom code, even in implementations that do - not support providing custom code for extension vocabularies. - -
-
- - The "$vocabulary" keyword SHOULD be used in the root schema of any schema - resource intended for use as a meta-schema. It MUST NOT appear in subschemas. - - - The "$vocabulary" keyword MUST be ignored in schema resources that - are not being processed as a meta-schema. This allows validating - a meta-schema M against its own meta-schema M' without requiring - the validator to understand the vocabularies declared by M. - -
-
- - Keywords from different vocabularies, as well as non-vocabulary - extension keywords, can have identical names. These are not - considered to be the same keyword from the perspective of - enabling or disabling them through "$vocabulary". - - - In particular the keywords defined in this specification and its - companion documents MUST be considered to be vocabulary keywords, - with availability governed by "$vocabulary" even in implementations - that do not support any extension vocabularies. - - - Guidance regarding vocabularies with identically-named keywords is provided - in . - -
-
- - If "$vocabulary" is absent, an implementation MAY determine - behavior based on the meta-schema if it is recognized from the - IRI value of the referring schema's "$schema" keyword. - This is how behavior (such as Hyper-Schema usage) has been - recognized prior to the existence of vocabularies. - - - If the meta-schema, as referenced by the schema, is not recognized, - or is missing, then the behavior is implementation-defined. - If the implementation - proceeds with processing the schema, it MUST assume the use of the - core vocabulary. If the implementation is built for a specific purpose, - then it SHOULD assume the use of all of the most relevant vocabularies - for that purpose. - - - For example, an implementation that is a validator - SHOULD assume the use of all vocabularies in this - specification and the companion Validation specification. - -
-
- - Note that the processing restrictions on "$vocabulary" mean that - meta-schemas that reference other meta-schemas using "$ref" or - similar keywords do not automatically inherit the vocabulary - declarations of those other meta-schemas. All such declarations - must be repeated in the root of each schema document intended - for use as a meta-schema. This is demonstrated in - the example meta-schema. - - This requirement allows implementations to find all vocabulary - requirement information in a single place for each meta-schema. - As schema extensibility means that there are endless potential - ways to combine more fine-grained meta-schemas by reference, - requiring implementations to anticipate all possibilities and - search for vocabularies in referenced meta-schemas would - be overly burdensome. - - -
-
-
- - Updated vocabulary and meta-schema IRIs MAY be published between - specification drafts in order to correct errors. Implementations - SHOULD consider IRIs dated after this specification draft and - before the next to indicate the same syntax and semantics - as those listed here. - -
-
- -
- - To differentiate between schemas in a vast ecosystem, schemas are - identified by IRI, and can embed references - to other schemas by specifying their IRI. - - - Several keywords can accept a relative IRI-reference, - or a value used to construct a relative IRI-reference. For these keywords, - it is necessary to establish a base IRI in order to resolve the reference. - - -
- - The "$id" keyword identifies a schema resource with its - canonical IRI. - - - Note that this IRI is an identifier and not necessarily a network locator. - In the case of a network-addressable URL, a schema need not be downloadable - from its canonical IRI. - - - If present, the value for this keyword MUST be a string, and MUST represent a - valid IRI-reference. This IRI-reference - SHOULD be normalized, and MUST resolve to an - absolute-IRI (without a fragment). - - - The resulting absolute-IRI serves as the base IRI for relative IRI-references - in keywords within the schema resource, in accordance with - RFC 3987 section 6.5 and - RFC 3986 section 5.1.1 regarding base IRIs - embedded in content. - - - The presence of "$id" in a subschema indicates that the subschema constitutes - a distinct schema resource within a single schema document. Furthermore, - in accordance with RFC 3987 section 6.5 and - RFC 3986 section 5.1.2 regarding - encapsulating entities, if an "$id" in a subschema is a relative - IRI-reference, the base IRI for resolving that reference is the IRI of - the parent schema resource. Note that an "$id" consisting of an empty IRI or - of the empty fragment only will result in the embedded resource having - the same IRI as the encapsulating resource, which SHOULD be considered - an error per . - - - If no parent schema object explicitly identifies itself as a resource - with "$id", the base IRI is that of the entire document, as established - by the steps given in the previous section. - -
- - The root schema of a JSON Schema document SHOULD contain an "$id" keyword - with an absolute-IRI (containing a scheme, - but no fragment). - -
-
-
- - Using JSON Pointer fragments requires knowledge of the structure of the schema. - When writing schema documents with the intention to provide re-usable - schemas, it may be preferable to use a plain name fragment that is not tied to - any particular structural location. This allows a subschema to be relocated - without requiring JSON Pointer references to be updated. - - - The "$anchor" and "$dynamicAnchor" keywords are used to specify such - fragments. They are identifier keywords that can only be used to create - plain name fragments, rather than absolute IRIs as seen with "$id". - - - The base IRI to which the resulting fragment is appended is the canonical - IRI of the schema resource containing the "$anchor" or "$dynamicAnchor" - in question. As discussed in the previous section, this is either the - nearest "$id" in the same or parent schema object, - or the base IRI for the document as determined according to - RFC 3987 and - RFC 3986. - - - Separately from the usual usage of IRIs, "$dynamicAnchor" - indicates that the fragment is an extension point when used with - the "$dynamicRef" keyword. This low-level, advanced feature - makes it easier to extend recursive schemas such as the meta-schemas, - without imposing any particular semantics on that extension. - See the section on "$dynamicRef" - for details. - - - In most cases, the normal fragment behavior both suffices and - is more intuitive. Therefore it is RECOMMENDED that "$anchor" - be used to create plain name fragments unless there is a clear - need for "$dynamicAnchor". - - - If present, the value of these keywords MUST be a string and MUST conform - to the plain name fragment identifier syntax defined in - . - - Note that the anchor string does not include the "#" character, - as it is not a IRI-reference. An "$anchor": "foo" becomes the - fragment "#foo" when used in a IRI. See below for full examples. - - -
- -
- - A schema MAY (and likely will) have multiple IRIs, but there is no way - for an IRI to identify more than one schema. When multiple schemas - attempt to identify as the same IRI through the use of "$id", "$anchor", - "$dynamicAnchor", or any other mechanism, implementations SHOULD raise - an error condition. Otherwise the result is undefined, and even if - documented will not be interoperable. - -
- -
- - Several keywords can be used to reference a schema which is to be applied to the - current instance location. "$ref" and "$dynamicRef" are applicator - keywords, applying the referenced schema to the instance. - - - As the values of "$ref" and "$dynamicRef" are IRI References, this allows - the possibility to externalise or divide a schema across multiple files, - and provides the ability to validate recursive structures through - self-reference. - - - The resolved IRI produced by these keywords is not necessarily a network - locator, only an identifier. A schema need not be downloadable from the - address if it is a network-addressable URL, and implementations SHOULD NOT - assume they should perform a network operation when they encounter - a network-addressable IRI. - - -
- - The "$ref" keyword is an applicator that is used to reference a statically - identified schema. Its results are the results of the referenced schema. - - Note that this definition of how the results are determined means that - other keywords can appear alongside of "$ref" in the same schema object. - - - - The value of the "$ref" keyword MUST be a string which is a IRI-Reference. - Resolved against the current IRI base, it produces the IRI of the schema - to apply. This resolution is safe to perform on schema load, as the - process of evaluating an instance cannot change how the reference resolves. - -
- -
- - The "$dynamicRef" keyword is an applicator that allows for deferring the - full resolution until runtime, at which point it is resolved each time it is - encountered while evaluating an instance. - - - Together with "$dynamicAnchor", "$dynamicRef" implements a cooperative - extension mechanism that is primarily useful with recursive schemas - (schemas that reference themselves). The extension point is defined with - "$dynamicAnchor" and only exhibits runtime dynamic behavior when referenced - with "$dynamicRef". - - - The value of the "$dynamicRef" property MUST be a string which is a - IRI-Reference that contains a valid plain name - fragment. Resolved against the current IRI base, it indicates - the schema resource used as the starting point for runtime resolution. - This initial resolution is safe to perform on schema load. - - - The schema to apply is the outermost schema resource in the - dynamic scope that defines a - "$dynamicAnchor" that matches the plain name fragment in the initially - resolved IRI. - - - For a full example using these keyword, see . - - The difference between the hyper-schema meta-schema in pre-2019 - drafts and an this draft dramatically demonstrates the utility - of these keywords. - - -
- -
- -
- - The "$defs" keyword reserves a location for schema - authors to inline re-usable JSON Schemas into a more general schema. - The keyword does not directly affect the validation result. - - - This keyword's value MUST be an object. - Each member value of this object MUST be a valid JSON Schema. - - - As an example, here is a schema describing an array of positive - integers, where the positive integer constraint is a subschema in - "$defs": - - -
-
- -
- - This keyword reserves a location for comments from schema authors - to readers or maintainers of the schema. - - - The value of this keyword MUST be a string. Implementations MUST NOT present this - string to end users. Tools for editing schemas SHOULD support displaying and - editing this keyword. The value of this keyword MAY be used in debug or error - output which is intended for developers making use of schemas. - - - Schema vocabularies SHOULD allow "$comment" within any object containing - vocabulary keywords. Implementations MAY assume "$comment" is allowed - unless the vocabulary specifically forbids it. Vocabularies MUST NOT - specify any effect of "$comment" beyond what is described in this - specification. - - - Tools that translate other media types or programming languages - to and from application/schema+json MAY choose to convert that media type or - programming language's native comments to or from "$comment" values. - The behavior of such translation when both native comments and "$comment" - properties are present is implementation-dependent. - - - Implementations MAY strip "$comment" values at any point during processing. - In particular, this allows for shortening schemas when the size of deployed - schemas is a concern. - - - Implementations MUST NOT take any other action based on the presence, absence, - or contents of "$comment" properties. In particular, the value of "$comment" - MUST NOT be collected as an annotation result. - -
-
- -
- - -
-
- - RFC 3987 Section 6.5 and - RFC 3986 Section 5.1 defines how to determine the - default base IRI of a document. - - - Informatively, the initial base IRI of a schema is the IRI at which it was - found, whether that was a network location, a local filesystem, or any other - situation identifiable by a IRI of any known scheme. - - - If a schema document defines no explicit base IRI with "$id" - (embedded in content), the base IRI is that determined per - RFC 3987 Section 6.5 and - RFC 3986 section 5. - - - If no source is known, or no IRI scheme is known for the source, a suitable - implementation-specific default IRI MAY be used as described in - RFC 3987 Section 6.5 and - RFC 3986 Section 5.1.4. It is RECOMMENDED - that implementations document any default base IRI that they assume. - - - If a schema object is embedded in a document of another media type, then - the initial base IRI is determined according to the rules of that - media type. - - - Unless the "$id" keyword described in an earlier section is present in the - root schema, this base IRI SHOULD be considered the canonical IRI of the - schema document's root schema resource. - -
- -
- - The use of IRIs to identify remote schemas does not necessarily mean anything is downloaded, - but instead JSON Schema implementations SHOULD understand ahead of time which schemas they will be using, - and the IRIs that identify them. - - - When schemas are downloaded, - for example by a generic user-agent that does not know until runtime which schemas to download, - see Usage for Hypermedia. - - - Implementations SHOULD be able to associate arbitrary IRIs with an arbitrary - schema and/or automatically associate a schema's "$id"-given IRI, depending - on the trust that the validator has in the schema. Such IRIs and schemas - can be supplied to an implementation prior to processing instances, or may - be noted within a schema document as it is processed, producing associations - as shown in . - -
- -
- - Implementations MUST recognize a schema as a meta-schema if it - is being examined because it was identified as such by another - schema's "$schema" keyword. This means that a single schema - document might sometimes be considered a regular schema, and - other times be considered a meta-schema. - - - In the case of examining a schema which is its own meta-schema, - when an implementation begins processing it as a regular schema, - it is processed under those rules. However, when loaded a second - time as a result of checking its own "$schema" value, it is treated - as a meta-schema. So the same document is processed both ways in - the course of one session. - - - Implementations MAY allow a schema to be explicitly passed as a meta-schema, - for implementation-specific purposes, such as pre-loading a commonly - used meta-schema and checking its vocabulary support requirements - up front. Meta-schema authors MUST NOT expect such features to be - interoperable across implementations. - -
-
- -
- - Schemas can be identified by any IRI that has been given to them, including - a JSON Pointer or their IRI given directly by "$id". In all cases, - dereferencing a "$ref" reference involves first resolving its value as a - IRI reference against the current base IRI per - RFC 3986. - - - If the resulting IRI identifies a schema within the current document, or - within another schema document that has been made available to the implementation, - then that schema SHOULD be used automatically. - - - For example, consider this schema: - - - - - When an implementation encounters the <#/$defs/single> schema, - it resolves the "$anchor" value as a fragment name against the current - base IRI to form <https://example.net/root.json#item>. - - - When an implementation then looks inside the <#/items> schema, it - encounters the <#item> reference, and resolves this to - <https://example.net/root.json#item>, which it has seen defined in - this same document and can therefore use automatically. - - - When an implementation encounters the reference to "other.json", it resolves - this to <https://example.net/other.json>, which is not defined in this - document. If a schema with that identifier has otherwise been supplied to - the implementation, it can also be used automatically. - - What should implementations do when the referenced schema is not known? - Are there circumstances in which automatic network dereferencing is - allowed? A same origin policy? A user-configurable option? In the - case of an evolving API described by Hyper-Schema, it is expected that - new schemas will be added to the system dynamically, so placing an - absolute requirement of pre-loading schema documents is not feasible. - - - -
- - Since JSON Pointer IRI fragments are constructed based on the structure - of the schema document, an embedded schema resource and its subschemas - can be identified by JSON Pointer fragments relative to either its own - canonical IRI, or relative to any containing resource's IRI. - - - Conceptually, a set of linked schema resources should behave - identically whether each resource is a separate document connected with - schema references, or is structured as - a single document with one or more schema resources embedded as - subschemas. - - - Since IRIs involving JSON Pointer fragments relative to the parent - schema resource's IRI cease to be valid when the embedded schema - is moved to a separate document and referenced, applications and schemas - SHOULD NOT use such IRIs to identify embedded schema resources or - locations within them. - - - Consider the following schema document that contains another - schema resource embedded within it: - - - - The IRI "https://example.com/foo#/items" points to the "items" schema, - which is an embedded resource. The canonical IRI of that schema - resource, however, is "https://example.com/bar". - - - For the "additionalProperties" schema within that embedded resource, - the IRI "https://example.com/foo#/items/additionalProperties" points - to the correct object, but that object's IRI relative to its resource's - canonical IRI is "https://example.com/bar#/additionalProperties". - - - Now consider the following two schema resources linked by reference - using a IRI value for "$ref": - - - - - Here we see that "https://example.com/bar#/additionalProperties", - using a JSON Pointer fragment appended to the canonical IRI of - the "bar" schema resource, is still valid, while - "https://example.com/foo#/items/additionalProperties", which relied - on a JSON Pointer fragment appended to the canonical IRI of the - "foo" schema resource, no longer resolves to anything. - - - Note also that "https://example.com/foo#/items" is valid in both - arrangements, but resolves to a different value. This IRI ends up - functioning similarly to a retrieval IRI for a resource. While this IRI - is valid, it is more robust to use the "$id" of the embedded or referenced - resource unless it is specifically desired to identify the object containing - the "$ref" in the second (non-embedded) arrangement. - - - An implementation MAY choose not to support addressing schema resource - contents by IRIs using a base other than the resource's canonical IRI, - plus a JSON Pointer fragment relative to that base. Therefore, schema - authors SHOULD NOT rely on such IRIs, as using them may reduce interoperability. - - This is to avoid requiring implementations to keep track of a whole - stack of possible base IRIs and JSON Pointer fragments for each, - given that all but one will be fragile if the schema resources - are reorganized. Some - have argued that this is easy so there is - no point in forbidding it, while others have argued that it complicates - schema identification and should be forbidden. Feedback on this - topic is encouraged. - After some discussion, we feel that we need to remove the use of - "canonical" in favour of talking about JSON Pointers which reference - across schema resource boundaries as undefined or even forbidden behavior - (https://github.com/json-schema-org/json-schema-spec/issues/937, - https://github.com/json-schema-org/json-schema-spec/issues/1183) - - - - Further examples of such non-canonical IRI construction, as well as - the appropriate canonical IRI-based fragments to use instead, - are provided in . - -
-
- -
- - A Compound Schema Document is defined as a JSON document (sometimes called a "bundled" schema) - which has multiple embedded JSON Schema Resources bundled into the same document to - ease transportation. - - - Each embedded Schema Resource MUST be treated as an individual Schema Resource, following standard - schema loading and processing requirements, including determining vocabulary support. - -
- - The bundling process for creating a Compound Schema Document is defined as taking - references (such as "$ref") to an external Schema Resource and embedding the referenced - Schema Resources within the referring document. Bundling SHOULD be done in such a way that - all IRIs (used for referencing) in the base document and any referenced/embedded - documents do not require altering. - - - Each embedded JSON Schema Resource MUST identify itself with a IRI using the "$id" keyword, - and SHOULD make use of the "$schema" keyword to identify the dialect it is using, in the root of the - schema resource. It is RECOMMENDED that the IRI identifier value of "$id" be an Absolute IRI. - - - When the Schema Resource referenced by a by-reference applicator is bundled, it is RECOMMENDED that - the Schema Resource be located as a value of a "$defs" object at the containing schema's root. - The key of the "$defs" for the now embedded Schema Resource MAY be the "$id" of the bundled schema - or some other form of application defined unique identifer (such as a UUID). This key is not - intended to be referenced in JSON Schema, but may be used by an application to aid the - bundling process. - - - A Schema Resource MAY be embedded in a location other than "$defs" where the location is defined - as a schema value. - - - A Bundled Schema Resource MUST NOT be bundled by replacing the schema object from which it was - referenced, or by wrapping the Schema Resource in other applicator keywords. - - - In order to produce identical output, references in the containing schema document to the - previously external Schema Resources MUST NOT be changed, and now resolve to a schema using the - "$id" of an embedded Schema Resource. Such identical output includes validation evaluation and IRIs - or paths used in resulting annotations or errors. - - - While the bundling process will often be the main method for creating a Compound Schema Document, - it is also possible and expected that some will be created by hand, potentially without individual - Schema Resources existing on their own previously. - -
-
- - When multiple schema resources are present in a single document, - schema resources which do not define with which dialect they should be processed - MUST be processed with the same dialect as the enclosing resource. - - - Since any schema that can be referenced can also be embedded, embedded schema resources MAY - specify different processing dialects using the "$schema" values from their enclosing resource. - -
-
- - Given that a Compound Schema Document may have embedded resources which identify as using different - dialects, these documents SHOULD NOT be validated by applying a meta-schema - to the Compound Schema Document as an instance. It is RECOMMENDED that an alternate - validation process be provided in order to validate Schema Documents. Each Schema Resource - SHOULD be separately validated against its associated meta-schema. - - If you know a schema is what's being validated, you can identify if the schemas - is a Compound Schema Document or not, by way of use of "$id", which identifies an - embedded resource when used not at the document's root. - - - - A Compound Schema Document in which all embedded resources identify as using the same - dialect, or in which "$schema" is omitted and therefore defaults to that of the enclosing resource, - MAY be validated by applying the appropriate meta-schema. - -
-
- -
-
- - A schema MUST NOT be run into an infinite loop against an instance. For - example, if two schemas "#alice" and "#bob" both have an "allOf" property - that refers to the other, a naive validator might get stuck in an infinite - recursive loop trying to validate the instance. Schemas SHOULD NOT make - use of infinite recursive nesting like this; the behavior is undefined. - -
- -
- - Subschema objects (or booleans) are recognized by their use with known - applicator keywords or with location-reserving keywords such as - "$defs" that take one or more subschemas - as a value. These keywords may be "$defs" and the standard applicators - from this document, or extension keywords from a known vocabulary, or - implementation-specific custom keywords. - - - Multi-level structures of unknown keywords are capable of introducing - nested subschemas, which would be subject to the processing rules for - "$id". Therefore, having a reference target in such an unrecognized - structure cannot be reliably implemented, and the resulting behavior - is undefined. Similarly, a reference target under a known keyword, - for which the value is known not to be a schema, results in undefined - behavior in order to avoid burdening implementations with the need - to detect such targets. - - These scenarios are analogous to fetching a schema over HTTP - but receiving a response with a Content-Type other than - application/schema+json. An implementation can certainly - try to interpret it as a schema, but the origin server - offered no guarantee that it actually is any such thing. - Therefore, interpreting it as such has security implications - and may produce unpredictable results. - - - - Note that single-level custom keywords with identical syntax and - semantics to "$defs" do not allow for any intervening "$id" keywords, - and therefore will behave correctly under implementations that attempt - to use any reference target as a schema. However, this behavior is - implementation-specific and MUST NOT be relied upon for interoperability. - -
-
- -
- -
- - - JSON has been adopted widely by HTTP servers for automated APIs and robots. This - section describes how to enhance processing of JSON documents in a more RESTful - manner when used with protocols that support media types and - Web linking. - - -
- - It is RECOMMENDED that instances described by a schema provide a link to - a downloadable JSON Schema using the link relation "describedby", as defined by - Linked Data Protocol 1.0, section 8.1. - - - - In HTTP, such links can be attached to any response using the - Link header. An example of such a header would be: - - - ; rel="describedby" -]]> - -
- -
- - When used for hypermedia systems over a network, - HTTP is frequently the protocol of choice for - distributing schemas. Misbehaving clients can pose problems for server - maintainers if they pull a schema over the network more frequently than - necessary, when it's instead possible to cache a schema for a long period of - time. - - - HTTP servers SHOULD set long-lived caching headers on JSON Schemas. - HTTP clients SHOULD observe caching headers and not re-request documents within - their freshness period. - Distributed systems SHOULD make use of a shared cache and/or caching proxy. - - - Clients SHOULD set or prepend a User-Agent header specific to the JSON Schema - implementation or software product. Since symbols are listed in decreasing order - of significance, the JSON Schema library name/version should precede the more - generic HTTP library name (if any). For example: - - - - Clients SHOULD be able to make requests with a "From" header so that server - operators can contact the owner of a potentially misbehaving script. - -
- -
- -
- -
- -
- - This section defines a vocabulary of applicator keywords that - are RECOMMENDED for use as the basis of other vocabularies. - - - Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its IRI were present with a value of true. - - - The current IRI for this vocabulary, known as the Applicator vocabulary, is: - <https://json-schema.org/draft/next/vocab/applicator>. - - - The current IRI for the corresponding meta-schema is: - . - -
- - Schema keywords typically operate independently, without - affecting each other's outcomes. - - - For schema author convenience, there are some exceptions among the - keywords in this vocabulary: - -
    -
  • - "additionalProperties", whose behavior is defined in terms of - "properties" and "patternProperties" -
    • -
  • - "items", whose behavior is defined in terms of "prefixItems" -
    • -
  • - "contains", whose behavior is affected by the presence and value of - "minContains" -
    • -
-
- -
- - These keywords apply subschemas to the same location in the instance - as the parent schema is being applied. They allow combining - or modifying the subschema results in various ways. - - - - Subschemas of these keywords evaluate the instance completely independently - such that the results of one such subschema MUST NOT impact the results of sibling - subschemas. Therefore subschemas may be applied in - any order. - - -
- - These keywords correspond to logical operators for combining or modifying - the boolean assertion results of the subschemas. They have no direct - impact on annotation collection, although they enable the same annotation - keyword to be applied to an instance location with different values. - Annotation keywords define their own rules for combining such values. - -
- - This keyword's value MUST be a non-empty array. - Each item of the array MUST be a valid JSON Schema. - - - An instance validates successfully against this keyword if it validates - successfully against all schemas defined by this keyword's value. - -
- -
- - This keyword's value MUST be a non-empty array. - Each item of the array MUST be a valid JSON Schema. - - - An instance validates successfully against this keyword if it validates - successfully against at least one schema defined by this keyword's value. - Note that when annotations are being collected, all subschemas MUST - be examined so that annotations are collected from each subschema - that validates successfully. - -
- -
- - This keyword's value MUST be a non-empty array. - Each item of the array MUST be a valid JSON Schema. - - - An instance validates successfully against this keyword if it validates - successfully against exactly one schema defined by this keyword's value. - -
- -
- - This keyword's value MUST be a valid JSON Schema. - - - An instance is valid against this keyword if it fails to validate - successfully against the schema defined by this keyword. - -
-
- -
- - Three of these keywords work together to implement conditional - application of a subschema based on the outcome of another subschema. - The fourth is a shortcut for a specific conditional case. - - - "if", "then", and "else" MUST NOT interact with each other across - subschema boundaries. In other words, an "if" in one - branch of an "allOf" MUST NOT have an impact on a "then" - or "else" in another branch. - - - There is no default behavior for "if", "then", or "else" - when they are not present. In particular, they MUST NOT - be treated as if present with an empty schema, and when - "if" is not present, both "then" and "else" MUST be - entirely ignored. - -
- - This keyword's value MUST be a valid JSON Schema. - - - This validation outcome of this keyword's subschema - has no direct effect on the overall validation - result. Rather, it controls which of the "then" - or "else" keywords are evaluated. - - - Instances that successfully validate against this - keyword's subschema MUST also be valid against - the subschema value of the "then" keyword, if - present. - - - Instances that fail to validate against this - keyword's subschema MUST also be valid against - the subschema value of the "else" keyword, if - present. - - - If annotations - are being collected, they are collected from this - keyword's subschema in the usual way, including when - the keyword is present without either "then" or "else". - -
-
- - This keyword's value MUST be a valid JSON Schema. - - - When "if" is present, and the instance successfully - validates against its subschema, then validation - succeeds against this keyword if the instance also - successfully validates against this keyword's subschema. - - - This keyword has no effect when "if" is absent, or - when the instance fails to validate against its - subschema. Implementations MUST NOT evaluate - the instance against this keyword, for either validation - or annotation collection purposes, in such cases. - -
-
- - This keyword's value MUST be a valid JSON Schema. - - - When "if" is present, and the instance fails to - validate against its subschema, then validation - succeeds against this keyword if the instance - successfully validates against this keyword's subschema. - - - This keyword has no effect when "if" is absent, or - when the instance successfully validates against its - subschema. Implementations MUST NOT evaluate - the instance against this keyword, for either validation - or annotation collection purposes, in such cases. - -
-
- - This keyword specifies subschemas that are evaluated if the instance - is an object and contains a certain property. - - - This keyword's value MUST be an object. - Each value in the object MUST be a valid JSON Schema. - - - If the object key is a property in the instance, the entire - instance must validate against the subschema. Its use is - dependent on the presence of the property. - - - Omitting this keyword has the same behavior as an empty object. - -
-
- - This keyword specifies subschemas that are evaluated if the instance is - an object and contains a certain property with a certain string value. - - - This keyword's value MUST be an object. Each value in the object MUST be - an object whose values MUST be valid JSON Schemas. - - - If the outer object key is a property in the instance and the inner - object key is equal to the value of that property, the entire instance - must validate against the schema. Its use is dependent on the presence - and value of the property. - - - Omitting this keyword has the same behavior as an empty object. - -
-
-
-
- - Each of these keywords defines a rule for applying its - subschema(s) to child instances, specifically object - properties and array items, and combining their results. - -
-
- - The value of "prefixItems" MUST be a non-empty array of valid JSON Schemas. - - - Validation succeeds if each element of the instance validates - against the subschema at the same position, if any. This keyword - does not constrain the length of the array. Only array positions - present in both the keyword's value and the instance value are - affected by this keyword. - - - This keyword produces an annotation value which is the largest - index to which this keyword applied a subschema. The value - MAY be a boolean true if a subschema was applied to every - index of the instance, such as is produced by the "items" keyword. - This annotation affects the behavior of "items" and "unevaluatedItems". - - - Omitting this keyword has the same assertion behavior as - an empty array. - -
- -
- - The value of "items" MUST be a valid JSON Schema. - - - This keyword applies its subschema to all instance elements - at indexes greater than the length of the "prefixItems" array - in the same schema object, as reported by the annotation result - of that "prefixItems" keyword. If no such annotation - result exists, "items" applies its subschema to all instance - array elements. - - Note that the behavior of "items" without "prefixItems" is - identical to that of the schema form of "items" in prior drafts. - When "prefixItems" is present, the behavior of "items" is - identical to the former "additionalItems" keyword. - - - - If the "items" subschema is applied to any - positions within the instance array, it produces an - annotation result of boolean true, indicating that all remaining array - elements have been evaluated against this keyword's subschema. - This annotation affects the behavior of "unevaluatedItems" in the - Unevaluated vocabulary. - - - Omitting this keyword has the same assertion behavior as - an empty schema. - - - Implementations MAY choose to implement or optimize this keyword - in another way that produces the same effect, such as by directly - checking for the presence and size of a "prefixItems" array. - Implementations that do not support annotation collection MUST do so. - -
-
- -
-
- - The value of "properties" MUST be an object. - Each value of this object MUST be a valid JSON Schema. - - - Validation succeeds if, for each name that appears in both - the instance and as a name within this keyword's value, the child - instance for that name successfully validates against the - corresponding schema. - - - The annotation result of this keyword is the set of instance - property names which are also present under this keyword. - This annotation affects the behavior of "additionalProperties" (in - this vocabulary) and "unevaluatedProperties" in the Unevaluated vocabulary. - - - Omitting this keyword has the same assertion behavior as - an empty object. - -
- -
- - The value of "patternProperties" MUST be an object. Each property name - of this object SHOULD be a valid regular expression, according to the - ECMA-262 regular expression dialect. Each property value of this object - MUST be a valid JSON Schema. - - - Validation succeeds if, for each instance name that matches any - regular expressions that appear as a property name in this keyword's value, - the child instance for that name successfully validates against each - schema that corresponds to a matching regular expression. Recall: regular - expressions are not implicitly anchored. - - - The annotation result of this keyword is the set of instance - property names matched by at least one property under this keyword. - This annotation affects the behavior of "additionalProperties" (in this - vocabulary) and "unevaluatedProperties" (in the Unevaluated vocabulary). - - - Omitting this keyword has the same assertion behavior as - an empty object. - -
- -
- - The value of "additionalProperties" MUST be a valid JSON Schema. - - - The behavior of this keyword depends on the presence and - annotation results of "properties" and "patternProperties" - within the same schema object. - Validation with "additionalProperties" applies only to the child - values of instance names that do not appear in the annotation - results of either "properties" or "patternProperties". - - - For all such properties, validation succeeds if the child instance - validates against the "additionalProperties" schema. - - - The annotation result of this keyword is the set of instance - property names validated by this keyword's subschema. - This annotation affects the behavior of "unevaluatedProperties" - in the Unevaluated vocabulary. - - - Omitting this keyword has the same assertion behavior as - an empty schema. - - - Implementations MAY choose to implement or optimize this keyword - in another way that produces the same effect, such as by directly - checking the names in "properties" and the patterns in - "patternProperties" against the instance property set. - Implementations that do not support annotation collection MUST do so. - - In defining this option, it seems there is the potential for - ambiguity in the output format. The ambiguity does not affect validation results, - but it does affect the resulting output format. - The ambiguity allows for multiple valid output results depending on whether annotations - are used or a solution that "produces the same effect" as draft-07. It is understood - that annotations from failing schemas are dropped. - See our - [Decision Record](https://github.com/json-schema-org/json-schema-spec/tree/HEAD/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md) - for further details. - - -
- -
- - The value of "propertyNames" MUST be a valid JSON Schema. - - - If the instance is an object, this keyword validates if every property name in - the instance validates against the provided schema. - Note the property name that the schema is testing will always be a string. - - - Omitting this keyword has the same behavior as an empty schema. - -
-
- -
-
- - The value of this keyword MUST be a non-negative integer. - - - This keyword modifies the behavior of "contains" within the same schema object, - as described below in the section for that keyword. - - - Validation MUST always succeed against this keyword. - The value of this keyword is used as its annotation result. - -
- -
- - The value of this keyword MUST be a non-negative integer. - - - This keyword modifies the behavior of "contains" within the same schema object, - as described below in the section for that keyword. - - - Validation MUST always succeed against this keyword. - The value of this keyword is used as its annotation result. - - Per , - omitted keywords MUST NOT produce annotation results. However, as described - in the section for "contains", the absence of this keyword's annotation - causes "contains" to assume a minimum value of 1. - -
- -
- - The value of this keyword MUST be a valid JSON Schema. - - - This keyword applies its subschema to array elements or object property values. - - - An instance is valid against "contains" if the number of elements or property - values that are valid against its subschema is with the inclusive range of - the minimum and (if any) maximum number of occurrences. - - - The maximum number of occurrences is provided by the "maxContains" keyword - within the same schema object as "contains". If "maxContains" is absent, - the maximum number of occurrences MUST be unbounded. - - - The minimum number of occurrences is provided by the "minContains" keyword - within the same schema object as "contains". If "minContains" is absent, - the minimum number of occurrences MUST be 1. - - - Implementations MAY implement the dependency on "minContians" and - "maxContains" by inspecting their values rather than reading annotations - produced by those keywords. - - - This keyword produces an annotation value which is an array of the - indexes or property names to which this keyword validates successfully - when applying its subschema, in ascending order. The value MAY be a - boolean "true" if the subschema validates successfully when applied to - every index or property value of the instance. The annotation MUST be - present if the instance array or object to which this keyword's schema - applies is empty. - - - This annotation affects the behavior of "unevaluatedItems" in the - Unevaluated vocabulary. - - - The subschema MUST be applied to every array element or object property - value even after the first match has been found, in order to collect - annotations for use by other keywords. This is to ensure that all possible - annotations are collected. - -
-
-
-
- -
- - The purpose of these keywords is to enable schema authors to apply - subschemas to array items or object properties that have not been - successfully evaluated against any dynamic-scope subschema of any - adjacent keywords. - - - These instance items or properties may have been unsuccessfully evaluated - against one or more adjacent keyword subschemas, such as when an assertion - in a branch of an "anyOf" fails. Such failed evaluations are not considered - to contribute to whether or not the item or property has been evaluated. - Only successful evaluations are considered. - - - If an item in an array or an object property is "successfully evaluated", it - is logically considered to be valid in terms of the representation of the - object or array that's expected. For example if a subschema represents a car, - which requires between 2-4 wheels, and the value of "wheels" is 6, the instance - object is not "evaluated" to be a car, and the "wheels" property is considered - "unevaluated (successfully as a known thing)", and does not retain any annotations. - - - Recall that adjacent keywords are keywords within the same schema object, - and that the dynamic-scope subschemas include reference targets as well as - lexical subschemas. - - - The behavior of these keywords depend on the annotation results of - adjacent keywords that apply to the instance location being validated. - - - Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its IRI were present with a value of true. - - - The current IRI for this vocabulary, known as the Unevaluated Applicator - vocabulary, is: - <https://json-schema.org/draft/next/vocab/unevaluated>. - - - The current IRI for the corresponding meta-schema is: - . - - -
- - Schema keywords typically operate independently, without - affecting each other's outcomes. However, the keywords in this - vocabulary are notable exceptions: - -
    -
  • - "unevaluatedItems", whose behavior is defined in terms of annotations - from "prefixItems", "items", "contains", and itself -
    • -
  • - "unevaluatedProperties", whose behavior is defined in terms of - annotations from "properties", "patternProperties", - "additionalProperties", "contains", and itself -
    • -
-
- -
- - The value of "unevaluatedItems" MUST be a valid JSON Schema. - - - The behavior of this keyword depends on the annotation results of - adjacent keywords that apply to the instance location being validated. - Specifically, the annotations from "prefixItems", "items", and "contains", - which can come from those keywords when they are adjacent to the - "unevaluatedItems" keyword. Those three annotations, as well as - "unevaluatedItems", can also result from any and all adjacent - in-place applicator keywords. - This includes but is not limited to the in-place applicators - defined in this document. - - - If no relevant annotations are present, the "unevaluatedItems" - subschema MUST be applied to all locations in the array. - If a boolean true value is present from any of the relevant annotations, - "unevaluatedItems" MUST be ignored. Otherwise, the subschema - MUST be applied to any index greater than the largest annotation - value for "prefixItems", which does not appear in any annotation - value for "contains". - - - This means that "prefixItems", "items", "contains", and all in-place - applicators MUST be evaluated before this keyword can be evaluated. - Authors of extension keywords MUST NOT define an in-place applicator - that would need to be evaluated after this keyword. - - - If the "unevaluatedItems" subschema is applied to any - positions within the instance array, it produces an - annotation result of boolean true, analogous to the - behavior of "items". - This annotation affects the behavior of "unevaluatedItems" in parent schemas. - - - Omitting this keyword has the same assertion behavior as - an empty schema. - -
- -
- - The value of "unevaluatedProperties" MUST be a valid JSON Schema. - - - The behavior of this keyword depends on the annotation results of - adjacent keywords that apply to the instance location being validated. - Specifically, the annotations from "properties", "patternProperties", - "contains", and "additionalProperties", which can come from those keywords when - they are adjacent to the "unevaluatedProperties" keyword. Those - four annotations, as well as "unevaluatedProperties", can also - result from any and all adjacent - in-place applicator keywords. - This includes but is not limited to the in-place applicators - defined in this document. - - - Validation with "unevaluatedProperties" applies only to the child - values of instance names that do not appear in the "properties", - "patternProperties", "additionalProperties", "contains", or - "unevaluatedProperties" annotation results that apply to the - instance location being validated. - - - For all such properties, validation succeeds if the child instance - validates against the "unevaluatedProperties" schema. - - - This means that "properties", "patternProperties", "additionalProperties", - "contains" and all in-place applicators MUST be evaluated before this keyword can - be evaluated. Authors of extension keywords MUST NOT define an in-place - applicator that would need to be evaluated after this keyword. - - - The annotation result of this keyword is the set of instance - property names validated by this keyword's subschema. - This annotation affects the behavior of "unevaluatedProperties" in parent schemas. - - - Omitting this keyword has the same assertion behavior as - an empty schema. - -
-
- -
- - JSON Schema is defined to be platform-independent. As such, to increase compatibility - across platforms, implementations SHOULD conform to a standard validation output - format. This section describes the minimum requirements that consumers will need to - properly interpret validation results. - - -
- - JSON Schema output is defined using the JSON Schema data instance model as described - in section 4.2.1. Implementations MAY deviate from this as supported by their - specific languages and platforms, however it is RECOMMENDED that the output be - convertible to the JSON format defined herein via serialization or other means. - -
- -
- - This specification defines three output formats. See the "Output Structure" - section for the requirements of each format. - -
-
Flag
-
- A boolean which simply indicates the overall validation result - with no further details. -
-
List
-
- Provides validation information in a flat list structure. -
-
Hierarchical
-
- Provides validation information in a hierarchical - structure that follows the evaluation paths generated while processing - the schema. -
-
- - An implementation MUST provide the "flag" format and SHOULD provide at least one - of the "list" or "hierarchical" formats. Implementations SHOULD specify in - their documentation which formats they support. - - -
- -
- - Beyond the simplistic "flag" output, additional information is useful to aid in - debugging a schema or instance. Each sub-result SHOULD contain the information - contained within this section at a minimum. - - - A single object that contains all of these components is considered an - output unit. - - - Implementations MAY elect to provide additional information. - - -
- - The evaluation path to the schema object that produced the output unit. - The value MUST be expressed as a JSON Pointer, and it MUST include any - by-reference applicators such as "$ref" or "$dynamicRef". - - The schema may not actually have a value at the location indicated - by this pointer. It is provided as an indication of the traversal - path only. - - - - - Note that this pointer may not be resolvable by the normal JSON Pointer process - due to the inclusion of these by-reference applicator keywords. - - - The JSON key for this information is "evaluationPath". - -
- -
- - The absolute, dereferenced location of the schema object that produced - the output unit. The value MUST be expressed using the canonical IRI of the - relevant schema resource plus a JSON Pointer fragment that indicates the schema - object that produced the output. It MUST NOT include by-reference applicators - such as "$ref" or "$dynamicRef". - - Note that "absolute" here is in the sense of "absolute filesystem path" - (meaning the complete location) rather than the "absolute-IRI" - terminology from RFC 3987 (meaning with scheme and without fragment). - Schema locations will have a fragment in order to identify the specific - schema object. - - - - - - The JSON key for this information is "schemaLocation". - -
- -
- - The location of the JSON value within the instance being validated. The - value MUST be expressed as a JSON Pointer. - - - The JSON key for this information is "instanceLocation". - -
- -
- - Any errors produced by the validation. This property MUST NOT - be included if the validation was successful. The value - for this property MUST be an object where the keys are the names of - keywords and the values are the error message produced by the - associated keyword. - - - If the subschema itself is producing the error, that error MUST be - listed with an empty string key. - - Although there may be other cases where a subschema can produce - an error, the most common case is the "false" schema. In - cases like these, there is no keyword that produces the error, - so there is nothing to use as a key. Thus the empty string - is used instead. - - - - The specific wording for the message is not defined by this - specification. Implementations will need to provide this. - - - The JSON key for this information is "errors". - -
- -
- - Any annotations produced by the evaluation. This property MUST NOT - be included if the validation result of the containing subschema was - unsuccessful. - - - The value for this property MUST be an object where the - keys are the names of keywords and the values are the annotations - produced by the associated keyword. - - - Each keyword defines its own annotation data type (e.g. "properties" - produces a list of keywords, whereas "title" produces a string). - - - The JSON key for this information is "annotations". - -
- -
- - Any annotations produced and subsequently dropped by the evaluation - due to an unsuccessful validation result of the containing subschema. - This property MAY be included if the validation result of the containing - subschema was unsuccessful. It MUST NOT be included if the local - validation result of the containing subschema was successful. - - - Implementations that wish to provide these annotations MUST NOT provide - them as their default behavior. These annotations MUST only be included - by explicitly configuring the implementation to do so. - - - The value for this property MUST be an object where the - keys are the names of keywords and the values are the annotations - produced by the associated keyword. - - - Each keyword defines its own annotation data type (e.g. "properties" - produces a list of keywords, whereas "title" produces a string). - - - The JSON key for this information is "droppedAnnotations". - -
- -
- - Evaluation results generated by applying a subschema to the instance - or a child of the instance. - Keywords which have multiple subschemas (e.g. "anyOf") will generally - generate an output unit for each subschema. In order to accommodate - potentially multiple results, the value of this property MUST be an - array of output units, even if only a single output unit is produced. - - - For "list", this property will appear only at the root output unit - and will hold all output units in a flat list. - - - For "hierarchical", this property will contain results in a tree - structure where each output unit may itself have further nested results. - - - The sequence of output units within this list is not specified and - MAY be determined by the implementation. Sets of output units are - considered equivalent if they contain the same units, in any order. - - - The JSON key for these additional results is "details". - -
- -
- -
- - The output MUST be an object containing a boolean property named "valid". When - additional information about the result is required, the output MUST also contain - "details" as described below. - -
-
valid
-
a boolean value indicating the overall validation success or failure
- -
details
-
the collection of results produced by subschemas
-
- - For these examples, the following schema and instances will be used. - - - - The failing instance will produce the following errors: - -
    -
  • - The value at "/foo" - evaluated at "/properties/foo/allOf/0" - by following the path "/properties/foo/allOf/0" - by the "required" keyword - is missing the property "unspecified-prop". -
    • -
  • - The value at "/foo/foo-prop" - evaluated at "/properties/foo/allOf/1/properties/foo-prop" - by following the path "/properties/foo/allOf/1/properties/foo-prop" - by the "const" keyword - is not the constant value 1. -
    • -
  • - The value at "/bar/bar-prop" - evaluated at "/$defs/bar/properties/bar-prop" - by following the path "/properties/bar/$ref/properties/bar-prop" - by the "type" keyword - is not a number. -
    • -
- - - "minimum" doesn't produce an error because it only operates on - instances that are numbers. - - - Note that the error message wording as depicted in the examples below is not a - requirement of this specification. Implementations SHOULD craft error messages - tailored for their audience or provide a templating mechanism that allows their - users to craft their own messages. - - - - The passing instance will produce the following annotations: - -
    -
  • - The keyword "title" - evaluated at "" - by following the path "" - will produce "root". -
    • -
  • - The keyword "properties" - evaluated at "" - by following the path "" - will produce ["foo", "bar"]. -
    • -
  • - The keyword "title" - evaluated at "/properties/foo" - by following the path "/properties/foo" - will produce "foo-title". -
    • -
  • - The keyword "properties" - evaluated at "/properties/foo/allOf/1" - by following the path "/properties/foo/allOf/1" - will produce ["foo-prop"]. -
    • -
  • - The keyword "additionalProperties" - evaluated at "/properties/foo/allOf/1" - by following the path "/properties/foo/allOf/1" - will produce ["unspecified-prop"]. -
    • -
  • - The keyword "title" - evaluated at "/properties/foo/allOf/1/properties/foo-prop" - by following the path "/properties/foo/allOf/1/properties/foo-prop" - will produce "foo-prop-title". -
    • -
  • - The keyword "title" - evaluated at "/$defs/bar" - by following the path "/properties/bar/$ref" - will produce "bar-title". -
    • -
  • - The keyword "properties" - evaluated at "/$defs/bar" - by following the path "/properties/var/$ref" - will produce ["bar-prop"]. -
    • -
  • - The keyword "title" - evaluated at "/$defs/bar/properties/bar-prop" - by following the path "/properties/bar/$ref/properties/bar-prop" - will produce "bar-prop-title". -
    • -
- -
- - In the simplest case, merely the boolean result for the "valid" valid property - needs to be fulfilled. For this format, all other information is explicitly - omitted. - - - - Because no errors or annotations are returned with this format, it is - RECOMMENDED that implementations use short-circuiting logic to return - failure or success as soon as the outcome can be determined. For example, - if an "anyOf" keyword contains five subschemas, and the second one - passes, there is no need to check the other three. The logic can simply - return with success. - -
- -
- - The "List" structure is a flat list of output units contained within a - root output unit. - - - The root output unit contains "valid" for the overall result and "details" - for the list of specific results. All other information is explicitly - omitted from the root output unit. If the root schema produces errors or - annotations, then the output node for the root MUST be present within the - root output unit's "details" list with those errors or annotations. - - - Output units which do not contain errors or annotations SHOULD be excluded - from this format, however implementations MAY choose to include them for - completeness. - - -
- -
- - The "Hierarchical" structure is a tree structure that follows the - evaluation path during the validation process. Typically, it will - resemble the schema as if all referenced schemas were inlined in place - of their associated by-reference keywords. - - - All output units are included in this format. - - - The location properties of the root output unit MAY be omitted. - - - -
- -
- - For convenience, JSON Schema has been provided to validate output generated - by implementations. Its IRI is: - . - -
- -
- -
- -
- - Both schemas and instances are JSON values. As such, all security considerations - defined in RFC 8259 apply. - - - Instances and schemas are both frequently written by untrusted third parties, to be - deployed on public Internet servers. - Implementations should take care that the parsing and evaluating against schemas - does not consume excessive system resources. - Implementations MUST NOT fall into an infinite loop. - - - A malicious party could cause an implementation to repeatedly collect a copy - of a very large value as an annotation. Implementations SHOULD guard against - excessive consumption of system resources in such a scenario. - - - Servers MUST ensure that malicious parties cannot change the functionality of - existing schemas by uploading a schema with a pre-existing or very similar "$id". - - - Individual JSON Schema vocabularies are liable to also have their own security - considerations. Consult the respective specifications for more information. - - - Schema authors should take care with "$comment" contents, as a malicious - implementation can display them to end-users in violation of a spec, or - fail to strip them if such behavior is expected. - - - A malicious schema author could place executable code or other dangerous - material within a "$comment". Implementations MUST NOT parse or otherwise - take action based on "$comment" contents. - -
- -
-
- - The proposed MIME media type for JSON Schema is defined as follows: - -
-
Type name:
-
application
- -
Subtype name:
-
schema+json
- -
Required parameters:
-
N/A
- -
Encoding considerations:
-
- Encoding considerations are - identical to those specified for the "application/json" - media type. See JSON. -
- -
Security considerations:
-
See above.
- -
Interoperability considerations:
-
- See Sections - , - , and - above. -
- -
Fragment identifier considerations:
-
- See -
-
-
-
- - The proposed MIME media type for JSON Schema Instances that require - a JSON Schema-specific media type is defined as follows: - -
-
Type name:
-
application
- -
Subtype name:
-
schema-instance+json
- -
Required parameters:
-
N/A
- -
Encoding considerations:
-
- Encoding considerations are - identical to those specified for the "application/json" - media type. See JSON. -
- -
Security considerations:
-
See above.
- -
Interoperability considerations:
-
- See Sections - , - , and - above. -
- -
Fragment identifier considerations:
-
See
-
-
-
- - - - - - &RFC2119; - &RFC3986; - &RFC3987; - &RFC6839; - &RFC6901; - &RFC8259; - &ldp; - - - ECMA-262, 11th edition specification - - - - - - - - &RFC6596; - &RFC7049; - &RFC7231; - &RFC8288; - &fragid-best-practices; - &xptr-framework; - - - JSON Schema Validation: A Vocabulary for Structural Validation of JSON - - - - - - - - - - - - - - - - JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON - - - - - - - - - - - - - Namespaces in XML 1.1 (Second Edition) - - Textuality -
- tbray@textuality.com -
- - - Contivo, Inc. -
- dmh@contivo.com -
- - - Microsoft -
- andrewl@microsoft.com -
- - - University of Edinburgh and Markup Technology Ltd -
- richard@cogsci.ed.ac.uk -
- - - - - - -
- - Consider the following schema, which shows "$id" being used to identify - both the root schema and various subschemas, and "$anchor" being used - to define plain name fragment identifiers. - - - - The schemas at the following IRI-encoded JSON - Pointers (relative to the root schema) have the following - base IRIs, and are identifiable by any listed IRI in accordance with - and above. - -
-
# (document root)
-
-
-
canonical (and base) IRI"
-
https://example.com/root.json
- -
canonical resource IRI plus pointer fragment"
-
https://example.com/root.json#
-
-
- -
#/$defs/A
-
-
-
base IRI
-
https://example.com/root.json
- -
canonical resource IRI plus plain fragment
-
https://example.com/root.json#foo
- -
canonical resource IRI plus pointer fragment
-
https://example.com/root.json#/$defs/A
-
-
- -
#/$defs/B
-
-
-
canonical (and base) IRI
-
https://example.com/other.json
- -
canonical resource IRI plus pointer fragment
-
https://example.com/other.json#
- -
base IRI of enclosing (root.json) resource plus fragment
-
https://example.com/root.json#/$defs/B
-
-
- -
#/$defs/B/$defs/X
-
-
-
base IRI
-
https://example.com/other.json
- -
canonical resource IRI plus plain fragment
-
https://example.com/other.json#bar
- -
canonical resource IRI plus pointer fragment
-
https://example.com/other.json#/$defs/X
- -
base IRI of enclosing (root.json) resource plus fragment
-
https://example.com/root.json#/$defs/B/$defs/X
-
-
- -
#/$defs/B/$defs/Y
-
-
-
canonical (and base) IRI
-
https://example.com/t/inner.json
- -
canonical IRI plus plain fragment
-
https://example.com/t/inner.json#bar
- -
canonical IRI plus pointer fragment
-
https://example.com/t/inner.json#
- -
base IRI of enclosing (other.json) resource plus fragment
-
https://example.com/other.json#/$defs/Y
- -
base IRI of enclosing (root.json) resource plus fragment
-
https://example.com/root.json#/$defs/B/$defs/Y
-
-
- -
#/$defs/C
-
-
-
canonical (and base) IRI
-
urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f
- -
canonical IRI plus pointer fragment
-
urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f#
- -
base IRI of enclosing (root.json) resource plus fragment
-
https://example.com/root.json#/$defs/C
-
-
-
- - Note: The fragment part of the IRI does not make it canonical or non-canonical, - rather, the base IRI used (as part of the full IRI with any fragment) is what - determines the canonical nature of the resulting full IRI. - - Multiple "canonical" IRIs? We Acknowledge this is potentially confusing, and - direct you to read the CREF located in the - JSON Pointer fragments and embedded schema resources - section for futher comments. - - - -
- -
- - Various tools have been created to rearrange schema documents - based on how and where references ("$ref") appear. This appendix discusses - which use cases and actions are compliant with this specification. - -
- - A set of schema resources intended for use together can be organized - with each in its own schema document, all in the same schema document, - or any granularity of document grouping in between. - - - Numerous tools exist to perform various sorts of reference removal. - A common case of this is producing a single file where all references - can be resolved within that file. This is typically done to simplify - distribution, or to simplify coding so that various invocations - of JSON Schema libraries do not have to keep track of and load - a large number of resources. - - - This transformation can be safely and reversibly done as long as - all static references (e.g. "$ref") use IRI-references that resolve - to IRIs using the canonical resource IRI as the base, and all schema - resources have an absolute-IRI as the "$id" in their root schema. - - - With these conditions met, each external resource can be copied - under "$defs", without breaking any references among the resources' - schema objects, and without changing any aspect of validation or - annotation results. The names of the schemas under "$defs" do - not affect behavior, assuming they are each unique, as they - do not appear in the canonical IRIs for the embedded resources. - -
-
- - Attempting to remove all references and produce a single schema document does not, - in all cases, produce a schema with identical behavior to the original form. - - - Since "$ref" is now treated like any other keyword, with other keywords allowed - in the same schema objects, fully supporting non-recursive "$ref" removal in - all cases can require relatively complex schema manipulations. It is beyond - the scope of this specification to determine or provide a set of safe "$ref" - removal transformations, as they depend not only on the schema structure - but also on the intended usage. - -
-
- -
- - Consider the following two schemas describing a simple - recursive tree structure, where each node in the tree - can have a "data" field of any type. The first schema - allows and ignores other instance properties. The second is - more strict and only allows the "data" and "children" properties. - An example instance with "data" misspelled as "daat" is also shown. - - - - When we load these two schemas, we will notice the "$dynamicAnchor" - named "node" (note the lack of "#" as this is just the name) - present in each, resulting in the following full schema IRIs: -
    -
  • "https://example.com/tree#node"
    • -
  • "https://example.com/strict-tree#node"
    • -
- In addition, JSON Schema implementations keep track of the fact - that these fragments were created with "$dynamicAnchor". - - - If we apply the "strict-tree" schema to the instance, we will follow - the "$ref" to the "tree" schema, examine its "children" subschema, - and find the "$dynamicRef": to "#node" (note the "#" for IRI fragment syntax) - in its "items" subschema. That reference resolves to - "https://example.com/tree#node", which is a IRI with a fragment - created by "$dynamicAnchor". Therefore we must examine the dynamic - scope before following the reference. - - - At this point, the evaluation path is - "#/$ref/properties/children/items/$dynamicRef", with a dynamic scope - containing (from the outermost scope to the innermost): -
    -
  1. "https://example.com/strict-tree#"
    2. -
  2. "https://example.com/tree#"
    3. -
  3. "https://example.com/tree#/properties/children"
    4. -
  4. "https://example.com/tree#/properties/children/items"
    5. -
- - - Since we are looking for a plain name fragment, which can be - defined anywhere within a schema resource, the JSON Pointer fragments - are irrelevant to this check. That means that we can remove those - fragments and eliminate consecutive duplicates, producing: -
    -
  1. "https://example.com/strict-tree"
    2. -
  2. "https://example.com/tree"
    3. -
- - - In this case, the outermost resource also has a "node" fragment - defined by "$dynamicAnchor". Therefore instead of resolving the - "$dynamicRef" to "https://example.com/tree#node", we resolve it to - "https://example.com/strict-tree#node". - - - This way, the recursion in the "tree" schema recurses to the root - of "strict-tree", instead of only applying "strict-tree" to the - instance root, but applying "tree" to instance children. - - - This example shows both "$dynamicAnchor"s in the same place - in each schema, specifically the resource root schema. - Since plain-name fragments are independent of the JSON structure, - this would work just as well if one or both of the node schema objects - were moved under "$defs". It is the matching "$dynamicAnchor" values - which tell us how to resolve the dynamic reference, not any sort of - correlation in JSON structure. - -
- -
-
- - Vocabulary authors should - take care to avoid keyword name collisions if the vocabulary is intended - for broad use, and potentially combined with other vocabularies. JSON - Schema does not provide any formal namespacing system, but also does - not constrain keyword names, allowing for any number of namespacing - approaches. - - - Vocabularies may build on each other, such as by defining the behavior - of their keywords with respect to the behavior of keywords from another - vocabulary, or by using a keyword from another vocabulary with - a restricted or expanded set of acceptable values. Not all such - vocabulary re-use will result in a new vocabulary that is compatible - with the vocabulary on which it is built. Vocabulary authors should - clearly document what level of compatibility, if any, is expected. - - - Meta-schema authors should not use "$vocabulary" to combine multiple - vocabularies that define conflicting syntax or semantics for the same - keyword. As semantic conflicts are not generally detectable through - schema validation, implementations are not expected to detect such - conflicts. If conflicting vocabularies are declared, the resulting - behavior is undefined. - - - Vocabulary authors SHOULD provide a meta-schema that validates the - expected usage of the vocabulary's keywords on their own. Such meta-schemas - SHOULD not forbid additional keywords, and MUST not forbid any - keywords from the Core vocabulary. - - - It is recommended that meta-schema authors reference each vocabulary's - meta-schema using the "allOf" keyword, - although other mechanisms for constructing the meta-schema may be - appropriate for certain use cases. - - - The recursive nature of meta-schemas makes the "$dynamicAnchor" - and "$dynamicRef" keywords particularly useful for extending - existing meta-schemas, as can be seen in the JSON Hyper-Schema meta-schema - which extends the Validation meta-schema. - - - Meta-schemas may impose additional constraints, including describing - keywords not present in any vocabulary, beyond what the meta-schemas - associated with the declared vocabularies describe. This allows for - restricting usage to a subset of a vocabulary, and for validating - locally defined keywords not intended for re-use. - - - However, meta-schemas should not contradict any vocabularies that - they declare, such as by requiring a different JSON type than - the vocabulary expects. The resulting behavior is undefined. - - - Meta-schemas intended for local use, with no need to test for - vocabulary support in arbitrary implementations, can safely omit - "$vocabulary" entirely. - -
- -
- - This meta-schema explicitly declares both the Core and Applicator vocabularies, - together with an extension vocabulary, and combines their meta-schemas with - an "allOf". The extension vocabulary's meta-schema, which describes only the - keywords in that vocabulary, is shown after the main example meta-schema. - - - The main example meta-schema also restricts the usage of the Unevaluated - vocabulary by forbidding the keywords prefixed with "unevaluated", which - are particularly complex to implement. This does not change the semantics - or set of keywords defined by the other vocabularies. It just ensures - that schemas using this meta-schema that attempt to use the keywords - prefixed with "unevaluated" will fail validation against this meta-schema. - - - Finally, this meta-schema describes the syntax of a keyword, "localKeyword", - that is not part of any vocabulary. Presumably, the implementors and users - of this meta-schema will understand the semantics of "localKeyword". - JSON Schema does not define any mechanism for expressing keyword semantics - outside of vocabularies, making them unsuitable for use except in a - specific environment in which they are understood. - - - This meta-schema combines several vocabularies for general use. - - - - This meta-schema describes only a single extension vocabulary. - - - - As shown above, even though each of the single-vocabulary meta-schemas - referenced in the general-use meta-schema's "allOf" declares its - corresponding vocabulary, this new meta-schema must re-declare them. - - - The standard meta-schemas that combine all vocabularies defined by - the Core and Validation specification, and that combine all vocabularies - defined by those specifications as well as the Hyper-Schema specification, - demonstrate additional complex combinations. These IRIs for these - meta-schemas may be found in the Validation and Hyper-Schema specifications, - respectively. - - - While the general-use meta-schema can validate the syntax of "minDate", - it is the vocabulary that defines the logic behind the semantic meaning - of "minDate". Without an understanding of the semantics (in this example, - that the instance value must be a date equal to or after the date - provided as the keyword's value in the schema), an implementation can - only validate the syntactic usage. In this case, that means validating - that it is a date-formatted string (using "pattern" to ensure that it is - validated even when "format" functions purely as an annotation, as explained - in the Validation specification. - -
-
- -
- - While the presence of references is expected to be transparent - to validation results, generative use cases such as code generators - and UI renderers often consider references to be semantically significant. - - - To make such use case-specific semantics explicit, the best practice - is to create an annotation keyword for use in the same - schema object alongside of a reference keyword such as "$ref". - - - For example, here is a hypothetical keyword for determining - whether a code generator should consider the reference - target to be a distinct class, and how those classes are related. - Note that this example is solely for illustrative purposes, and is - not intended to propose a functional code generation keyword. - - - - Here, this schema represents some sort of object-oriented class. - The first reference in the "allOf" is noted as the base class. - The second is not assigned a class relationship, meaning that the - code generator should combine the target's definition with this - one as if no reference were involved. - - - Looking at the properties, "foo" is flagged as object composition, - while the "date" property is not. It is simply a field with - sub-fields, rather than an instance of a distinct class. - - - This style of usage requires the annotation to be in the same object - as the reference, which must be recognizable as a reference. - -
- -
- - Thanks to - Gary Court, - Francis Galiegue, - Kris Zyp, - Geraint Luff, - and Henry Andrews - for their work on the initial drafts of JSON Schema. - - - Thanks to - Jason Desrosiers, - Daniel Perrett, - Erik Wilde, - Evgeny Poberezkin, - Brad Bowman, - Gowry Sankar, - Donald Pipowitch, - Dave Finlay, - Denis Laxalde, - Phil Sturgeon, - Shawn Silverman, - and Karen Etheridge - for their submissions and patches to the document. - -
- -
- - This section to be removed before leaving Internet-Draft status. - - -
-
    -
  • "contains" now applies to objects as well as arrays
    • -
  • Use IRIs instead of URIs
    • -
  • Remove bookending requirement for "$dynamicRef"
    • -
  • Add "propertyDependencies" keyword
    • -
-
- -
-
    -
  • Improve and clarify the "type", "contains", "unevaluatedProperties", and "unevaluatedItems" keyword explanations
    • -
  • Clarify various aspects of "canonical URIs"
    • -
  • Comment on ambiguity around annotations and "additionalProperties"
    • -
  • Clarify Vocabularies need not be formally defined
    • -
  • Remove references to remaining media-type parameters
    • -
  • Fix multiple examples
    • -
-
- -
-
    -
  • "$schema" MAY change for embedded resources
    • -
  • Array-value "items" functionality is now "prefixItems"
    • -
  • "items" subsumes the old function of "additionalItems"
    • -
  • "contains" annotation behavior, and "contains" and "unevaluatedItems" interactions now specified
    • -
  • Rename $recursive* to $dynamic*, with behavior modification
    • -
  • $dynamicAnchor defines a fragment like $anchor
    • -
  • $dynamic* (previously $recursive) no longer use runtime base URI determination
    • -
  • Define Compound Schema Documents (bundle) and processing
    • -
  • Reference ECMA-262, 11th edition for regular expression support
    • -
  • Regular expression should support unicode
    • -
  • Remove media type parameters
    • -
  • Specify Unknown keywords are collected as annotations
    • -
  • Moved "unevaluatedItems" and "unevaluatedProperties" from core into their own vocabulary
    • -
-
- -
-
    -
  • Update to RFC 8259 for JSON specification
    • -
  • Moved "definitions" from the Validation specification here as "$defs"
    • -
  • Moved applicator keywords from the Validation specification as their own vocabulary
    • -
  • Moved the schema form of "dependencies" from the Validation specification as "dependentSchemas"
    • -
  • Formalized annotation collection
    • -
  • Specified recommended output formats
    • -
  • Defined keyword interactions in terms of annotation and assertion results
    • -
  • Added "unevaluatedProperties" and "unevaluatedItems"
    • -
  • Define "$ref" behavior in terms of the assertion, applicator, and annotation model
    • -
  • Allow keywords adjacent to "$ref"
    • -
  • Note undefined behavior for "$ref" targets involving unknown keywords
    • -
  • Add recursive referencing, primarily for meta-schema extension
    • -
  • Add the concept of formal vocabularies, and how they can be recognized through meta-schemas
    • -
  • Additional guidance on initial base URIs beyond network retrieval
    • -
  • Allow "schema" media type parameter for "application/schema+json"
    • -
  • Better explanation of media type parameters and the HTTP Accept header
    • -
  • Use "$id" to establish canonical and base absolute-URIs only, no fragments
    • -
  • Replace plain-name-fragment-only form of "$id" with "$anchor"
    • -
  • Clarified that the behavior of JSON Pointers across "$id" boundary is unreliable
    • -
-
- -
-
    -
  • This draft is purely a clarification with no functional changes
    • -
  • Emphasized annotations as a primary usage of JSON Schema
    • -
  • Clarified $id by use cases
    • -
  • Exhaustive schema identification examples
    • -
  • Replaced "external referencing" with how and when an implementation might know of a schema from another document
    • -
  • Replaced "internal referencing" with how an implementation should recognized schema identifiers during parsing
    • -
  • Dereferencing the former "internal" or "external" references is always the same process
    • -
  • Minor formatting improvements
    • -
-
- -
-
    -
  • Make the concept of a schema keyword vocabulary more clear
    • -
  • Note that the concept of "integer" is from a vocabulary, not the data model
    • -
  • Classify keywords as assertions or annotations and describe their general behavior
    • -
  • Explain the boolean schemas in terms of generalized assertions
    • -
  • Reserve "$comment" for non-user-visible notes about the schema
    • -
  • Wording improvements around "$id" and fragments
    • -
  • Note the challenges of extending meta-schemas with recursive references
    • -
  • Add "application/schema-instance+json" media type
    • -
  • Recommend a "schema" link relation / parameter instead of "profile"
    • -
-
- -
-
    -
  • Updated intro
    • -
  • Allowed for any schema to be a boolean
    • -
  • "$schema" SHOULD NOT appear in subschemas, although that may change
    • -
  • Changed "id" to "$id"; all core keywords prefixed with "$"
    • -
  • Clarify and formalize fragments for application/schema+json
    • -
  • Note applicability to formats such as CBOR that can be represented in the JSON data model
    • -
-
- -
-
    -
  • Updated references to JSON
    • -
  • Updated references to HTTP
    • -
  • Updated references to JSON Pointer
    • -
  • Behavior for "id" is now specified in terms of RFC3986
    • -
  • Aligned vocabulary usage for URIs with RFC3986
    • -
  • Removed reference to draft-pbryan-zyp-json-ref-03
    • -
  • Limited use of "$ref" to wherever a schema is expected
    • -
  • Added definition of the "JSON Schema data model"
    • -
  • Added additional security considerations
    • -
  • Defined use of subschema identifiers for "id"
    • -
  • Rewrote section on usage with HTTP
    • -
  • Rewrote section on usage with rel="describedBy" and rel="profile"
    • -
  • Fixed numerous invalid examples
    • -
-
- -
-
    -
  • Salvaged from draft v3.
    • -
  • Split validation keywords into separate document.
    • -
  • Split hypermedia keywords into separate document.
    • -
  • Initial post-split draft.
    • -
  • Mandate the use of JSON Reference, JSON Pointer.
    • -
  • Define the role of "id". Define URI resolution scope.
    • -
  • Add interoperability considerations.
    • -
-
- -
-
    -
  • Initial draft.
    • -
-
-
- - diff --git a/jsonschema-validation.md b/jsonschema-validation.md new file mode 100644 index 00000000..f22c50ec --- /dev/null +++ b/jsonschema-validation.md @@ -0,0 +1,1046 @@ +# JSON Schema Validation: A Vocabulary for Structural Validation of JSON + +## Abstract +JSON Schema (application/schema+json) has several purposes, one of which is JSON +instance validation. This document specifies a vocabulary for JSON Schema to +describe the meaning of JSON documents, provide hints for user interfaces +working with JSON data, and to make assertions about what a valid document must +look like. + +## Note to Readers +The issues list for this draft can be found at +. + +For additional information, see . + +To provide feedback, use this issue tracker, the communication methods listed on +the homepage, or email the document editors. + +## Table of Contents + +## Introduction +JSON Schema can be used to require that a given JSON document (an instance) +satisfies a certain number of criteria. These criteria are asserted by using +keywords described in this specification. In addition, a set of keywords is also +defined to assist in interactive user interface instance generation. + +This specification will use the concepts, syntax, and terminology defined by the +[JSON Schema core](#json-schema) specification. + +## Conventions and Terminology +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in [RFC 2119](#rfc2119). + +This specification uses the term "container instance" to refer to both array and +object instances. It uses the term "children instances" to refer to array +elements or object member values. + +Elements in an array value are said to be unique if no two elements of this +array are [equal](#json-schema). + +## Overview +JSON Schema validation asserts constraints on the structure of instance data. +An instance location that satisfies all asserted constraints is then annotated +with any keywords that contain non-assertion information, such as descriptive +metadata and usage hints. If all locations within the instance satisfy all +asserted constraints, then the instance is said to be valid against the schema. + +Each schema object is independently evaluated against each instance location to +which it applies. This greatly simplifies the implementation requirements for +validators by ensuring that they do not need to maintain state across the +document-wide validation process. + +This specification defines a set of assertion keywords, as well as a small +vocabulary of metadata keywords that can be used to annotate the JSON instance +with useful information. The [Section +7](#7-vocabularies-for-semantic-content-with-format) keyword is intended +primarily as an annotation, but can optionally be used as an assertion. The +[Section 8](#8-a-vocabulary-for-the-contents-of-string-encoded-data) keywords +are annotations for working with documents embedded as JSON strings. + +## Interoperability Considerations + +### Validation of String Instances +It should be noted that the nul character (\u0000) is valid in a JSON string. An +instance to validate may contain a string value with this character, regardless +of the ability of the underlying programming language to deal with such data. + +### Validation of Numeric Instances +The JSON specification allows numbers with arbitrary precision, and JSON Schema +does not add any such bounds. This means that numeric instances processed by +JSON Schema can be arbitrarily large and/or have an arbitrarily long decimal +part, regardless of the ability of the underlying programming language to deal +with such data. + +### Regular Expressions +Keywords that use regular expressions, or constrain the instance value to be a +regular expression, are subject to the interoperability considerations for +regular expressions in the [JSON Schema Core](#json-schema) specification. + +## Meta-Schema +The current IRI for the default JSON Schema dialect meta-schema is +`https://json-schema.org/draft/next/schema`. For schema author convenience, this +meta-schema describes a dialect consisting of all vocabularies defined in this +specification and the JSON Schema Core specification, as well as two former +keywords which are reserved for a transitional period. Individual vocabulary and +vocabulary meta-schema IRIs are given for each section below. Certain +vocabularies are optional to support, which is explained in detail in the +relevant sections. + +Updated vocabulary and meta-schema IRIs MAY be published between specification +drafts in order to correct errors. Implementations SHOULD consider IRIs dated +after this specification draft and before the next to indicate the same syntax +and semantics as those listed here. + +## A Vocabulary for Structural Validation +Validation keywords in a schema impose requirements for successful validation of +an instance. These keywords are all assertions without any annotation behavior. + +Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this +vocabulary as if its IRI were present with a value of true. + +The current IRI for this vocabulary, known as the Validation vocabulary, is: +`https://json-schema.org/draft/next/vocab/validation`. + +The current IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/validation`. + +### Validation Keywords for Any Instance Type + +#### type +The value of this keyword MUST be either a string or an array. If it is an +array, elements of the array MUST be strings and MUST be unique. + +String values MUST be one of the six primitive types ("null", "boolean", +"object", "array", "number", or "string"), or "integer" which matches any number +with a zero fractional part. + +If the value of "type" is a string, then an instance validates successfully if +its type matches the type represented by the value of the string. If the value +of "type" is an array, then an instance validates successfully if its type +matches any of the types indicated by the strings in the array. + +#### enum +The value of this keyword MUST be an array. This array SHOULD have at least one +element. Elements in the array SHOULD be unique. + +An instance validates successfully against this keyword if its value is equal to +one of the elements in this keyword's array value. + +Elements in the array might be of any type, including null. + +#### const +The value of this keyword MAY be of any type, including null. + +Use of this keyword is functionally equivalent to an [`enum`](#612-enum) with a +single value. + +An instance validates successfully against this keyword if its value is equal to +the value of the keyword. + +### Validation Keywords for Numeric Instances (number and integer) + +#### multipleOf +The value of `multipleOf` MUST be a number, strictly greater than 0. + +A numeric instance is valid only if division by this keyword's value results in +an integer. + +#### maximum +The value of `maximum` MUST be a number, representing an inclusive upper limit +for a numeric instance. + +If the instance is a number, then this keyword validates only if the instance is +less than or exactly equal to `maximum`. + +#### exclusiveMaximum +The value of `exclusiveMaximum` MUST be a number, representing an exclusive +upper limit for a numeric instance. + +If the instance is a number, then the instance is valid only if it has a value +strictly less than (not equal to) `exclusiveMaximum`. + +#### minimum +The value of `minimum` MUST be a number, representing an inclusive lower limit +for a numeric instance. + +If the instance is a number, then this keyword validates only if the instance is +greater than or exactly equal to `minimum`. + +#### exclusiveMinimum +The value of `exclusiveMinimum` MUST be a number, representing an exclusive +lower limit for a numeric instance. + +If the instance is a number, then the instance is valid only if it has a value +strictly greater than (not equal to) `exclusiveMinimum`. + +### Validation Keywords for Strings + +#### maxLength +The value of this keyword MUST be a non-negative integer. + +A string instance is valid against this keyword if its length is less than, or +equal to, the value of this keyword. + +The length of a string instance is defined as the number of its characters as +defined by [RFC 8259](#rfc8259). + +#### minLength +The value of this keyword MUST be a non-negative integer. + +A string instance is valid against this keyword if its length is greater than, +or equal to, the value of this keyword. + +The length of a string instance is defined as the number of its characters as +defined by [RFC 8259](#rfc8259). + +Omitting this keyword has the same behavior as a value of 0. + +#### pattern +The value of this keyword MUST be a string. This string SHOULD be a valid +regular expression, according to the ECMA-262 regular expression dialect. + +A string instance is considered valid if the regular expression matches the +instance successfully. Recall: regular expressions are not implicitly anchored. + +### Validation Keywords for Arrays + +#### maxItems +The value of this keyword MUST be a non-negative integer. + +An array instance is valid against `maxItems` if its size is less than, or equal +to, the value of this keyword. + +#### minItems +The value of this keyword MUST be a non-negative integer. + +An array instance is valid against `minItems` if its size is greater than, or +equal to, the value of this keyword. + +Omitting this keyword has the same behavior as a value of 0. + +#### uniqueItems +The value of this keyword MUST be a boolean. + +If this keyword has boolean value false, the instance validates successfully. If +it has boolean value true, the instance validates successfully if all of its +elements are unique. + +Omitting this keyword has the same behavior as a value of false. + +### Validation Keywords for Objects + +#### maxProperties +The value of this keyword MUST be a non-negative integer. + +An object instance is valid against `maxProperties` if its number of properties +is less than, or equal to, the value of this keyword. + +#### minProperties +The value of this keyword MUST be a non-negative integer. + +An object instance is valid against `minProperties` if its number of properties +is greater than, or equal to, the value of this keyword. + +Omitting this keyword has the same behavior as a value of 0. + +#### required +The value of this keyword MUST be an array. Elements of this array, if any, MUST +be strings, and MUST be unique. + +An object instance is valid against this keyword if every item in the array is +the name of a property in the instance. + +Omitting this keyword has the same behavior as an empty array. + +#### dependentRequired +The value of this keyword MUST be an object. Properties in this object, if any, +MUST be arrays. Elements in each array, if any, MUST be strings, and MUST be +unique. + +This keyword specifies properties that are required if a specific other property +is present. Their requirement is dependent on the presence of the other +property. + +Validation succeeds if, for each name that appears in both the instance and as a +name within this keyword's value, every item in the corresponding array is also +the name of a property in the instance. + +Omitting this keyword has the same behavior as an empty object. + +## Vocabularies for Semantic Content With format + +### Foreword +Structural validation alone may be insufficient to allow an application to +correctly utilize certain values. The `format` annotation keyword is defined to +allow schema authors to convey semantic information for a fixed subset of values +which are accurately described by authoritative resources, be they RFCs or other +external specifications. + +The value of this keyword is called a format attribute. It MUST be a string. A +format attribute can generally only validate a given set of instance types. If +the type of the instance to validate is not in this set, validation for this +format attribute and instance SHOULD succeed. All format attributes defined in +this section apply to strings, but a format attribute can be specified to apply +to any instance types defined in the data model defined in the [core JSON +Schema.](#json-schema)[^1] + +[^1]: Note that the `type` keyword in this specification defines an "integer" +type which is not part of the data model. Therefore a format attribute can be +limited to numbers, but not specifically to integers. However, a numeric format +can be used alongside the `type` keyword with a value of "integer", or could be +explicitly defined to always pass if the number is not an integer, which +produces essentially the same behavior as only applying to integers. + +The current IRI for this vocabulary, known as the Format-Annotation vocabulary, +is: `https://json-schema.org/draft/next/vocab/format-annotation`. The current +IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/format-annotation`. Implementing +support for this vocabulary is REQUIRED. + +In addition to the Format-Annotation vocabulary, a secondary vocabulary is +available for custom meta-schemas that defines `format` as an assertion. The IRI +for the Format-Assertion vocabulary, is: +`https://json-schema.org/draft/next/vocab/format-assertion`. The current IRI for +the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/format-assertion`. Implementing support +for the Format-Assertion vocabulary is OPTIONAL. + +Specifying both the Format-Annotation and the Format-Assertion vocabularies is +functionally equivalent to specifying only the Format-Assertion vocabulary since +its requirements are a superset of the Format-Annotation vocabulary. + +### Implementation Requirements +The `format` keyword functions as defined by the vocabulary which is referenced. + +#### Format-Annotation Vocabulary +The value of format MUST be collected as an annotation, if the implementation +supports annotation collection. This enables application-level validation when +schema validation is unavailable or inadequate. + +Implementations MAY still treat `format` as an assertion in addition to an +annotation and attempt to validate the value's conformance to the specified +semantics. The implementation MUST provide options to enable and disable such +evaluation and MUST be disabled by default. Implementations SHOULD document +their level of support for such validation.[^2] + +[^2]: Specifying the Format-Annotation vocabulary and enabling validation in an +implementation should not be viewed as being equivalent to specifying the +Format-Assertion vocabulary since implementations are not required to provide +full validation support when the Format-Assertion vocabulary is not specified. + +When the implementation is configured for assertion behavior, it: + +- SHOULD provide an implementation-specific best effort validation for each +format attribute defined below; +- MAY choose to implement validation of any or all format attributes as a no-op +by always producing a validation result of true;[^3] + +[^3]: This matches the current reality of implementations, which provide widely +varying levels of validation, including no validation at all, for some or all +format attributes. It is also designed to encourage relying only on the +annotation behavior and performing semantic validation in the application, which +is the recommended best practice. + +#### Format-Assertion Vocabulary +When the Format-Assertion vocabulary is declared with a value of true, +implementations MUST provide full validation support for all of the formats +defined by this specificaion. Implementations that cannot provide full +validation support MUST refuse to process the schema. + +An implementation that supports the Format-Assertion vocabulary: +- MUST still collect `format` as an annotation if the implementation supports +annotation collection; +- MUST evaluate `format` as an assertion; +- MUST implement syntactic validation for all format attributes defined in this +specification, and for any additional format attributes that it recognizes, such +that there exist possible instance values of the correct type that will fail +validation. The requirement for minimal validation of format attributes is +intentionally vague and permissive, due to the complexity involved in many of +the attributes. Note in particular that the requirement is limited to syntactic +checking; it is not to be expected that an implementation would send an email, +attempt to connect to a URL, or otherwise check the existence of an entity +identified by a format instance.[^4] + +[^4]: The expectation is that for simple formats such as date-time, syntactic +validation will be thorough. For a complex format such as email addresses, which +are the amalgamation of various standards and numerous adjustments over time, +with obscure and/or obsolete rules that may or may not be restricted by other +applications making use of the value, a minimal validation is sufficient. For +example, an instance string that does not contain an "@" is clearly not a valid +email address, and an "email" or "hostname" containing characters outside of +7-bit ASCII is likewise clearly invalid. + +It is RECOMMENDED that implementations use a common parsing library for each +format, or a well-known regular expression. Implementations SHOULD clearly +document how and to what degree each format attribute is validated. + +The [standard core and validation meta-schema](#5-meta-schema) includes this +vocabulary in its `$vocabulary` keyword with a value of false, since by default +implementations are not required to support this keyword as an assertion. +Supporting the format vocabulary with a value of true is understood to greatly +increase code size and in some cases execution time, and will not be appropriate +for all implementations. + +#### Custom format attributes +Implementations MAY support custom format attributes. Save for agreement between +parties, schema authors SHALL NOT expect a peer implementation to support such +custom format attributes. An implementation MUST NOT fail to collect unknown +formats as annotations. When the Format-Assertion vocabulary is specified, +implementations MUST fail upon encountering unknown formats. + +Vocabularies do not support specifically declaring different value sets for +keywords. Due to this limitation, and the historically uneven implementation of +this keyword, it is RECOMMENDED to define additional keywords in a custom +vocabulary rather than additional format attributes if interoperability is +desired. + +### Defined Formats + +#### Dates, Times, and Duration +These attributes apply to string instances. + +Date and time format names are derived from [RFC 3339, section 5.6](#rfc3339). +The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC +3339. + +Implementations supporting formats SHOULD implement support for the following +attributes: + +- *date-time:* A string instance is valid against this attribute if it is a +valid representation according to the "date-time" ABNF rule (referenced above) +- *date:* A string instance is valid against this attribute if it is a valid +representation according to the "full-date" ABNF rule (referenced above) +- *time:* A string instance is valid against this attribute if it is a valid +representation according to the "full-time" ABNF rule (referenced above) +- *duration:* A string instance is valid against this attribute if it is a valid +representation according to the "duration" ABNF rule (referenced above) + +Implementations MAY support additional attributes using the other format names +defined anywhere in that RFC. If "full-date" or "full-time" are implemented, the +corresponding short form ("date" or "time" respectively) MUST be implemented, +and MUST behave identically. Implementations SHOULD NOT define extension +attributes with any name matching an RFC 3339 format unless it validates +according to the rules of that format.[^5] + +[^5]: There is not currently consensus on the need for supporting all RFC 3339 +formats, so this approach of reserving the namespace will encourage +experimentation without committing to the entire set. Either the format +implementation requirements will become more flexible in general, or these will +likely either be promoted to fully specified attributes or dropped. + +#### Email Addresses +These attributes apply to string instances. + +A string instance is valid against these attributes if it is a valid Internet +email address as follows: - *email:* As defined by the "Mailbox" ABNF rule in +[RFC 5321, section 4.1.2](#rfc5321). + +- *idn-email:* As defined by the extended "Mailbox" ABNF rule in [RFC 6531, +section 3.3](#rfc6531). Note that all strings valid against the "email" +attribute are also valid against the "idn-email" attribute. + +#### Hostnames +These attributes apply to string instances. + +A string instance is valid against these attributes if it is a valid +representation for an Internet hostname as follows: + +- *hostname:* As defined by [RFC 1123, section 2.1](#rfc1123), including host +names produced using the Punycode algorithm specified in [RFC 5891, section +4.4](#rfc5891). +- *idn-hostname:* As defined by either RFC 1123 as for hostname, or an +internationalized hostname as defined by [RFC 5890, section 2.3.2.3](#rfc5890). +Note that all strings valid against the "hostname" attribute are also valid +against the "idn-hostname" attribute. + +#### IP Addresses +These attributes apply to string instances. + +A string instance is valid against these attributes if it is a valid +representation of an IP address as follows: + +- *ipv4:* An IPv4 address according to the "dotted-quad" ABNF syntax as defined +in [RFC 2673, section 3.2](#rfc2673). +- *ipv6:* An IPv6 address as defined in [RFC 4291, section 2.2](#rfc4291). + +#### Resource Identifiers +These attributes apply to string instances. + +- *uri:* A string instance is valid against this attribute if it is a valid IRI, +according to [Appendix RFC3987](#rfc3987). +- *uri-reference:* A string instance is valid against this attribute if it is a +valid URI Reference (either a URI or a relative-reference), according to +[Appendix RFC3986](#rfc3986). +- *iri:* A string instance is valid against this attribute if it is a valid IRI, +according to [Appendix RFC3987](#rfc3987). +- *iri-reference:* A string instance is valid against this attribute if it is a +valid IRI Reference (either an IRI or a relative-reference), according to +[Appendix RFC3987](#rfc3987). +- *uuid:* A string instance is valid against this attribute if it is a valid +string representation of a UUID, according to [Appendix RFC4122](#rfc4122). + +Note that all valid URIs are valid IRIs, and all valid URI References are also +valid IRI References. + +Note also that the "uuid" format is for plain UUIDs, not UUIDs in URNs. An +example is "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". For UUIDs as URNs, use the +"uri" format, with a "pattern" regular expression of "^urn:uuid:" to indicate +the URI scheme and URN namespace. + +#### uri-template +This attribute applies to string instances. + +A string instance is valid against this attribute if it is a valid URI Template +(of any level), according to [Appendix RFC6570](#rfc6570). + +Note that URI Templates may be used for IRIs; there is no separate IRI Template +specification. + +#### JSON Pointers +These attributes apply to string instances. + +- *json-pointer:* A string instance is valid against this attribute if it is a +valid JSON string representation of a JSON Pointer, according to [RFC 6901, +section 5](#rfc6901). +- *relative-json-pointer:* A string instance is valid against this attribute if +it is a valid [Relative JSON Pointer](#relative-json-pointer). To allow for both +absolute and relative JSON Pointers, use `anyOf` or `oneOf` to indicate support +for either format. + +#### regex +This attribute applies to string instances. + +A regular expression, which SHOULD be valid according to the +[ECMA-262](#ecma262) regular expression dialect. + +Implementations that validate formats MUST accept at least the subset of +ECMA-262 defined in the [Regular Expressions](#43-regular-expressions) section +of this specification, and SHOULD accept all valid ECMA-262 expressions. + +## A Vocabulary for the Contents of String-Encoded Data + +### Foreword +Annotations defined in this section indicate that an instance contains non-JSON +data encoded in a JSON string. + +These properties provide additional information required to interpret JSON data +as rich multimedia documents. They describe the type of content, how it is +encoded, and/or how it may be validated. They do not function as validation +assertions; a malformed string-encoded document MUST NOT cause the containing +instance to be considered invalid. + +Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this +vocabulary as if its IRI were present with a value of true. + +The current IRI for this vocabulary, known as the Content vocabulary, is: +`https://json-schema.org/draft/next/vocab/content`. + +The current IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/content`. + +### Implementation Requirements +Due to security and performance concerns, as well as the open-ended nature of +possible content types, implementations MUST NOT automatically decode, parse, +and/or validate the string contents. Applications are expected to use these +annotations to invoke the appropriate libraries separately. + +All keywords in this section apply only to strings, and have no effect on other +data types. + +### contentEncoding +If the instance value is a string, this property defines that the string SHOULD +be interpreted as encoded binary data and applications wishing to decode it +SHOULD do so using the encoding named by this property. + +Possible values indicating base 16, 32, and 64 encodings with several variations +are listed in [RFC 4648](#rfc4648). Additionally, sections 6.7 and 6.8 of [RFC +2045](#rfc2045) provide encodings used in MIME. This keyword is derived from +MIME's Content-Transfer-Encoding header, which was designed to map binary data +into ASCII characters. It is not related to HTTP's Content-Encoding header, +which is used to encode (e.g. compress or encrypt) the content of HTTP request +and responses. + +As "base64" is defined in both RFCs, the definition from RFC 4648 SHOULD be +assumed unless the string is specifically intended for use in a MIME context. +Note that all of these encodings result in strings consisting only of 7-bit +ASCII characters. Therefore, this keyword has no meaning for strings containing +characters outside of that range. + +If this keyword is absent, but `contentMediaType` is present, this indicates +that the encoding is the identity encoding, meaning that no transformation was +needed in order to represent the content in a UTF-8 string. + +The value of this property MUST be a string. + +### contentMediaType +If the instance is a string, this property indicates the media type of the +contents of the string. If `contentEncoding` is present, this property describes +the decoded string. + +The value of this property MUST be a string, which MUST be a media type, as +defined by [RFC 2046](#rfc2046). + +### contentSchema +If the instance is a string, and if `contentMediaType` is present, this property +contains a schema which describes the structure of the string. + +This keyword MAY be used with any media type that can be mapped into JSON +Schema's data model. Specifying such mappings is outside of the scope of this +specification. + +The value of this property MUST be a valid JSON schema. It SHOULD be ignored if +`contentMediaType` is not present. Accessing the schema through the schema +location IRI included as part of the annotation will ensure that it is correctly +processed as a subschema. Using the extracted annotation value directly is only +safe if the schema is an embedded resource with both `$schema` and an +absolute-IRI `$id`. + +### Example +Here is an example schema, illustrating the use of `contentEncoding` and +`contentMediaType`: + +```json +{ + "type": "string", + "contentEncoding": "base64", + "contentMediaType": "image/png" +} +``` + +Instances described by this schema are expected to be strings, and their values +should be interpretable as base64-encoded PNG images. + +Another example: + +```json +{ + "type": "string", + "contentMediaType": "text/html" +} +``` + +Instances described by this schema are expected to be strings containing HTML, +using whatever character set the JSON string was decoded into. Per section 8.1 +of [RFC 8259](#rfc8259), outside of an entirely closed system, this MUST be +UTF-8. + +This example describes a JWT that is MACed using the HMAC SHA-256 algorithm, and +requires the "iss" and "exp" fields in its claim set. + +```json +{ + "type": "string", + "contentMediaType": "application/jwt", + "contentSchema": { + "type": "array", + "minItems": 2, + "prefixItems": [ + { + "const": { + "typ": "JWT", + "alg": "HS256" + } + }, + { + "type": "object", + "required": ["iss", "exp"], + "properties": { + "iss": {"type": "string"}, + "exp": {"type": "integer"} + } + } + ] + } +} +``` + +Note that `contentEncoding` does not appear. While the `application/jwt` media +type makes use of base64url encoding, that is defined by the media type, which +determines how the JWT string is decoded into a list of two JSON data +structures: first the header, and then the payload. Since the JWT media type +ensures that the JWT can be represented in a JSON string, there is no need for +further encoding or decoding. + +## A Vocabulary for Basic Meta-Data Annotations +These general-purpose annotation keywords provide commonly used information for +documentation and user interface display purposes. They are not intended to form +a comprehensive set of features. Rather, additional vocabularies can be defined +for more complex annotation-based applications. + +Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this +vocabulary as if its IRI were present with a value of true. + +The current IRI for this vocabulary, known as the Meta-Data vocabulary, is: +`https://json-schema.org/draft/next/vocab/meta-data`. + +The current IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/meta-data`. + +### title and description +The value of both of these keywords MUST be a string. + +Both of these keywords can be used to decorate a user interface with information +about the data produced by this user interface. A title will preferably be +short, whereas a description will provide explanation about the purpose of the +instance described by this schema. + +### default +There are no restrictions placed on the value of this keyword. When multiple +occurrences of this keyword are applicable to a single sub-instance, +implementations SHOULD remove duplicates. + +This keyword can be used to supply a default JSON value associated with a +particular schema. It is RECOMMENDED that a default value be valid against the +associated schema. + +### deprecated +The value of this keyword MUST be a boolean. When multiple occurrences of this +keyword are applicable to a single sub-instance, applications SHOULD consider +the instance location to be deprecated if any occurrence specifies a true value. + +If `deprecated` has a value of boolean true, it indicates that applications +SHOULD refrain from usage of the declared property. It MAY mean the property is +going to be removed in the future. + +A root schema containing `deprecated` with a value of true indicates that the +entire resource being described MAY be removed in the future. + +The `deprecated` keyword applies to each instance location to which the schema +object containing the keyword successfully applies. This can result in scenarios +where every array item or object property is deprecated even though the +containing array or object is not. + +Omitting this keyword has the same behavior as a value of false. + +### readOnly and writeOnly +The value of these keywords MUST be a boolean. When multiple occurrences of +these keywords are applicable to a single sub-instance, the resulting behavior +SHOULD be as for a true value if any occurrence specifies a true value, and +SHOULD be as for a false value otherwise. + +If `readOnly` has a value of boolean true, it indicates that the value of the +instance is managed exclusively by the owning authority, and attempts by an +application to modify the value of this property are expected to be ignored or +rejected by that owning authority. + +An instance document that is marked as `readOnly` for the entire document MAY be +ignored if sent to the owning authority, or MAY result in an error, at the +authority's discretion. + +If `writeOnly` has a value of boolean true, it indicates that the value is never +present when the instance is retrieved from the owning authority. It can be +present when sent to the owning authority to update or create the document (or +the resource it represents), but it will not be included in any updated or newly +created version of the instance. + +An instance document that is marked as `writeOnly` for the entire document MAY +be returned as a blank document of some sort, or MAY produce an error upon +retrieval, or have the retrieval request ignored, at the authority's discretion. + +For example, `readOnly` would be used to mark a database-generated serial number +as read-only, while `writeOnly` would be used to mark a password input field. + +These keywords can be used to assist in user interface instance generation. In +particular, an application MAY choose to use a widget that hides input values as +they are typed for write-only fields. + +Omitting these keywords has the same behavior as values of false. + +### examples +The value of this keyword MUST be an array. There are no restrictions placed on +the values within the array. When multiple occurrences of this keyword are +applicable to a single sub-instance, implementations MUST provide a flat array +of all values rather than an array of arrays. + +This keyword can be used to provide sample JSON values associated with a +particular schema, for the purpose of illustrating usage. It is RECOMMENDED that +these values be valid against the associated schema. + +Implementations MAY use the value(s) of `default`, if present, as an additional +example. If `examples` is absent, `default` MAY still be used in this manner. + +## Security Considerations +JSON Schema validation defines a vocabulary for JSON Schema core and concerns +all the security considerations listed there. + +JSON Schema validation allows the use of Regular Expressions, which have +numerous different (often incompatible) implementations. Some implementations +allow the embedding of arbitrary code, which is outside the scope of JSON Schema +and MUST NOT be permitted. Regular expressions can often also be crafted to be +extremely expensive to compute (with so-called "catastrophic backtracking"), +resulting in a denial-of-service attack. + +Implementations that support validating or otherwise evaluating instance string +data based on `contentEncoding` and/or `contentMediaType` are at risk of +evaluating data in an unsafe way based on misleading information. Applications +can mitigate this risk by only performing such processing when a relationship +between the schema and instance is established (e.g., they share the same +authority). + +Processing a media type or encoding is subject to the security considerations of +that media type or encoding. For example, the security considerations of [RFC +4329 Scripting Media Types](#rfc4329) apply when processing JavaScript or +ECMAScript encoded within a JSON string. + +## References + +### Normative References + +#### [RFC2119] +Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, +RFC 2119, DOI 10.17487/RFC2119, March 1997, +<>. + +#### [RFC1123] +Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", +STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, +<>. + +#### [RFC2045] +Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part +One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, +November 1996, <>. + +#### [RFC2046] +Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part +Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, +<>. + +#### [RFC2673] +Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, DOI +10.17487/RFC2673, August 1999, <>. + +#### [RFC3339] +Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, +DOI 10.17487/RFC3339, July 2002, <>. + +#### [RFC3986] +Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier +(URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, +<>. + +#### [RFC3987] +Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC +3987, DOI 10.17487/RFC3987, January 2005, +<>. + +#### [RFC4122] +Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) +URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, +<>. + +#### [RFC4291] +Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI +10.17487/RFC4291, February 2006, <>. + +#### [RFC4648] +Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI +10.17487/RFC4648, October 2006, <>. + +#### [RFC5321] +Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, +October 2008, <>. + +#### [RFC5890] +Klensin, J., "Internationalized Domain Names for Applications (IDNA): +Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August +2010, <>. + +#### [RFC5891] +Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", +RFC 5891, DOI 10.17487/RFC5891, August 2010, +<>. + +#### [RFC6570] +Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI +Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, +<>. + +#### [RFC6531] + +Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI +10.17487/RFC6531, February 2012, <>. + +#### [RFC6901] +Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation +(JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, +<>. + +#### [RFC8259] +Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", +STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, +<>. + +#### [ecma262] +"ECMA-262, 11th edition specification", June 2020, +<>. + +#### [relative-json-pointer] +Luff, G., Andrews, H., and B. Hutton, Ed., "Relative JSON Pointers", Work in +Progress, Internet-Draft, draft-handrews-relative-json-pointer-01, December +2020, +<>. + +#### [json-schema] +Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON Schema: A Media Type +for Describing JSON Documents", Work in Progress, Internet-Draft, +draft-bhutton-json-schema-01, June 2022, +<>. + +### Informative References + +#### [RFC4329] +Hoehrmann, B., "Scripting Media Types", RFC 4329, DOI 10.17487/RFC4329, April +2006, <>. + +## Appendix A. Keywords Moved from Validation to Core +Several keywords have been moved from this document into the [Core +Specification](#json-schema) starting with draft 2019-09, in some cases with +re-naming or other changes. This affects the following former validation +keywords: + +- *`definitions`* Renamed to `$defs` to match `$ref` and be shorter to type. +Schema vocabulary authors SHOULD NOT define a `definitions` keyword with +different behavior in order to avoid invalidating schemas that still use the +older name. While `definitions` is absent in the single-vocabulary meta-schemas +referenced by this document, it remains present in the default meta-schema, and +implementations SHOULD assume that `$defs` and `definitions` have the same +behavior when that meta-schema is used. +- *`allOf`, `anyOf`, `oneOf`, `not`, `if`, `then`, `else`, `items`, +`additionalItems`, `contains`, `propertyNames`, `properties`, +`patternProperties`, `additionalProperties`* All of these keywords apply +subschemas to the instance and combine their results, without asserting any +conditions of their own. Without assertion keywords, these applicators can only +cause assertion failures by using the false boolean schema, or by inverting the +result of the true boolean schema (or equivalent schema objects). For this +reason, they are better defined as a generic mechanism on which validation, +hyper-schema, and extension vocabularies can all be based. +- *`maxContains`, `minContains`* These keywords modify the behavior of +`contains`, and are therefore grouped with it in the applicator vocabulary. +- *`dependencies`* This keyword had two different modes of behavior, which made +it relatively challenging to implement and reason about. The schema form has +been moved to Core and renamed to `dependentSchemas`, as part of the applicator +vocabulary. It is analogous to `properties`, except that instead of applying its +subschema to the property value, it applies it to the object containing the +property. The property name array form is retained here and renamed to +`dependentRequired`, as it is an assertion which is a shortcut for the +conditional use of the `required` assertion keyword. + +## Appendix B. Acknowledgments +Thanks to Gary Court, Francis Galiegue, Kris Zyp, Geraint Luff, and Henry +Andrews for their work on the initial drafts of JSON Schema. + +Thanks to Jason Desrosiers, Daniel Perrett, Erik Wilde, Evgeny Poberezkin, Brad +Bowman, Gowry Sankar, Donald Pipowitch, Dave Finlay, Denis Laxalde, Phil +Sturgeon, Shawn Silverman, and Karen Etheridge for their submissions and patches +to the document. + +## Appendix C. ChangeLog[^6] +[^6]: This section to be removed before leaving Internet-Draft status. + +- *draft-next* + - Use IRIs instead of URIs +- *draft-bhutton-json-schema-validation-01* + - Improve and clarify the `minContains` keyword explanation + - Remove the use of "production" in favour of "ABNF rule" +- *draft-bhutton-json-schema-validation-00* + - Correct email format RFC reference to 5321 instead of 5322 + - Clarified the set and meaning of `contentEncoding` values + - Reference ECMA-262, 11th edition for regular expression support + - Split `format` into an annotation only vocabulary and an assertion + vocabulary + - Clarify `deprecated` when applicable to arrays +- *draft-handrews-json-schema-validation-02* + - Grouped keywords into formal vocabularies + - Update `format` implementation requirements in terms of vocabularies + - By default, `format` MUST NOT be validated, although validation can be + enabled + - A vocabulary declaration can be used to require `format` validation + - Moved `definitions` to the core spec as `$defs` + - Moved applicator keywords to the core spec + - Renamed the array form of `dependencies` to `dependentRequired`, moved the +schema form to the core spec + - Specified all `content*` keywords as annotations, not assertions + - Added `contentSchema` to allow applying a schema to a string-encoded + document + - Also allow RFC 4648 encodings in `contentEncoding` + - Added `minContains` and `maxContains` + - Update RFC reference for nhostname" and "idn-hostname" + - Add "uuid" and "duration" formats +- *draft-handrews-json-schema-validation-01* + - This draft is purely a clarification with no functional changes + - Provided the general principle behind ignoring annotations under `not` and + similar cases + - Clarified `if`/`then`/`else` validation interactions + - Clarified `if`/`then`/`else` behavior for annotation + - Minor formatting and cross-referencing improvements +- *draft-handrews-json-schema-validation-00* + - Added `if`/`then`/`else` + - Classify keywords as assertions or annotations per the core spec + - Warn of possibly removing `dependencies` in the future + - Grouped validation keywords into sub-sections for readability + - Moved `readOnly` from hyper-schema to validation meta-data + - Added `writeOnly` + - Added string-encoded media section, with former hyper-schema `media` + keywords + - Restored "regex" format (removal was unintentional) + - Added "date" and "time" formats, and reserved additional RFC 3339 format + names + - I18N formats: "iri", "iri-reference", "idn-hostname", "idn-email" + - Clarify that "json-pointer" format means string encoding, not URI fragment + - Fixed typo that inverted the meaning of `minimum` and `exclusiveMinimum` + - Move format syntax references into Normative References + - JSON is a normative requirement +- *draft-wright-json-schema-validation-01* + - Standardized on hyphenated format names with full words ("uriref" becomes + "uri-reference") + - Add the formats "uri-template" and "json-pointer" + - Changed `exclusiveMaximum`/`exclusiveMinimum` from boolean modifiers of + `maximum`/`minimum` to independent numeric fields. + - Split the additionalItems/items into two sections + - Reworked properties/patternProperties/additionalProperties definition + - Added `examples` keyword + - Added `contains` keyword + - Allow empty `required` and `dependencies` arrays + - Fixed `type` reference to primitive types + - Added `const` keyword + - Added `propertyNames` keyword +- *draft-wright-json-schema-validation-00* + - Added additional security considerations + - Removed reference to "latest version" meta-schema, use numbered version + instead + - Rephrased many keyword definitions for brevity + - Added "uriref" format that also allows relative URI references +- *draft-fge-json-schema-validation-00* + - Initial draft. + - Salvaged from draft v3. + - Redefine the `required` keyword. + - Remove `extends`, `disallow` + - Add `anyOf`, `allOf`, `oneOf`, `not`, `definitions`, `minProperties`, + `maxProperties`. + - `dependencies` member values can no longer be single strings; at least one + element is required in a property dependency array. + - Rename `divisibleBy` to `multipleOf`. + - `type` arrays can no longer have schemas; remove `any` as a possible + value. + - Rework the `format` section; make support optional. + - `format": remove attributes "phone", "style", "color"; rename "ip-address" + to "ipv4"; add references for all attributes. + - Provide algorithms to calculate schema(s) for array/object instances. + - Add interoperability considerations. + +## Authors' Addresses + +### Austin Wright (*editor*) + +Email: + +### Ben Hutton (*editor*) + +Postman + +Email: + +URI: diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml deleted file mode 100644 index 65902b4e..00000000 --- a/jsonschema-validation.xml +++ /dev/null @@ -1,1492 +0,0 @@ - - - - - - - - - - - - - - - - - - - - -]> - - - - - - - - - - - - JSON Schema Validation: A Vocabulary for Structural Validation of JSON - - - -
- aaa@bzfx.net -
- - - - Postman -
- ben@jsonschema.dev - https://jsonschema.dev -
- - - - Internet Engineering Task Force - JSON - Schema - validation - - - - JSON Schema (application/schema+json) has several purposes, one of which is JSON - instance validation. - This document specifies a vocabulary for JSON Schema to describe the meaning of JSON - documents, provide hints for user interfaces working with JSON data, and to make - assertions about what a valid document must look like. - - - - - - The issues list for this draft can be found at - . - - - For additional information, see . - - - To provide feedback, use this issue tracker, the communication methods listed on the - homepage, or email the document editors. - - - - - -
- - JSON Schema can be used to require that a given JSON document (an instance) - satisfies a certain number of criteria. These criteria are asserted by using - keywords described in this specification. In addition, a set of keywords - is also defined to assist in interactive user interface instance generation. - - - This specification will use the concepts, syntax, and terminology defined - by the JSON Schema core specification. - -
- -
- - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", - "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be - interpreted as described in RFC 2119. - - - This specification uses the term "container instance" to refer to both array and - object instances. It uses the term "children instances" to refer to array elements - or object member values. - - - Elements in an array value are said to be unique if no two elements of this array - are equal. - -
- -
- - JSON Schema validation asserts constraints on the structure of instance data. - An instance location that satisfies all asserted constraints is then - annotated with any keywords that contain non-assertion information, - such as descriptive metadata and usage hints. If all locations within - the instance satisfy all asserted constraints, then the instance is - said to be valid against the schema. - - - Each schema object is independently evaluated against each instance location - to which it applies. This greatly simplifies the implementation requirements - for validators by ensuring that they do not need to maintain state across - the document-wide validation process. - - - This specification defines a set of assertion keywords, as well as a small vocabulary - of metadata keywords that can be used to annotate the JSON instance with - useful information. The keyword is intended primarily - as an annotation, but can optionally be used as an assertion. The - keywords are annotations for working with documents - embedded as JSON strings. - -
- -
- -
- - It should be noted that the nul character (\u0000) is valid in a JSON string. An - instance to validate may contain a string value with this character, regardless - of the ability of the underlying programming language to deal with such data. - -
- -
- - The JSON specification allows numbers with arbitrary precision, and JSON Schema - does not add any such bounds. - This means that numeric instances processed by JSON Schema can be arbitrarily large and/or - have an arbitrarily long decimal part, regardless of the ability of the - underlying programming language to deal with such data. - -
- -
- - Keywords that use regular expressions, or constrain the instance value - to be a regular expression, are subject to the interoperability - considerations for regular expressions in the - JSON Schema Core specification. - -
- -
- -
- - The current IRI for the default JSON Schema dialect meta-schema is - . - For schema author convenience, this meta-schema describes a dialect - consisting of all vocabularies - defined in this specification and the JSON Schema Core specification, - as well as two former keywords which are reserved for a transitional period. - Individual vocabulary and vocabulary meta-schema IRIs are given for - each section below. Certain vocabularies are optional to support, which - is explained in detail in the relevant sections. - - - Updated vocabulary and meta-schema IRIs MAY be published between - specification drafts in order to correct errors. Implementations - SHOULD consider IRIs dated after this specification draft and - before the next to indicate the same syntax and semantics - as those listed here. - -
- -
- - Validation keywords in a schema impose requirements for successful validation of an - instance. These keywords are all assertions without any annotation behavior. - - - Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its IRI were present with a value of true. - - - The current IRI for this vocabulary, known as the Validation vocabulary, is: - <https://json-schema.org/draft/next/vocab/validation>. - - - The current IRI for the corresponding meta-schema is: - . - - -
-
- - The value of this keyword MUST be either a string or an array. If it is - an array, elements of the array MUST be strings and MUST be unique. - - - String values MUST be one of the six primitive types - ("null", "boolean", "object", "array", "number", or "string"), - or "integer" which matches any number with a zero fractional part. - - - If the value of "type" is a string, then an instance validates successfully if - its type matches the type represented by the value of the string. - - If the value of "type" is an array, then an instance validates successfully if - its type matches any of the types indicated by the strings in the array. - -
- -
- - The value of this keyword MUST be an array. This array SHOULD have at - least one element. Elements in the array SHOULD be unique. - - - An instance validates successfully against this keyword if its value is - equal to one of the elements in this keyword's array value. - - - Elements in the array might be of any type, including null. - -
- -
- - The value of this keyword MAY be of any type, including null. - - - Use of this keyword is functionally equivalent to an - "enum" with a single value. - - - An instance validates successfully against this keyword if its value is - equal to the value of the keyword. - -
-
- -
-
- - The value of "multipleOf" MUST be a number, strictly greater than 0. - - - A numeric instance is valid only if division by this keyword's value results in - an integer. - -
- -
- - The value of "maximum" MUST be a number, representing an inclusive upper limit - for a numeric instance. - - - If the instance is a number, then this keyword validates only if the instance is - less than or exactly equal to "maximum". - -
- -
- - The value of "exclusiveMaximum" MUST be a number, representing an exclusive upper - limit for a numeric instance. - - - If the instance is a number, then the instance is valid only if it has a value - strictly less than (not equal to) "exclusiveMaximum". - -
- -
- - The value of "minimum" MUST be a number, representing an inclusive lower limit - for a numeric instance. - - - If the instance is a number, then this keyword validates only if the instance is - greater than or exactly equal to "minimum". - -
- -
- - The value of "exclusiveMinimum" MUST be a number, representing an exclusive lower - limit for a numeric instance. - - - If the instance is a number, then the instance is valid only if it has a value - strictly greater than (not equal to) "exclusiveMinimum". - -
-
- -
-
- - The value of this keyword MUST be a non-negative integer. - - A string instance is valid against this keyword if its - length is less than, or equal to, the value of this keyword. - - - The length of a string instance is defined as the number of its - characters as defined by RFC 8259. - -
- -
- - The value of this keyword MUST be a non-negative integer. - - - A string instance is valid against this keyword if its - length is greater than, or equal to, the value of this keyword. - - - - The length of a string instance is defined as the number of its - characters as defined by RFC 8259. - - - Omitting this keyword has the same behavior as a value of 0. - -
- -
- - The value of this keyword MUST be a string. This string SHOULD be a - valid regular expression, according to the ECMA-262 regular expression - dialect. - - - A string instance is considered valid if the regular - expression matches the instance successfully. Recall: regular - expressions are not implicitly anchored. - -
-
- -
- -
- - The value of this keyword MUST be a non-negative integer. - - - An array instance is valid against "maxItems" if its size is - less than, or equal to, the value of this keyword. - -
- -
- - The value of this keyword MUST be a non-negative integer. - - - An array instance is valid against "minItems" if its size is - greater than, or equal to, the value of this keyword. - - - Omitting this keyword has the same behavior as a value of 0. - -
- -
- - The value of this keyword MUST be a boolean. - - - If this keyword has boolean value false, the instance validates - successfully. If it has boolean value true, the instance validates - successfully if all of its elements are unique. - - - Omitting this keyword has the same behavior as a value of false. - -
-
- -
-
- - The value of this keyword MUST be a non-negative integer. - - - An object instance is valid against "maxProperties" if its - number of properties is less than, or equal to, the value of this - keyword. - -
- -
- - The value of this keyword MUST be a non-negative integer. - - - An object instance is valid against "minProperties" if its - number of properties is greater than, or equal to, the value of this - keyword. - - - Omitting this keyword has the same behavior as a value of 0. - -
- -
- - The value of this keyword MUST be an array. - Elements of this array, if any, MUST be strings, and MUST be unique. - - - An object instance is valid against this keyword if every item in the array is - the name of a property in the instance. - - - Omitting this keyword has the same behavior as an empty array. - -
- -
- - The value of this keyword MUST be an object. Properties in - this object, if any, MUST be arrays. Elements in each array, - if any, MUST be strings, and MUST be unique. - - - This keyword specifies properties that are required if a specific - other property is present. Their requirement is dependent on the - presence of the other property. - - - Validation succeeds if, for each name that appears in both - the instance and as a name within this keyword's value, every - item in the corresponding array is also the name of a property - in the instance. - - - Omitting this keyword has the same behavior as an empty object. - -
-
-
- -
- -
- - Structural validation alone may be insufficient to allow an application to correctly - utilize certain values. The "format" annotation keyword is defined to allow schema - authors to convey semantic information for a fixed subset of values which are - accurately described by authoritative resources, be they RFCs or other external - specifications. - - - - The value of this keyword is called a format attribute. It MUST be a string. A - format attribute can generally only validate a given set of instance types. If - the type of the instance to validate is not in this set, validation for this - format attribute and instance SHOULD succeed. All format attributes defined - in this section apply to strings, but a format attribute can be specified - to apply to any instance types defined in the data model defined in the - core JSON Schema. - - Note that the "type" keyword in this specification defines an "integer" type - which is not part of the data model. Therefore a format attribute can be - limited to numbers, but not specifically to integers. However, a numeric - format can be used alongside the "type" keyword with a value of "integer", - or could be explicitly defined to always pass if the number is not an integer, - which produces essentially the same behavior as only applying to integers. - - - - - The current IRI for this vocabulary, known as the Format-Annotation vocabulary, is: - <https://json-schema.org/draft/next/vocab/format-annotation>. The current - IRI for the corresponding meta-schema is: - . - Implementing support for this vocabulary is REQUIRED. - - - In addition to the Format-Annotation vocabulary, a secondary vocabulary is available - for custom meta-schemas that defines "format" as an assertion. The IRI for the - Format-Assertion vocabulary, is: - <https://json-schema.org/draft/next/vocab/format-assertion>. The current - IRI for the corresponding meta-schema is: - . - Implementing support for the Format-Assertion vocabulary is OPTIONAL. - - - Specifying both the Format-Annotation and the Format-Assertion vocabularies is functionally - equivalent to specifying only the Format-Assertion vocabulary since its requirements - are a superset of the Format-Annotation vocabulary. - -
- -
- - The "format" keyword functions as defined by the vocabulary which is referenced. - - -
- - The value of format MUST be collected as an annotation, if the implementation - supports annotation collection. This enables application-level validation when - schema validation is unavailable or inadequate. - - - Implementations MAY still treat "format" as an assertion in addition to an - annotation and attempt to validate the value's conformance to the specified - semantics. The implementation MUST provide options to enable and disable such - evaluation and MUST be disabled by default. Implementations SHOULD document - their level of support for such validation. - - Specifying the Format-Annotation vocabulary and enabling validation in an - implementation should not be viewed as being equivalent to specifying - the Format-Assertion vocabulary since implementations are not required to - provide full validation support when the Format-Assertion vocabulary - is not specified. - - - - When the implementation is configured for assertion behavior, it: - - - SHOULD provide an implementation-specific best effort validation - for each format attribute defined below; - - - MAY choose to implement validation of any or all format attributes - as a no-op by always producing a validation result of true; - - - - This matches the current reality of implementations, which provide - widely varying levels of validation, including no validation at all, - for some or all format attributes. It is also designed to encourage - relying only on the annotation behavior and performing semantic - validation in the application, which is the recommended best practice. - - -
- -
- - When the Format-Assertion vocabulary is declared with a value of true, - implementations MUST provide full validation support for all of the formats - defined by this specificaion. Implementations that cannot provide full - validation support MUST refuse to process the schema. - - - An implementation that supports the Format-Assertion vocabulary: - - - MUST still collect "format" as an annotation if the implementation - supports annotation collection; - - - MUST evaluate "format" as an assertion; - - - MUST implement syntactic validation for all format attributes defined - in this specification, and for any additional format attributes that - it recognizes, such that there exist possible instance values - of the correct type that will fail validation. - - - The requirement for minimal validation of format attributes is intentionally - vague and permissive, due to the complexity involved in many of the attributes. - Note in particular that the requirement is limited to syntactic checking; it is - not to be expected that an implementation would send an email, attempt to connect - to a URL, or otherwise check the existence of an entity identified by a format - instance. - - The expectation is that for simple formats such as date-time, syntactic - validation will be thorough. For a complex format such as email addresses, - which are the amalgamation of various standards and numerous adjustments - over time, with obscure and/or obsolete rules that may or may not be - restricted by other applications making use of the value, a minimal validation - is sufficient. For example, an instance string that does not contain - an "@" is clearly not a valid email address, and an "email" or "hostname" - containing characters outside of 7-bit ASCII is likewise clearly invalid. - - - - It is RECOMMENDED that implementations use a common parsing library for each format, - or a well-known regular expression. Implementations SHOULD clearly document - how and to what degree each format attribute is validated. - - - The standard core and validation meta-schema - includes this vocabulary in its "$vocabulary" keyword with a value of false, - since by default implementations are not required to support this keyword - as an assertion. Supporting the format vocabulary with a value of true is - understood to greatly increase code size and in some cases execution time, - and will not be appropriate for all implementations. - -
-
- - Implementations MAY support custom format attributes. Save for agreement between - parties, schema authors SHALL NOT expect a peer implementation to support such - custom format attributes. An implementation MUST NOT fail to collect unknown formats - as annotations. When the Format-Assertion vocabulary is specified, implementations - MUST fail upon encountering unknown formats. - - - Vocabularies do not support specifically declaring different value sets for keywords. - Due to this limitation, and the historically uneven implementation of this keyword, - it is RECOMMENDED to define additional keywords in a custom vocabulary rather than - additional format attributes if interoperability is desired. - -
-
- -
- -
- - These attributes apply to string instances. - - - Date and time format names are derived from - RFC 3339, section 5.6. - The duration format is from the ISO 8601 ABNF as given - in Appendix A of RFC 3339. - - - Implementations supporting formats SHOULD implement support for - the following attributes: - - - A string instance is valid against this attribute if it is - a valid representation according to the "date-time' ABNF rule - (referenced above) - - - A string instance is valid against this attribute if it is - a valid representation according to the "full-date" ABNF rule - (referenced above) - - - A string instance is valid against this attribute if it is - a valid representation according to the "full-time" ABNF rule - (referenced above) - - - A string instance is valid against this attribute if it is - a valid representation according to the "duration" ABNF rule - (referenced above) - - - - - Implementations MAY support additional attributes using the other - format names defined anywhere in that RFC. If "full-date" or "full-time" - are implemented, the corresponding short form ("date" or "time" - respectively) MUST be implemented, and MUST behave identically. - Implementations SHOULD NOT define extension attributes - with any name matching an RFC 3339 format unless it validates - according to the rules of that format. - - There is not currently consensus on the need for supporting - all RFC 3339 formats, so this approach of reserving the - namespace will encourage experimentation without committing - to the entire set. Either the format implementation requirements - will become more flexible in general, or these will likely - either be promoted to fully specified attributes or dropped. - - -
- -
- - These attributes apply to string instances. - - - A string instance is valid against these attributes if it is a valid - Internet email address as follows: - - - As defined by the "Mailbox" ABNF rule in - RFC 5321, section 4.1.2. - - - As defined by the extended "Mailbox" ABNF rule in - RFC 6531, section 3.3. - - - Note that all strings valid against the "email" attribute are also - valid against the "idn-email" attribute. - -
-
- - These attributes apply to string instances. - - - A string instance is valid against these attributes if it is a valid - representation for an Internet hostname as follows: - - - As defined by RFC 1123, section 2.1, - including host names produced using the Punycode algorithm - specified in RFC 5891, section 4.4. - - - As defined by either RFC 1123 as for hostname, or an - internationalized hostname as defined by - RFC 5890, section 2.3.2.3. - - - Note that all strings valid against the "hostname" attribute are also - valid against the "idn-hostname" attribute. - -
- -
- - These attributes apply to string instances. - - - A string instance is valid against these attributes if it is a valid - representation of an IP address as follows: - - - An IPv4 address according to the "dotted-quad" ABNF - syntax as defined in - RFC 2673, section 3.2. - - - An IPv6 address as defined in - RFC 4291, section 2.2. - - - -
- -
- - These attributes apply to string instances. - - - - - A string instance is valid against this attribute if it is - a valid IRI, according to . - - - A string instance is valid against this attribute if it is a valid URI - Reference (either a URI or a relative-reference), - according to . - - - A string instance is valid against this attribute if it is - a valid IRI, according to . - - - A string instance is valid against this attribute if it is a valid IRI - Reference (either an IRI or a relative-reference), - according to . - - - A string instance is valid against this attribute if it is a valid - string representation of a UUID, according to . - - - - - Note that all valid URIs are valid IRIs, and all valid URI References are - also valid IRI References. - - - Note also that the "uuid" format is for plain UUIDs, not UUIDs in URNs. An example - is "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". For UUIDs as URNs, use the "uri" format, - with a "pattern" regular expression of "^urn:uuid:" to indicate the URI scheme and - URN namespace. - -
- -
- - This attribute applies to string instances. - - - A string instance is valid against this attribute if it is a valid URI Template - (of any level), according to . - - - Note that URI Templates may be used for IRIs; there is no separate - IRI Template specification. - -
- -
- - These attributes apply to string instances. - - - - - A string instance is valid against this attribute if it - is a valid JSON string representation of a JSON Pointer, - according to RFC 6901, section 5. - - - A string instance is valid against this attribute if it is a valid - Relative JSON Pointer. - - - To allow for both absolute and relative JSON Pointers, use "anyOf" or - "oneOf" to indicate support for either format. - -
-
- - This attribute applies to string instances. - - - A regular expression, which SHOULD be valid according to the - ECMA-262 regular expression dialect. - - - Implementations that validate formats MUST accept at least the subset of - ECMA-262 defined in the Regular Expressions - section of this specification, and SHOULD accept all valid ECMA-262 expressions. - -
-
-
- -
- -
- - Annotations defined in this section indicate that an instance contains - non-JSON data encoded in a JSON string. - - - These properties provide additional information required to interpret JSON data - as rich multimedia documents. They describe the type of content, how it is encoded, - and/or how it may be validated. They do not function as validation assertions; - a malformed string-encoded document MUST NOT cause the containing instance - to be considered invalid. - - - Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its IRI were present with a value of true. - - - The current IRI for this vocabulary, known as the Content vocabulary, is: - <https://json-schema.org/draft/next/vocab/content>. - - - The current IRI for the corresponding meta-schema is: - . - -
- -
- - Due to security and performance concerns, as well as the open-ended nature of - possible content types, implementations MUST NOT automatically decode, parse, - and/or validate the string contents. Applications are expected to use these - annotations to invoke the appropriate libraries separately. - - - All keywords in this section apply only to strings, and have no - effect on other data types. - -
- -
- - - If the instance value is a string, this property defines that the string - SHOULD be interpreted as encoded binary data and applications wishing - to decode it SHOULD do so using the encoding named by this property. - - - - Possible values indicating base 16, 32, and 64 encodings with several - variations are listed in RFC 4648. Additionally, - sections 6.7 and 6.8 of RFC 2045 provide - encodings used in MIME. This keyword is derived from MIME's - Content-Transfer-Encoding header, which was designed to map binary data - into ASCII characters. It is not related to HTTP's Content-Encoding header, - which is used to encode (e.g. compress or encrypt) - the content of HTTP request and responses. - - - As "base64" is defined in both RFCs, the definition - from RFC 4648 SHOULD be assumed unless the string is specifically intended - for use in a MIME context. Note that all of these encodings result in - strings consisting only of 7-bit ASCII characters. Therefore, this keyword - has no meaning for strings containing characters outside of that range. - - - - If this keyword is absent, but "contentMediaType" is present, this - indicates that the encoding is the identity encoding, meaning that - no transformation was needed in order to represent the content in - a UTF-8 string. - - - - The value of this property MUST be a string. - -
- -
- - If the instance is a string, this property indicates the media type - of the contents of the string. If "contentEncoding" is present, - this property describes the decoded string. - - - The value of this property MUST be a string, which MUST be a media type, - as defined by RFC 2046. - -
- -
- - If the instance is a string, and if "contentMediaType" is present, this - property contains a schema which describes the structure of the string. - - - This keyword MAY be used with any media type that can be mapped into - JSON Schema's data model. Specifying such mappings is outside of the - scope of this specification. - - - The value of this property MUST be a valid JSON schema. It SHOULD be ignored if - "contentMediaType" is not present. Accessing the schema through the schema location - IRI included as part of the annotation will ensure that it is correctly processed - as a subschema. Using the extracted annotation value directly is only safe if - the schema is an embedded resource with both "$schema" and an absolute-IRI "$id". - -
- -
-
- - Here is an example schema, illustrating the use of "contentEncoding" and - "contentMediaType": - - - - - - Instances described by this schema are expected to be strings, - and their values should be interpretable as base64-encoded PNG images. - -
- -
- - Another example: - - - - - - Instances described by this schema are expected to be strings containing HTML, - using whatever character set the JSON string was decoded into. - Per section 8.1 of - RFC 8259, outside of an entirely closed - system, this MUST be UTF-8. - -
- -
- - This example describes a JWT that is MACed using the HMAC SHA-256 - algorithm, and requires the "iss" and "exp" fields in its claim set. - - - - - - Note that "contentEncoding" does not appear. While the "application/jwt" - media type makes use of base64url encoding, that is defined by the media - type, which determines how the JWT string is decoded into a list of two - JSON data structures: first the header, and then the payload. Since the - JWT media type ensures that the JWT can be represented in a JSON string, - there is no need for further encoding or decoding. - -
-
- -
- -
- - These general-purpose annotation keywords provide commonly used information - for documentation and user interface display purposes. They are not intended - to form a comprehensive set of features. Rather, additional vocabularies - can be defined for more complex annotation-based applications. - - - Meta-schemas that do not use "$vocabulary" SHOULD be considered to - require this vocabulary as if its IRI were present with a value of true. - - - The current IRI for this vocabulary, known as the Meta-Data vocabulary, is: - <https://json-schema.org/draft/next/vocab/meta-data>. - - - The current IRI for the corresponding meta-schema is: - . - - -
- - The value of both of these keywords MUST be a string. - - - Both of these keywords can be used to decorate a user interface with - information about the data produced by this user interface. A title will - preferably be short, whereas a description will provide explanation about - the purpose of the instance described by this schema. - -
- -
- - There are no restrictions placed on the value of this keyword. When - multiple occurrences of this keyword are applicable to a single - sub-instance, implementations SHOULD remove duplicates. - - - This keyword can be used to supply a default JSON value associated with a - particular schema. It is RECOMMENDED that a default value be valid against - the associated schema. - -
- -
- - The value of this keyword MUST be a boolean. When multiple occurrences - of this keyword are applicable to a single sub-instance, applications - SHOULD consider the instance location to be deprecated if any occurrence - specifies a true value. - - - If "deprecated" has a value of boolean true, it indicates that applications - SHOULD refrain from usage of the declared property. It MAY mean the property - is going to be removed in the future. - - - A root schema containing "deprecated" with a value of true indicates that - the entire resource being described MAY be removed in the future. - - - The "deprecated" keyword applies to each instance location to which the - schema object containing the keyword successfully applies. This can - result in scenarios where every array item or object property - is deprecated even though the containing array or object is not. - - - Omitting this keyword has the same behavior as a value of false. - -
- -
- - The value of these keywords MUST be a boolean. When multiple occurrences - of these keywords are applicable to a single sub-instance, the resulting - behavior SHOULD be as for a true value if any occurrence specifies a true value, - and SHOULD be as for a false value otherwise. - - - If "readOnly" has a value of boolean true, it indicates that the value - of the instance is managed exclusively by the owning authority, and - attempts by an application to modify the value of this property are - expected to be ignored or rejected by that owning authority. - - - An instance document that is marked as "readOnly" for the entire document - MAY be ignored if sent to the owning authority, or MAY result in an - error, at the authority's discretion. - - - If "writeOnly" has a value of boolean true, it indicates that the value - is never present when the instance is retrieved from the owning authority. - It can be present when sent to the owning authority to update or create - the document (or the resource it represents), but it will not be included - in any updated or newly created version of the instance. - - - An instance document that is marked as "writeOnly" for the entire document - MAY be returned as a blank document of some sort, or MAY produce an error - upon retrieval, or have the retrieval request ignored, at the authority's - discretion. - - - For example, "readOnly" would be used to mark a database-generated serial - number as read-only, while "writeOnly" would be used to mark a password - input field. - - - These keywords can be used to assist in user interface instance generation. - In particular, an application MAY choose to use a widget that hides - input values as they are typed for write-only fields. - - - Omitting these keywords has the same behavior as values of false. - -
- -
- - The value of this keyword MUST be an array. - There are no restrictions placed on the values within the array. - When multiple occurrences of this keyword are applicable to a single - sub-instance, implementations MUST provide a flat array of all - values rather than an array of arrays. - - - This keyword can be used to provide sample JSON values associated with a - particular schema, for the purpose of illustrating usage. It is - RECOMMENDED that these values be valid against the associated schema. - - - Implementations MAY use the value(s) of "default", if present, as - an additional example. If "examples" is absent, "default" - MAY still be used in this manner. - -
-
- -
- - JSON Schema validation defines a vocabulary for JSON Schema core and concerns all - the security considerations listed there. - - - JSON Schema validation allows the use of Regular Expressions, which have numerous - different (often incompatible) implementations. - Some implementations allow the embedding of arbitrary code, which is outside the - scope of JSON Schema and MUST NOT be permitted. - Regular expressions can often also be crafted to be extremely expensive to compute - (with so-called "catastrophic backtracking"), resulting in a denial-of-service - attack. - - - Implementations that support validating or otherwise evaluating instance - string data based on "contentEncoding" and/or "contentMediaType" are at - risk of evaluating data in an unsafe way based on misleading information. - Applications can mitigate this risk by only performing such processing - when a relationship between the schema and instance is established - (e.g., they share the same authority). - - - Processing a media type or encoding is subject to the security considerations - of that media type or encoding. For example, the security considerations - of RFC 4329 Scripting Media Types apply when - processing JavaScript or ECMAScript encoded within a JSON string. - -
- - - - - - - - &RFC2119; - &RFC1123; - &RFC2045; - &RFC2046; - &RFC2673; - &RFC3339; - &RFC3986; - &RFC3987; - &RFC4122; - &RFC4291; - &RFC4648; - &RFC5321; - &RFC5890; - &RFC5891; - &RFC6570; - &RFC6531; - &RFC6901; - &RFC8259; - - - ECMA-262, 11th edition specification - - - - - - - Relative JSON Pointers - - - - - Cloudflare, Inc. - - - - - - - - - - JSON Schema: A Media Type for Describing JSON Documents - - - - - - - - - - - - - - - - - - - - &RFC4329; - - -
- - Several keywords have been moved from this document into the - Core Specification starting with draft 2019-09, - in some cases with re-naming or other changes. This affects the following former - validation keywords: - - - Renamed to "$defs" to match "$ref" and be shorter to type. - Schema vocabulary authors SHOULD NOT define a "definitions" keyword - with different behavior in order to avoid invalidating schemas that - still use the older name. While "definitions" is absent in the - single-vocabulary meta-schemas referenced by this document, it - remains present in the default meta-schema, and implementations - SHOULD assume that "$defs" and "definitions" have the same - behavior when that meta-schema is used. - - - All of these keywords apply subschemas to the instance and combine - their results, without asserting any conditions of their own. - Without assertion keywords, these applicators can only cause assertion - failures by using the false boolean schema, or by inverting the result - of the true boolean schema (or equivalent schema objects). - For this reason, they are better defined as a generic mechanism on which - validation, hyper-schema, and extension vocabularies can all be based. - - - These keywords modify the behavior of "contains", and are therefore - grouped with it in the applicator vocabulary. - - - This keyword had two different modes of behavior, which made it - relatively challenging to implement and reason about. - The schema form has been moved to Core and renamed to - "dependentSchemas", as part of the applicator vocabulary. - It is analogous to "properties", except that instead of applying - its subschema to the property value, it applies it to the object - containing the property. - The property name array form is retained here and renamed to - "dependentRequired", as it is an assertion which is a shortcut - for the conditional use of the "required" assertion keyword. - - - -
- -
- - Thanks to - Gary Court, - Francis Galiegue, - Kris Zyp, - Geraint Luff, - and Henry Andrews - for their work on the initial drafts of JSON Schema. - - - Thanks to - Jason Desrosiers, - Daniel Perrett, - Erik Wilde, - Evgeny Poberezkin, - Brad Bowman, - Gowry Sankar, - Donald Pipowitch, - Dave Finlay, - Denis Laxalde, - Phil Sturgeon, - Shawn Silverman, - and Karen Etheridge - for their submissions and patches to the document. - -
- -
- - This section to be removed before leaving Internet-Draft status. - - - - - - Use IRIs instead of URIs - - - - - Improve and clarify the "minContains" keyword explanation - Remove the use of "production" in favour of "ABNF rule" - - - - - Correct email format RFC reference to 5321 instead of 5322 - Clarified the set and meaning of "contentEncoding" values - Reference ECMA-262, 11th edition for regular expression support - Split "format" into an annotation only vocabulary and an assertion vocabulary - Clarify "deprecated" when applicable to arrays - - - - - Grouped keywords into formal vocabularies - Update "format" implementation requirements in terms of vocabularies - By default, "format" MUST NOT be validated, although validation can be enabled - A vocabulary declaration can be used to require "format" validation - Moved "definitions" to the core spec as "$defs" - Moved applicator keywords to the core spec - Renamed the array form of "dependencies" to "dependentRequired", moved the schema form to the core spec - Specified all "content*" keywords as annotations, not assertions - Added "contentSchema" to allow applying a schema to a string-encoded document - Also allow RFC 4648 encodings in "contentEncoding" - Added "minContains" and "maxContains" - Update RFC reference for "hostname" and "idn-hostname" - Add "uuid" and "duration" formats - - - - - This draft is purely a clarification with no functional changes - Provided the general principle behind ignoring annotations under "not" and similar cases - Clarified "if"/"then"/"else" validation interactions - Clarified "if"/"then"/"else" behavior for annotation - Minor formatting and cross-referencing improvements - - - - - Added "if"/"then"/"else" - Classify keywords as assertions or annotations per the core spec - Warn of possibly removing "dependencies" in the future - Grouped validation keywords into sub-sections for readability - Moved "readOnly" from hyper-schema to validation meta-data - Added "writeOnly" - Added string-encoded media section, with former hyper-schema "media" keywords - Restored "regex" format (removal was unintentional) - Added "date" and "time" formats, and reserved additional RFC 3339 format names - I18N formats: "iri", "iri-reference", "idn-hostname", "idn-email" - Clarify that "json-pointer" format means string encoding, not URI fragment - Fixed typo that inverted the meaning of "minimum" and "exclusiveMinimum" - Move format syntax references into Normative References - JSON is a normative requirement - - - - - Standardized on hyphenated format names with full words ("uriref" becomes "uri-reference") - Add the formats "uri-template" and "json-pointer" - Changed "exclusiveMaximum"/"exclusiveMinimum" from boolean modifiers of "maximum"/"minimum" to independent numeric fields. - Split the additionalItems/items into two sections - Reworked properties/patternProperties/additionalProperties definition - Added "examples" keyword - Added "contains" keyword - Allow empty "required" and "dependencies" arrays - Fixed "type" reference to primitive types - Added "const" keyword - Added "propertyNames" keyword - - - - - Added additional security considerations - Removed reference to "latest version" meta-schema, use numbered version instead - Rephrased many keyword definitions for brevity - Added "uriref" format that also allows relative URI references - - - - - Initial draft. - Salvaged from draft v3. - Redefine the "required" keyword. - Remove "extends", "disallow" - Add "anyOf", "allOf", "oneOf", "not", "definitions", "minProperties", - "maxProperties". - "dependencies" member values can no longer be single strings; at - least one element is required in a property dependency array. - Rename "divisibleBy" to "multipleOf". - "type" arrays can no longer have schemas; remove "any" as a possible - value. - Rework the "format" section; make support optional. - "format": remove attributes "phone", "style", "color"; rename - "ip-address" to "ipv4"; add references for all attributes. - Provide algorithms to calculate schema(s) for array/object - instances. - Add interoperability considerations. - - - - -
- - diff --git a/package.json b/package.json new file mode 100644 index 00000000..866e2d8c --- /dev/null +++ b/package.json @@ -0,0 +1,33 @@ +{ + "name": "json-schema-org/json-schema-spec", + "version": "1.0.0", + "description": "The JSON Schema Specification", + "type": "module", + "main": "index.js", + "scripts": { + "lint": "eslint *.js", + "build": "npm run build-core && npm run build-validation", + "build-core": "node build/build.js < jsonschema-core.md > jsonschema-core.html", + "build-validation": "node build/build.js < jsonschema-validation.md > jsonschema-validation.html" + }, + "license": "MIT", + "dependencies": { + "rehype-autolink-headings": "^6.1.1", + "rehype-slug": "^5.1.0", + "rehype-stringify": "^9.0.3", + "remark": "^14.0.3", + "remark-flexible-containers": "^1.0.6", + "remark-gfm": "^3.0.1", + "remark-preset-lint-markdown-style-guide": "^5.1.3", + "remark-rehype": "^10.1.0", + "remark-toc": "^8.0.1", + "remark-torchlight": "^0.0.5", + "vfile-reporter": "^8.0.0" + }, + "devDependencies": { + "dotenv": "^16.3.1", + "eslint": "*", + "eslint-import-resolver-node": "*", + "eslint-plugin-import": "*" + } +} From b97bf362d7ddfbf91dc0e4b491dca2479e7bb903 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Fri, 28 Jul 2023 16:06:39 -0700 Subject: [PATCH 490/780] Auto number appendices and other cleanup --- README.md | 2 ++ build/build.js | 30 ++++++++++------ build/remark-number-headings.js | 26 ++++++++++---- jsonschema-core.md | 63 ++++++++++++++------------------- jsonschema-validation.md | 22 ++++-------- package.json | 7 ++-- 6 files changed, 76 insertions(+), 74 deletions(-) diff --git a/README.md b/README.md index 73a6da2d..c8e013e7 100644 --- a/README.md +++ b/README.md @@ -38,6 +38,8 @@ features they make available to you. - [remark-lint](https://github.com/remarkjs/remark-lint) -- Enforce markdown styles guide. +- [remark-validate-links](https://github.com/remarkjs/remark-validate-links) -- + Check for broken links. - [remark-gfm](https://github.com/remarkjs/remark-gfm) -- Adds support for Github Flavored Markdown specific markdown features such as autolink literals, footnotes, strikethrough, tables, and tasklists. diff --git a/build/build.js b/build/build.js index 403d7660..8f888480 100644 --- a/build/build.js +++ b/build/build.js @@ -1,18 +1,18 @@ -/* eslint-disable no-console */ import dotenv from "dotenv"; import { readFileSync, writeFileSync } from "node:fs"; import { reporter } from "vfile-reporter"; import { remark } from "remark"; -import remarkPresetLintMarkdownStyleGuide from "remark-preset-lint-markdown-style-guide"; -import remarkGfm from "remark-gfm"; -import remarkToc from "remark-toc"; -import torchLight from "remark-torchlight"; -import remarkRehype from "remark-rehype"; -import rehypeSlug from "rehype-slug"; import rehypeAutolinkHeadings from "rehype-autolink-headings"; +import rehypeSlug from "rehype-slug"; import rehypeStringify from "rehype-stringify"; -import remarkNumberHeadings from "./remark-number-headings.js"; import remarkFlexibleContainers from "remark-flexible-containers"; +import remarkGfm from "remark-gfm"; +import remarkNumberHeadings from "./remark-number-headings.js"; +import remarkPresetLintMarkdownStyleGuide from "remark-preset-lint-markdown-style-guide"; +import remarkRehype from "remark-rehype"; +import remarkToc from "remark-toc"; +import remarkValidateLinks from "remark-validate-links"; +import torchLight from "remark-torchlight"; dotenv.config(); @@ -22,10 +22,20 @@ dotenv.config(); const html = await remark() .use(remarkPresetLintMarkdownStyleGuide) .use(remarkGfm) - .use(remarkNumberHeadings, { startDepth: 2, skip: ["Abstract", "Note to Readers", "Table of Contents"] }) - .use(remarkToc, { tight: true, heading: "Table of Contents" }) .use(torchLight) .use(remarkFlexibleContainers) + .use(remarkNumberHeadings, { + startDepth: 2, + skip: ["Abstract", "Note to Readers", "Table of Contents", "Authors' Addresses", "\\[.*\\]", "draft-.*"], + appendixToken: "[Appendix]", + appendixPrefix: "Appendix" + }) + .use(remarkToc, { + tight: true, + heading: "Table of Contents", + skip: "\\[.*\\]|draft-.*" + }) + .use(remarkValidateLinks) .use(remarkRehype) .use(rehypeSlug) .use(rehypeAutolinkHeadings, { behavior: "wrap" }) diff --git a/build/remark-number-headings.js b/build/remark-number-headings.js index 8517e042..30800774 100644 --- a/build/remark-number-headings.js +++ b/build/remark-number-headings.js @@ -8,6 +8,7 @@ const defaultOptions = { const remarkNumberHeadings = (options) => (tree) => { options = { ...defaultOptions, ...options }; + options.skip = new RegExp(`^(${options.skip.join("|")})$`, "u"); let sectionNumbers = []; @@ -17,17 +18,28 @@ const remarkNumberHeadings = (options) => (tree) => { } visit(node, "text", (textNode) => { - const text = textNode.value ? textNode.value.trim() : ""; + let text = textNode.value ? textNode.value.trim() : ""; - if (options.skip.includes(text)) { + if (options.skip.test(text)) { return; } - sectionNumbers[node.depth] = (sectionNumbers[node.depth] ?? 0) + 1; - sectionNumbers = sectionNumbers.slice(0, node.depth + 1); - - const sectionNumber = sectionNumbers.slice(options.startDepth, node.depth + 1).join("."); - textNode.value = `${sectionNumber}. ${text}`; + if (text.startsWith(options.appendixToken)) { + const currentIndex = typeof sectionNumbers[node.depth] === "string" + ? sectionNumbers[node.depth] + : "@"; + sectionNumbers[node.depth] = String.fromCharCode(currentIndex.charCodeAt(0) + 1); + sectionNumbers = sectionNumbers.slice(0, node.depth + 1); + + const sectionNumber = sectionNumbers.slice(options.startDepth, node.depth + 1).join("."); + textNode.value = `${options.appendixPrefix} ${sectionNumber}. ${text.slice(options.appendixToken.length + 1)}`; + } else { + sectionNumbers[node.depth] = (sectionNumbers[node.depth] ?? 0) + 1; + sectionNumbers = sectionNumbers.slice(0, node.depth + 1); + + const sectionNumber = sectionNumbers.slice(options.startDepth, node.depth + 1).join("."); + textNode.value = `${sectionNumber}. ${text}`; + } }); }); }; diff --git a/jsonschema-core.md b/jsonschema-core.md index 09ee2bcb..b75e4405 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -2768,7 +2768,7 @@ Bray, T., Ed., Hollander, D., Ed., Layman, A., Ed., and R. Tobin, Ed., "Namespaces in XML 1.1 (Second Edition)", August 2006, <>. -## Appendix A. Schema identification examples +## [Appendix] Schema identification examples Consider the following schema, which shows `$id` being used to identify both the root schema and various subschemas, and `$anchor` being used to define plain name fragment identifiers. @@ -2841,12 +2841,12 @@ embedded schema resources](#921-json-pointer-fragments-and-embedded-schema-resources) section for futher comments. -## Appendix B. Manipulating schema documents and references +## [Appendix] Manipulating schema documents and references Various tools have been created to rearrange schema documents based on how and where references (`$ref`) appear. This appendix discusses which use cases and actions are compliant with this specification. -### B.1. Bundling schema resources into a single document +### Bundling schema resources into a single document A set of schema resources intended for use together can be organized with each in its own schema document, all in the same schema document, or any granularity of document grouping in between. @@ -2868,7 +2868,7 @@ changing any aspect of validation or annotation results. The names of the schemas under `$defs` do not affect behavior, assuming they are each unique, as they do not appear in the canonical IRIs for the embedded resources. -### B.2. Reference removal is not always safe +### Reference removal is not always safe Attempting to remove all references and produce a single schema document does not, in all cases, produce a schema with identical behavior to the original form. @@ -2880,7 +2880,7 @@ scope of this specification to determine or provide a set of safe `$ref` removal transformations, as they depend not only on the schema structure but also on the intended usage. -## Appendix C. Example of recursive schema extension +## [Appendix] Example of recursive schema extension Consider the following two schemas describing a simple recursive tree structure, where each node in the tree can have a "data" field of any type. The first schema allows and ignores other instance properties. The second is more strict @@ -2976,9 +2976,9 @@ of the node schema objects were moved under `$defs`. It is the matching `$dynamicAnchor` values which tell us how to resolve the dynamic reference, not any sort of correlation in JSON structure. -## Appendix D. Working with vocabularies +## [Appendix] Working with vocabularies -### D.1. Best practices for vocabulary and meta-schema authors +### Best practices for vocabulary and meta-schema authors Vocabulary authors should take care to avoid keyword name collisions if the vocabulary is intended for broad use, and potentially combined with other vocabularies. JSON Schema does not provide any formal namespacing system, but @@ -3026,7 +3026,7 @@ resulting behavior is undefined. Meta-schemas intended for local use, with no need to test for vocabulary support in arbitrary implementations, can safely omit `$vocabulary` entirely. -### D.2. Example meta-schema with vocabulary declarations +### Example meta-schema with vocabulary declarations This meta-schema explicitly declares both the Core and Applicator vocabularies, together with an extension vocabulary, and combines their meta-schemas with an `allOf`. The extension vocabulary's meta-schema, which describes only the @@ -3118,7 +3118,7 @@ to ensure that it is validated even when `format` functions purely as an annotation, as explained in the [Validation specification](#json-schema-validation). -## Appendix E. References and generative use cases +## [Appendix] References and generative use cases While the presence of references is expected to be transparent to validation results, generative use cases such as code generators and UI renderers often consider references to be semantically significant. @@ -3167,7 +3167,7 @@ instance of a distinct class. This style of usage requires the annotation to be in the same object as the reference, which must be recognizable as a reference. -## Appendix F. Acknowledgments +## [Appendix] Acknowledgments Thanks to Gary Court, Francis Galiegue, Kris Zyp, Geraint Luff, and Henry Andrews for their work on the initial drafts of JSON Schema. @@ -3176,16 +3176,16 @@ Bowman, Gowry Sankar, Donald Pipowitch, Dave Finlay, Denis Laxalde, Phil Sturgeon, Shawn Silverman, and Karen Etheridge for their submissions and patches to the document. -## Appendix G. Change Log[^19] +## [Appendix] Change Log[^19] [^19]: This section to be removed before leaving Internet-Draft status. -### G.1. draft-bhutton-json-schema-next +### draft-bhutton-json-schema-next - `contains` now applies to objects as well as arrays - Use IRIs instead of URIs - Remove bookending requirement for `$dynamicRef` - Add `propertyDependencies` keyword -### G.2. draft-bhutton-json-schema-01 +### draft-bhutton-json-schema-01 - Improve and clarify the `type`, `contains`, `unevaluatedProperties`, and `unevaluatedItems` keyword explanations - Clarify various aspects of "canonical URIs" @@ -3194,7 +3194,7 @@ to the document. - Remove references to remaining media-type parameters - Fix multiple examples -### G.3. draft-bhutton-json-schema-00 +### draft-bhutton-json-schema-00 - `$schema` MAY change for embedded resources - Array-value `items` functionality is now `prefixItems` - `items` subsumes the old function of `additionalItems` @@ -3211,7 +3211,7 @@ interactions now specified - Moved `unevaluatedItems` and `unevaluatedProperties` from core into their own vocabulary -### G.4. draft-handrews-json-schema-02 +### draft-handrews-json-schema-02 - Update to RFC 8259 for JSON specification - Moved `definitions` from the Validation specification here as `$defs` - Moved applicator keywords from the Validation specification as their own @@ -3237,7 +3237,7 @@ meta-schemas - Clarified that the behavior of JSON Pointers across `$id` boundary is unreliable -### G.5. draft-handrews-json-schema-01 +### draft-handrews-json-schema-01 - This draft is purely a clarification with no functional changes - Emphasized annotations as a primary usage of JSON Schema - Clarified $id by use cases @@ -3250,7 +3250,7 @@ schema identifiers during parsing same process - Minor formatting improvements -### G.6. draft-handrews-json-schema-00 +### draft-handrews-json-schema-00 - Make the concept of a schema keyword vocabulary more clear - Note that the concept of "integer" is from a vocabulary, not the data model - Classify keywords as assertions or annotations and describe their general @@ -3262,7 +3262,7 @@ behavior - Add `application/schema-instance+json` media type - Recommend a "schema" link relation / parameter instead of "profile" -### G.7. draft-wright-json-schema-01 +### draft-wright-json-schema-01 - Updated intro - Allowed for any schema to be a boolean - `$schema` SHOULD NOT appear in subschemas, although that may change @@ -3271,7 +3271,7 @@ behavior - Note applicability to formats such as CBOR that can be represented in the JSON data model -### G.8. draft-wright-json-schema-00 +### draft-wright-json-schema-00 - Updated references to JSON - Updated references to HTTP - Updated references to JSON Pointer @@ -3286,7 +3286,7 @@ data model - Rewrote section on usage with rel="describedBy" and rel="profile" - Fixed numerous invalid examples -### G.9. draft-zyp-json-schema-04 +### draft-zyp-json-schema-04 - Salvaged from draft v3. - Split validation keywords into separate document. - Split hypermedia keywords into separate document. @@ -3295,23 +3295,12 @@ data model - Define the role of `id`. Define URI resolution scope. - Add interoperability considerations. -### G.10. draft-zyp-json-schema-00 +### draft-zyp-json-schema-00 - Initial draft. ## Authors' Addresses - -### Austin Wright (*editor*) -Email: - -### Ben Hutton (*editor*) -Postman - -Email: - -URI: - -### Greg Dennis - -Email: - -URI: +| Author | Company | Email | URI | +|--------------------------|---------|-------------------------|----------------------------------| +| Austin Wright (*editor*) | | | | +| Ben Hutton (*editor*) | Postman | | | +| Greg Dennis | | | | diff --git a/jsonschema-validation.md b/jsonschema-validation.md index f22c50ec..7a4777b3 100644 --- a/jsonschema-validation.md +++ b/jsonschema-validation.md @@ -895,7 +895,7 @@ draft-bhutton-json-schema-01, June 2022, Hoehrmann, B., "Scripting Media Types", RFC 4329, DOI 10.17487/RFC4329, April 2006, <>. -## Appendix A. Keywords Moved from Validation to Core +## [Appendix] Keywords Moved from Validation to Core Several keywords have been moved from this document into the [Core Specification](#json-schema) starting with draft 2019-09, in some cases with re-naming or other changes. This affects the following former validation @@ -928,7 +928,7 @@ property. The property name array form is retained here and renamed to `dependentRequired`, as it is an assertion which is a shortcut for the conditional use of the `required` assertion keyword. -## Appendix B. Acknowledgments +## [Appendix] Acknowledgments Thanks to Gary Court, Francis Galiegue, Kris Zyp, Geraint Luff, and Henry Andrews for their work on the initial drafts of JSON Schema. @@ -937,7 +937,7 @@ Bowman, Gowry Sankar, Donald Pipowitch, Dave Finlay, Denis Laxalde, Phil Sturgeon, Shawn Silverman, and Karen Etheridge for their submissions and patches to the document. -## Appendix C. ChangeLog[^6] +## [Appendix] ChangeLog[^6] [^6]: This section to be removed before leaving Internet-Draft status. - *draft-next* @@ -1032,15 +1032,7 @@ schema form to the core spec - Add interoperability considerations. ## Authors' Addresses - -### Austin Wright (*editor*) - -Email: - -### Ben Hutton (*editor*) - -Postman - -Email: - -URI: +| Author | Company | Email | URI | +|--------------------------|---------|----------------------|--------------------------| +| Austin Wright (*editor*) | | | | +| Ben Hutton (*editor*) | Postman | | | diff --git a/package.json b/package.json index 866e2d8c..fcf5d44f 100644 --- a/package.json +++ b/package.json @@ -5,7 +5,6 @@ "type": "module", "main": "index.js", "scripts": { - "lint": "eslint *.js", "build": "npm run build-core && npm run build-validation", "build-core": "node build/build.js < jsonschema-core.md > jsonschema-core.html", "build-validation": "node build/build.js < jsonschema-validation.md > jsonschema-validation.html" @@ -22,12 +21,10 @@ "remark-rehype": "^10.1.0", "remark-toc": "^8.0.1", "remark-torchlight": "^0.0.5", + "remark-validate-links": "^12.1.1", "vfile-reporter": "^8.0.0" }, "devDependencies": { - "dotenv": "^16.3.1", - "eslint": "*", - "eslint-import-resolver-node": "*", - "eslint-plugin-import": "*" + "dotenv": "^16.3.1" } } From eb336201dca29da57102eca1db9b6e07432d8df3 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Fri, 28 Jul 2023 23:08:22 -0700 Subject: [PATCH 491/780] Add markdown syntax for section links --- build/build.js | 6 ++ build/remark-section-links.js | 43 ++++++++++++++ jsonschema-core.md | 105 ++++++++++++++++------------------ jsonschema-validation.md | 9 ++- package.json | 2 + 5 files changed, 105 insertions(+), 60 deletions(-) create mode 100644 build/remark-section-links.js diff --git a/build/build.js b/build/build.js index 8f888480..ddc39d7c 100644 --- a/build/build.js +++ b/build/build.js @@ -7,9 +7,12 @@ import rehypeSlug from "rehype-slug"; import rehypeStringify from "rehype-stringify"; import remarkFlexibleContainers from "remark-flexible-containers"; import remarkGfm from "remark-gfm"; +import remarkHeadingId from "remark-heading-id"; +import remarkHeadings from "@vcarl/remark-headings"; import remarkNumberHeadings from "./remark-number-headings.js"; import remarkPresetLintMarkdownStyleGuide from "remark-preset-lint-markdown-style-guide"; import remarkRehype from "remark-rehype"; +import remarkSectionLinks from "./remark-section-links.js"; import remarkToc from "remark-toc"; import remarkValidateLinks from "remark-validate-links"; import torchLight from "remark-torchlight"; @@ -24,12 +27,15 @@ dotenv.config(); .use(remarkGfm) .use(torchLight) .use(remarkFlexibleContainers) + .use(remarkHeadingId) .use(remarkNumberHeadings, { startDepth: 2, skip: ["Abstract", "Note to Readers", "Table of Contents", "Authors' Addresses", "\\[.*\\]", "draft-.*"], appendixToken: "[Appendix]", appendixPrefix: "Appendix" }) + .use(remarkHeadings) + .use(remarkSectionLinks) .use(remarkToc, { tight: true, heading: "Table of Contents", diff --git a/build/remark-section-links.js b/build/remark-section-links.js new file mode 100644 index 00000000..1c41e042 --- /dev/null +++ b/build/remark-section-links.js @@ -0,0 +1,43 @@ +import { visit } from "unist-util-visit"; + + +const sectionLink = /\{\{(?.*?)\}\}/u; + +const remarkSectionLinks = (options) => (tree, vfile) => { + // Heading data comes from @vcarl/remark-headings + const headings = {}; + for (const heading of vfile.data.headings) { + if (heading?.data?.id) { + headings[heading.data.id] = heading.value; + } + } + + visit(tree, "text", (node, index, parent) => { + const match = node.value.match(sectionLink); + + if (match) { + if (!(match.groups.id in headings)) { + throw Error(`SectionLinkError: No header found with id "${match.groups.id}"`) + } + const headerText = headings[match.groups.id]; + + const beforeNode = { type: "text", value: node.value.slice(0, match.index) }; + const afterNode = { type: "text", value: node.value.slice(match.index + match[0].length) }; + const linkNode = { + type: "link", + title: headerText, + url: `#${match.groups.id}`, + children: [ + { + type: "text", + value: "Section " + headerText.slice(0, headerText.indexOf(". ")) + } + ] + }; + + parent.children.splice(index, 1, beforeNode, linkNode, afterNode); + } + }); +}; + +export default remarkSectionLinks; diff --git a/jsonschema-core.md b/jsonschema-core.md index b75e4405..83997d53 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -92,7 +92,7 @@ A JSON document is an information resource (series of octets) described by the In JSON Schema, the terms "JSON document", "JSON text", and "JSON value" are interchangeable because of the data model it defines in -[Section 4.2.1](#421-instance-data-model). +{{instance-data-model}}. JSON Schema is only defined over JSON documents. However, any document or memory structure that can be parsed into or processed according to the JSON Schema data @@ -109,7 +109,7 @@ including media types with the `+json` structured syntax suffix. Among these, this specification defines the `application/schema-instance+json` media type which defines handling for fragments in the IRI. -#### Instance Data Model +#### Instance Data Model {#instance-data-model} JSON Schema interprets documents according to a data model. A JSON value interpreted according to this data model is called an "instance". @@ -219,7 +219,7 @@ companions, are free to define other behaviors as well. A JSON Schema MAY contain properties which are not schema keywords or are not recognized as schema keywords. The behavior of such keywords is governed by -[Section 6.5.2](#652-handling-of-unrecognized-or-unsupported-keywords). +{{unknown-keywords}}. An empty schema is a JSON Schema with no properties. @@ -281,7 +281,7 @@ in another. Any such IRIs with fragments are considered to be non-canonical. The root schema is the schema that comprises the entire JSON document in question. The root schema is always a schema resource, where the IRI is -determined as described in [Section 9.1.1](#911-initial-base-iri).[^1] +determined as described in {{initial-base-iri}}.[^1] [^1]: Note that documents that embed schemas in another format will not have a root schema resource in this sense. Exactly how such usages fit with the JSON @@ -303,7 +303,7 @@ schema titled "root" is the root schema. As with the root schema, a subschema is either an object or a boolean. -As discussed in [Section 8.2.1](#821-the-id-keyword), a JSON Schema document +As discussed in {{id-keyword}}, a JSON Schema document can contain multiple JSON Schema resources. When used without qualification, the term "root schema" refers to the document's root schema. In some cases, resource root schemas are discussed. A resource's root schema is its top-level @@ -313,7 +313,7 @@ to be extracted to a standalone JSON Schema document. Whether multiple schema resources are embedded or linked with a reference, they are processed in the same way, with the same available behaviors. -## Fragment Identifiers +## Fragment Identifiers {#fragment-identifiers} In accordance with section 3.1 of [RFC 6839](#rfc6839), the syntax and semantics of fragment identifiers specified for any +json media type SHOULD be as specified for `application/json`. (At publication of this document, there is no @@ -420,7 +420,7 @@ any way other than annotation collection. Consequently, the "x-" prefix is reserved for this purpose, and extension vocabularies MUST NOT define any keywords which begin with this prefix. -#### Handling of unrecognized or unsupported keywords +#### Handling of unrecognized or unsupported keywords {#unknown-keywords} Implementations SHOULD treat keywords they do not recognize, or that they recognize but do not support, as annotations, where the value of the keyword is the value of the annotation. Whether an implementation collects these @@ -445,9 +445,9 @@ applicator keywords are processed until a schema object with no applicators (and therefore no subschemas) is reached. The appropriate location in the instance is evaluated against the assertion and annotation keywords in the schema object. The interactions of those keyword results to produce the schema object results -are governed by [Section 7.7.1.2](#7712-annotations-and-assertions), while the +are governed by {{annotations-and-assertions}}, while the relationship of subschema results to the results of the applicator keyword that -applied them is described by [Section 7.5](#75-applicators). +applied them is described by {{applicators}}. Evaluation of a parent schema object can complete once all of its subschemas have been evaluated, although in some circumstances evaluation may be @@ -507,7 +507,7 @@ keywords MUST NOT result in a circular dependency. Keywords MAY modify their behavior based on the presence or absence of another keyword in the same [schema object](#43-json-schema-documents). -### Default Behaviors +### Default Behaviors {#default-behaviors} A missing keyword MUST NOT produce a false assertion result, MUST NOT produce annotation results, and MUST NOT cause any other schema to be evaluated as part of its own behavioral definition. However, given that missing keywords do not @@ -546,7 +546,7 @@ care not to disrupt the functioning of core keywords. For example, the to the matching `$dynamicRef` keyword, leaving the behavior of `$ref` undisturbed. -### Applicators +### Applicators {#applicators} Applicators allow for building more complex schemas than can be accomplished with a single schema object. Evaluation of an instance against a [schema document](#43-json-schema-documents) begins by applying the [root @@ -567,12 +567,12 @@ operation to the assertion results of subschemas, but MUST NOT introduce new assertion conditions of their own. [Annotation](#77-annotations) results from subschemas are preserved in -accordance with [Section 7.7.1](#771-collecting-annotations) so that +accordance with {{collecting-annotations}} so that applications can decide how to interpret multiple values. Applicator keywords do not play a direct role in this preservation. #### Referenced and Referencing Schemas -As noted in [Section 7.5](#75-applicators), an applicator keyword may refer to a +As noted in {{applicators}}, an applicator keyword may refer to a schema to be applied, rather than including it as a subschema in the applicator's value. In such situations, the schema being applied is known as the referenced schema, while the schema containing the applicator keyword is the @@ -657,7 +657,7 @@ even if they cannot change the overall assertion result. The only exception is that subschemas of a schema object that has failed validation MAY be skipped, as annotations are not retained for failing schemas. -#### Collecting Annotations +#### Collecting Annotations {#collecting-annotations} Annotations are collected by keywords that explicitly define annotation-collecting behavior. Note that boolean schemas cannot produce annotations as they do not make use of keywords. @@ -752,7 +752,7 @@ might take. For example, an application may consider the presence of two different values for `default` to be an error, regardless of their schema locations. -##### Annotations and Assertions +##### Annotations and Assertions {#annotations-and-assertions} Schema objects that produce a false assertion result MUST NOT produce any annotation results, whether from their own keywords or from keywords in subschemas. @@ -787,10 +787,10 @@ re-use. These keywords do not affect validation or annotation results. Their purpose in the core vocabulary is to ensure that locations are available for certain purposes and will not be redefined by extension keywords. -While these keywords do not directly affect results, as explained in [Section -9.4.2](#942-references-to-possible-non-schemas) unrecognized extension keywords -that reserve locations for re-usable schemas may have undesirable interactions -with references in certain circumstances. +While these keywords do not directly affect results, as explained in +{{non-schema-references}} unrecognized extension keywords that reserve +locations for re-usable schemas may have undesirable interactions with +references in certain circumstances. ### Loading Instance Data While none of the vocabularies defined as part of this or the associated @@ -803,7 +803,7 @@ examine parts of an instance outside the current evaluation location. Keywords that allow adjusting the location using a Relative JSON Pointer SHOULD default to using the current location if a default is desireable. -## The JSON Schema Core Vocabulary +## The JSON Schema Core Vocabulary {#core-vocabulary} Keywords declared in this section, which all begin with "$", make up the JSON Schema Core vocabulary. These keywords are either required in order to process any schema or meta-schema, including those split across multiple documents, or @@ -919,7 +919,7 @@ through `$schema`, through appropriately defined media type parameters or link relation types, or through documented default implementation-defined behavior in the absence of an explicit meta-schema. If a meta-schema does not contain `$vocabulary`, the set of vocabularies in use is determined according to -[Section 8.1.2.4](#8124-default-vocabularies). +{{default-vocabularies}}. Any vocabulary in use by a schema and understood by the implementation MUST be processed in a manner consistent with the semantic definitions contained within @@ -927,22 +927,20 @@ the vocabulary, regardless of whether that vocabulary is required or optional. Any vocabulary that is not present in `$vocabulary` MUST NOT be made available for use in schemas described by that meta-schema, except for the core vocabulary -as specified by the introduction to [Section -8](#8-the-json-schema-core-vocabulary). +as specified by the introduction to {{core-vocabulary}}. Implementations that do not support a vocabulary required by a schema MUST refuse to process that schema. Implementations that do not support a vocabulary that is optionally used by a schema SHOULD proceed with processing the schema. The keywords will be -considered to be unrecognized keywords as addressed by [Section -6.5.2](#652-handling-of-unrecognized-or-unsupported-keywords). Note that since -the recommended behavior for such keywords is to collect them as annotations, -vocabularies consisting only of annotations will have the same behavior when -used optionally whether the implementation supports them or not. This allows -annotation-only vocabularies to be supported without custom code, even in -implementations that do not support providing custom code for extension -vocabularies. +considered to be unrecognized keywords as addressed by +{{unknown-keywords}}. Note that since the recommended behavior for such +keywords is to collect them as annotations, vocabularies consisting only of +annotations will have the same behavior when used optionally whether the +implementation supports them or not. This allows annotation-only vocabularies to +be supported without custom code, even in implementations that do not support +providing custom code for extension vocabularies. ##### Vocabularies are schema resource-scoped The `$vocabulary` keyword SHOULD be used in the root schema of any schema @@ -967,7 +965,7 @@ extension vocabularies. Guidance regarding vocabularies with identically-named keywords is provided in [Appendix D.1](#d1-best-practices-for-vocabulary-and-meta-schema-authors). -##### Default vocabularies +##### Default vocabularies {#default-vocabularies} If `$vocabulary` is absent, an implementation MAY determine behavior based on the meta-schema if it is recognized from the IRI value of the referring schema's `$schema` keyword. This is how behavior (such as Hyper-Schema usage) has been @@ -1012,7 +1010,7 @@ Several keywords can accept a relative [IRI-reference](#rfc3987), or a value used to construct a relative IRI-reference. For these keywords, it is necessary to establish a base IRI in order to resolve the reference. -#### The $id Keyword +#### The $id Keyword {#id-keyword} The `$id` keyword identifies a schema resource with its [canonical](#rfc6596) IRI. @@ -1037,11 +1035,11 @@ a relative IRI-reference, the base IRI for resolving that reference is the IRI of the parent schema resource. Note that an `$id` consisting of an empty IRI or of the empty fragment only will result in the embedded resource having the same IRI as the encapsulating resource, which SHOULD be considered an error per -[Section 8.2.3](#823-duplicate-schema-identifiers). +{{duplicate-identifiers}}. If no parent schema object explicitly identifies itself as a resource with `$id`, the base IRI is that of the entire document, as established by the steps -given in the [previous section.](#911-initial-base-iri) +given in the [previous section.](initial-base-iri) ##### Identifying the root schema The root schema of a JSON Schema document SHOULD contain an `$id` keyword with @@ -1076,14 +1074,14 @@ Therefore it is RECOMMENDED that `$anchor` be used to create plain name fragments unless there is a clear need for `$dynamicAnchor`. If present, the value of these keywords MUST be a string and MUST conform to the -plain name fragment identifier syntax defined in [Section -5](#5-fragment-identifiers).[^4] +plain name fragment identifier syntax defined in +{{fragment-identifiers}}.[^4] [^4]: Note that the anchor string does not include the "#" character, as it is not a IRI-reference. An `$anchor`: "foo" becomes the fragment `#foo` when used in a IRI. See below for full examples. -#### Duplicate schema identifiers +#### Duplicate schema identifiers {#duplicate-identifiers} A schema MAY (and likely will) have multiple IRIs, but there is no way for an IRI to identify more than one schema. When multiple schemas attempt to identify as the same IRI through the use of `$id`, `$anchor`, `$dynamicAnchor`, or any @@ -1200,7 +1198,7 @@ MUST NOT be collected as an annotation result. ### Loading a Schema -#### Initial Base IRI +#### Initial Base IRI {#initial-base-iri} [RFC 3987 Section 6.5](#rfc3987) and [RFC 3986 Section 5.1](#rfc3986) defines how to determine the default base IRI of a document. @@ -1306,7 +1304,7 @@ described by Hyper-Schema, it is expected that new schemas will be added to the system dynamically, so placing an absolute requirement of pre-loading schema documents is not feasible. -#### JSON Pointer fragments and embedded schema resources +#### JSON Pointer fragments and embedded schema resources {#json-pointer-embedded} Since JSON Pointer IRI fragments are constructed based on the structure of the schema document, an embedded schema resource and its subschemas can be identified by JSON Pointer fragments relative to either its own canonical IRI, @@ -1478,7 +1476,7 @@ the other, a naive validator might get stuck in an infinite recursive loop trying to validate the instance. Schemas SHOULD NOT make use of infinite recursive nesting like this; the behavior is undefined. -#### References to Possible Non-Schemas +#### References to Possible Non-Schemas {#non-schema-references} Subschema objects (or booleans) are recognized by their use with known applicator keywords or with location-reserving keywords such as [`$defs`](#825-schema-re-use-with-defs) that take one or more subschemas as a @@ -1851,10 +1849,9 @@ as described below in the section for that keyword. Validation MUST always succeed against this keyword. The value of this keyword is used as its annotation result. -Per [Section 7.3](#73-default-behaviors), omitted keywords MUST NOT produce -annotation results. However, as described in the section for `contains`, the -absence of this keyword's annotation causes `contains` to assume a minimum value -of 1. +Per {{default-behaviors}}, omitted keywords MUST NOT produce annotation +results. However, as described in the section for `contains`, the absence of +this keyword's annotation causes `contains` to assume a minimum value of 1. ##### contains The value of this keyword MUST be a valid JSON Schema. @@ -2605,7 +2602,7 @@ Passing results (annotations) For convenience, JSON Schema has been provided to validate output generated by implementations. Its IRI is: . -## Security Considerations +## Security Considerations {#security-considerations} Both schemas and instances are JSON values. As such, all security considerations defined in [RFC 8259](#rfc8259) apply. @@ -2647,13 +2644,13 @@ Required parameters:: N/A Encoding considerations:: Encoding considerations are identical to those specified for the `application/json` media type. See [JSON](#rfc8259). -Security considerations:: See [Section 13](#13-security-considerations) above. +Security considerations:: See {{security-considerations}} above. Interoperability considerations:: See Sections [6.2](#62-programming-language-independence), [6.3](#63-mathematical-integers), and [6.4](#64-regular-expressions) above. -Fragment identifier considerations:: See [Section 5](#5-fragment-identifiers) +Fragment identifier considerations:: See {{fragment-identifiers}} ### application/schema-instance+json The proposed MIME media type for JSON Schema Instances that require a JSON @@ -2668,13 +2665,13 @@ Required parameters:: N/A Encoding considerations:: Encoding considerations are identical to those specified for the `application/json` media type. See [JSON](#rfc8259). -Security considerations:: See [Section 13](#13-security-considerations) above. +Security considerations:: See {{security-considerations}} above. Interoperability considerations:: See Sections [6.2](#62-programming-language-independence), [6.3](#63-mathematical-integers), and [6.4](#64-regular-expressions) above. -Fragment identifier considerations:: See [Section 5](#5-fragment-identifiers) +Fragment identifier considerations:: See {{fragment-identifiers}} ## References @@ -2797,8 +2794,8 @@ name fragment identifiers. The schemas at the following IRI-encoded [JSON Pointers](#rfc6901) (relative to the root schema) have the following base IRIs, and are identifiable by any -listed IRI in accordance with [Section 5](#5-fragment-identifiers) and [Section -9.2.1](#921-json-pointer-fragments-and-embedded-schema-resources) above. +listed IRI in accordance with {{fragment-identifiers}} and +#section(json-pointer-embedded) above. `#` (document root): canonical (and base) IRI: `https://example.com/root.json` canonical resource IRI plus pointer fragment: `https://example.com/root.json#` @@ -2837,9 +2834,7 @@ determines the canonical nature of the resulting full IRI.[^18] [^18]: Multiple "canonical" IRIs? We Acknowledge this is potentially confusing, and direct you to read the CREF located in the [JSON Pointer fragments and -embedded schema -resources](#921-json-pointer-fragments-and-embedded-schema-resources) section -for futher comments. +embedded schema resources](#json-pointer-embedded) section for further comments. ## [Appendix] Manipulating schema documents and references Various tools have been created to rearrange schema documents based on how and diff --git a/jsonschema-validation.md b/jsonschema-validation.md index 7a4777b3..60ead15a 100644 --- a/jsonschema-validation.md +++ b/jsonschema-validation.md @@ -53,10 +53,9 @@ document-wide validation process. This specification defines a set of assertion keywords, as well as a small vocabulary of metadata keywords that can be used to annotate the JSON instance -with useful information. The [Section -7](#7-vocabularies-for-semantic-content-with-format) keyword is intended +with useful information. The {{format-vocabulary}} keyword is intended primarily as an annotation, but can optionally be used as an assertion. The -[Section 8](#8-a-vocabulary-for-the-contents-of-string-encoded-data) keywords +{{content-vocabulary}} keywords are annotations for working with documents embedded as JSON strings. ## Interoperability Considerations @@ -269,7 +268,7 @@ the name of a property in the instance. Omitting this keyword has the same behavior as an empty object. -## Vocabularies for Semantic Content With format +## Vocabularies for Semantic Content With format {#format-vocabulary} ### Foreword Structural validation alone may be insufficient to allow an application to @@ -519,7 +518,7 @@ Implementations that validate formats MUST accept at least the subset of ECMA-262 defined in the [Regular Expressions](#43-regular-expressions) section of this specification, and SHOULD accept all valid ECMA-262 expressions. -## A Vocabulary for the Contents of String-Encoded Data +## A Vocabulary for the Contents of String-Encoded Data {#content-vocabulary} ### Foreword Annotations defined in this section indicate that an instance contains non-JSON diff --git a/package.json b/package.json index fcf5d44f..d54300d9 100644 --- a/package.json +++ b/package.json @@ -11,12 +11,14 @@ }, "license": "MIT", "dependencies": { + "@vcarl/remark-headings": "^0.1.0", "rehype-autolink-headings": "^6.1.1", "rehype-slug": "^5.1.0", "rehype-stringify": "^9.0.3", "remark": "^14.0.3", "remark-flexible-containers": "^1.0.6", "remark-gfm": "^3.0.1", + "remark-heading-id": "^1.0.0", "remark-preset-lint-markdown-style-guide": "^5.1.3", "remark-rehype": "^10.1.0", "remark-toc": "^8.0.1", From 110f5ff85f56ba186137fcf5528aea0746e57f31 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Sun, 30 Jul 2023 19:55:06 -0700 Subject: [PATCH 492/780] Add eslint --- .eslintrc | 34 ++++++++++++++++++++++++++++++++++ .gitignore | 2 ++ package.json | 6 +++++- 3 files changed, 41 insertions(+), 1 deletion(-) create mode 100644 .eslintrc diff --git a/.eslintrc b/.eslintrc new file mode 100644 index 00000000..5b6c9f31 --- /dev/null +++ b/.eslintrc @@ -0,0 +1,34 @@ +{ + "root": true, + "env": { + "es6": true, + "node": true + }, + "parserOptions": { + "ecmaVersion": 2020, + "sourceType": "module" + }, + "extends": [ + "eslint:recommended", + "plugin:import/recommended" + ], + "plugins": ["import"], + "rules": { + "array-bracket-spacing": "error", + "arrow-parens": "error", + "comma-dangle": "error", + "dot-location": ["error", "property"], + "eol-last": "error", + "generator-star-spacing": ["error", { "before": false, "after": true }], + "indent": ["error", 2, { "ignoreComments": true, "SwitchCase": 1 }], + "linebreak-style": "error", + "no-trailing-spaces": "error", + "no-unused-vars": ["error", { "argsIgnorePattern": "_.*" }], + "prefer-const": ["error", { "destructuring": "all" }], + "semi": "error", + "quotes": ["error", "double", { "allowTemplateLiterals": true }] + }, + "settings": { + "import/resolver": "node" + } +} diff --git a/.gitignore b/.gitignore index dc05e9da..2a6a4349 100644 --- a/.gitignore +++ b/.gitignore @@ -10,3 +10,5 @@ relative-json-pointer.txt package-lock.json node_modules/ + +.env diff --git a/package.json b/package.json index d54300d9..36b667b9 100644 --- a/package.json +++ b/package.json @@ -5,6 +5,7 @@ "type": "module", "main": "index.js", "scripts": { + "lint": "eslint build/", "build": "npm run build-core && npm run build-validation", "build-core": "node build/build.js < jsonschema-core.md > jsonschema-core.html", "build-validation": "node build/build.js < jsonschema-validation.md > jsonschema-validation.html" @@ -27,6 +28,9 @@ "vfile-reporter": "^8.0.0" }, "devDependencies": { - "dotenv": "^16.3.1" + "dotenv": "*", + "eslint": "*", + "eslint-import-resolver-node": "*", + "eslint-plugin-import": "*" } } From 35b73bda62bd83dc7cabba584966000abb95e351 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Sun, 30 Jul 2023 19:59:22 -0700 Subject: [PATCH 493/780] Use custom toc and heading-links remark plugins --- .eslintrc => .eslintrc.json | 1 + README.md | 36 +- build/build.js | 37 +- build/remark-headings.js | 97 ++++ build/remark-number-headings.js | 47 -- build/remark-reference-links.js | 21 + build/remark-section-links.js | 43 -- build/remark-table-of-contents.js | 65 +++ jsonschema-core.md | 713 ++++++++++++++++++------------ jsonschema-validation.md | 281 +++++++----- package.json | 8 +- 11 files changed, 827 insertions(+), 522 deletions(-) rename .eslintrc => .eslintrc.json (94%) create mode 100644 build/remark-headings.js delete mode 100644 build/remark-number-headings.js create mode 100644 build/remark-reference-links.js delete mode 100644 build/remark-section-links.js create mode 100644 build/remark-table-of-contents.js diff --git a/.eslintrc b/.eslintrc.json similarity index 94% rename from .eslintrc rename to .eslintrc.json index 5b6c9f31..585b9d92 100644 --- a/.eslintrc +++ b/.eslintrc.json @@ -22,6 +22,7 @@ "generator-star-spacing": ["error", { "before": false, "after": true }], "indent": ["error", 2, { "ignoreComments": true, "SwitchCase": 1 }], "linebreak-style": "error", + "no-console": ["error", { "allow": ["error"] }], "no-trailing-spaces": "error", "no-unused-vars": ["error", { "argsIgnorePattern": "_.*" }], "prefer-const": ["error", { "destructuring": "all" }], diff --git a/README.md b/README.md index c8e013e7..00646e62 100644 --- a/README.md +++ b/README.md @@ -43,19 +43,37 @@ features they make available to you. - [remark-gfm](https://github.com/remarkjs/remark-gfm) -- Adds support for Github Flavored Markdown specific markdown features such as autolink literals, footnotes, strikethrough, tables, and tasklists. -- [remark-number-headings](/json-schema-org/json-schema-spec/blob/main/remark-number-headings.js) - -- Adds hierarchical section numbers to headings. -- [remark-toc](https://github.com/remarkjs/remark-toc) -- Adds a table of - contents in a section with a header called "Table of Contents". +- [remark-heading-id](https://github.com/imcuttle/remark-heading-id) -- Adds + support for `{#my-anchor}` syntax to add an `id` to an element so it can be + referenced using URI fragment syntax. +- [remark-headings](/json-schema-org/json-schema-spec/blob/main/remark-headings.js) + -- A collection of enhancements for headings. + - Adds hierarchical section numbers to headings. + - Use the `[Appendix]` prefix on headings that should be numbered as an + appendix. + - Adds id anchors to headers that don't have one + - Example: `#section-2-13` + - Example: `#appendix-a` + - Makes the heading a link utilizing its anchor +- [remark-reference-links](/json-schema-org/json-schema-spec/blob/main/remark-reference-link.js) + -- Adds new syntax for referencing a section of the spec using the section + number as the link text. + - Example: + ```markdown + ## Foo {#foo} + + ## Bar + This is covered in {{foo}} // --> Renders to "This is covered in [Section 2.3](#foo)" + - Link text will use "Section" or "Appendix" as needed + ``` +- [remark-table-of-contents](/json-schema-org/json-schema-spec/blob/main/remark-table-of-contents.js) + -- Adds a table of contents in a section with a header called "Table of + Contents". - [remark-torchlight](https://github.com/torchlight-api/remark-torchlight) -- Syntax highlighting and more using https://torchlight.dev. Features include line numbers and line highlighting. -- [rehype-slug](https://github.com/rehypejs/rehype-slug) -- Adds `id` anchors to - header so they can be linked to with URI fragment syntax. -- [rehype-autolink-headings](https://github.com/rehypejs/rehype-autolink-headings) - -- Makes headings clickable. - [remark-flexible-containers](https://github.com/ipikuka/remark-flexible-containers) - -- Add a callout box using the following syntax. Supported container types are + - Add a callout box using the following syntax. Supported container types are `warning`, `note`, and `experimental`. ``` diff --git a/build/build.js b/build/build.js index ddc39d7c..6fce20ab 100644 --- a/build/build.js +++ b/build/build.js @@ -2,20 +2,17 @@ import dotenv from "dotenv"; import { readFileSync, writeFileSync } from "node:fs"; import { reporter } from "vfile-reporter"; import { remark } from "remark"; -import rehypeAutolinkHeadings from "rehype-autolink-headings"; -import rehypeSlug from "rehype-slug"; -import rehypeStringify from "rehype-stringify"; import remarkFlexibleContainers from "remark-flexible-containers"; import remarkGfm from "remark-gfm"; import remarkHeadingId from "remark-heading-id"; -import remarkHeadings from "@vcarl/remark-headings"; -import remarkNumberHeadings from "./remark-number-headings.js"; +import remarkHeadings from "./remark-headings.js"; import remarkPresetLintMarkdownStyleGuide from "remark-preset-lint-markdown-style-guide"; import remarkRehype from "remark-rehype"; -import remarkSectionLinks from "./remark-section-links.js"; -import remarkToc from "remark-toc"; +import remarkReferenceLinks from "./remark-reference-links.js"; +import remarkTableOfContents from "./remark-table-of-contents.js"; +import remarkTorchLight from "remark-torchlight"; import remarkValidateLinks from "remark-validate-links"; -import torchLight from "remark-torchlight"; +import rehypeStringify from "rehype-stringify"; dotenv.config(); @@ -25,26 +22,20 @@ dotenv.config(); const html = await remark() .use(remarkPresetLintMarkdownStyleGuide) .use(remarkGfm) - .use(torchLight) - .use(remarkFlexibleContainers) .use(remarkHeadingId) - .use(remarkNumberHeadings, { + .use(remarkHeadings, { startDepth: 2, - skip: ["Abstract", "Note to Readers", "Table of Contents", "Authors' Addresses", "\\[.*\\]", "draft-.*"], - appendixToken: "[Appendix]", - appendixPrefix: "Appendix" + skip: ["Abstract", "Note to Readers", "Table of Contents", "Authors' Addresses", "\\[.*\\]", "draft-.*"] }) - .use(remarkHeadings) - .use(remarkSectionLinks) - .use(remarkToc, { - tight: true, - heading: "Table of Contents", - skip: "\\[.*\\]|draft-.*" + .use(remarkReferenceLinks) + .use(remarkFlexibleContainers) + .use(remarkTorchLight) + .use(remarkTableOfContents, { + startDepth: 2, + skip: ["Abstract", "Note to Readers", "\\[.*\\]", "Authors' Addresses", "draft-.*"] }) .use(remarkValidateLinks) .use(remarkRehype) - .use(rehypeSlug) - .use(rehypeAutolinkHeadings, { behavior: "wrap" }) .use(rehypeStringify) .process(md); @@ -122,7 +113,7 @@ dotenv.config(); - ${String(html)} + ${html.toString()} `); diff --git a/build/remark-headings.js b/build/remark-headings.js new file mode 100644 index 00000000..6cecefcd --- /dev/null +++ b/build/remark-headings.js @@ -0,0 +1,97 @@ +import { visit } from "unist-util-visit"; +import { link, text } from "mdast-builder"; +import { findAndReplace } from "mdast-util-find-and-replace"; +import { toString as nodeToString } from "mdast-util-to-string"; + + +const defaultOptions = { + startDepth: 1, + skip: [], + appendixToken: "[Appendix]", + appendixPrefix: "Appendix" +}; + +const remarkNumberHeadings = (options) => (tree, file) => { + options = { ...defaultOptions, ...options }; + options.skip = new RegExp(`^(${options.skip.join("|")})$`, "u"); + + // Auto-number headings + let sectionNumbers = []; + + visit(tree, "heading", (headingNode) => { + if (headingNode.depth < options.startDepth) { + return; + } + + const headingText = nodeToString(headingNode); + if (options.skip.test(headingText)) { + return; + } + + if (!("data" in headingNode)) { + headingNode.data = {}; + } + + if (!("hProperties" in headingNode.data)) { + headingNode.data.hProperties = {}; + } + + if (headingText.startsWith(options.appendixToken)) { + findAndReplace(headingNode, [options.appendixToken]); + + const currentIndex = typeof sectionNumbers[headingNode.depth] === "string" + ? sectionNumbers[headingNode.depth] + : "@"; + sectionNumbers[headingNode.depth] = String.fromCharCode(currentIndex.charCodeAt(0) + 1); + sectionNumbers = sectionNumbers.slice(0, headingNode.depth + 1); + + const sectionNumber = sectionNumbers.slice(options.startDepth, headingNode.depth + 1).join("."); + headingNode.data.section = `${options.appendixPrefix} ${sectionNumber}`; + + headingNode.children.splice(0, 0, text(`${headingNode.data.section}. `)); + } else { + sectionNumbers[headingNode.depth] = (sectionNumbers[headingNode.depth] ?? 0) + 1; + sectionNumbers = sectionNumbers.slice(0, headingNode.depth + 1); + + const sectionNumber = sectionNumbers.slice(options.startDepth, headingNode.depth + 1).join("."); + const prefix = typeof sectionNumbers[options.startDepth] === "string" + ? options.appendixPrefix + : "Section"; + headingNode.data.section = `${prefix} ${sectionNumber}`; + + headingNode.children.splice(0, 0, text(`${sectionNumber}. `)); + } + + if (!("id" in headingNode.data)) { + const sectionSlug = headingNode.data?.id + ?? headingNode.data.section.replaceAll(/[ .]/g, "-").toLowerCase(); + headingNode.data.hProperties.id = sectionSlug; + headingNode.data.id = sectionSlug; + } + }); + + // Build headings data used by ./remark-reference-links.js + if (!("data" in file)) { + file.data = {}; + } + + file.data.headings = {}; + + visit(tree, "heading", (headingNode) => { + if (headingNode.data?.id) { + if (headingNode.data.id in file.data.headings) { + file.message(`Found duplicate heading id "${headingNode.data.id}"`); + } + file.data.headings[headingNode.data.id] = headingNode; + } + }); + + // Make heading a link + visit(tree, "heading", (headingNode) => { + if (headingNode.data?.id) { + headingNode.children = [link(`#${headingNode.data.id}`, "", headingNode.children)]; + } + }); +}; + +export default remarkNumberHeadings; diff --git a/build/remark-number-headings.js b/build/remark-number-headings.js deleted file mode 100644 index 30800774..00000000 --- a/build/remark-number-headings.js +++ /dev/null @@ -1,47 +0,0 @@ -import { visit } from "unist-util-visit"; - - -const defaultOptions = { - startDepth: 1, - skip: [] -}; - -const remarkNumberHeadings = (options) => (tree) => { - options = { ...defaultOptions, ...options }; - options.skip = new RegExp(`^(${options.skip.join("|")})$`, "u"); - - let sectionNumbers = []; - - visit(tree, "heading", (node) => { - if (node.depth < options.startDepth) { - return; - } - - visit(node, "text", (textNode) => { - let text = textNode.value ? textNode.value.trim() : ""; - - if (options.skip.test(text)) { - return; - } - - if (text.startsWith(options.appendixToken)) { - const currentIndex = typeof sectionNumbers[node.depth] === "string" - ? sectionNumbers[node.depth] - : "@"; - sectionNumbers[node.depth] = String.fromCharCode(currentIndex.charCodeAt(0) + 1); - sectionNumbers = sectionNumbers.slice(0, node.depth + 1); - - const sectionNumber = sectionNumbers.slice(options.startDepth, node.depth + 1).join("."); - textNode.value = `${options.appendixPrefix} ${sectionNumber}. ${text.slice(options.appendixToken.length + 1)}`; - } else { - sectionNumbers[node.depth] = (sectionNumbers[node.depth] ?? 0) + 1; - sectionNumbers = sectionNumbers.slice(0, node.depth + 1); - - const sectionNumber = sectionNumbers.slice(options.startDepth, node.depth + 1).join("."); - textNode.value = `${sectionNumber}. ${text}`; - } - }); - }); -}; - -export default remarkNumberHeadings; diff --git a/build/remark-reference-links.js b/build/remark-reference-links.js new file mode 100644 index 00000000..16af2928 --- /dev/null +++ b/build/remark-reference-links.js @@ -0,0 +1,21 @@ +import { text, link } from "mdast-builder"; +import { toString as nodeToString } from "mdast-util-to-string"; +import { findAndReplace } from "mdast-util-find-and-replace"; + + +const referenceLink = /\{\{(?.*?)\}\}/ug; + +const remarkReferenceLinks = () => (tree, file) => { + findAndReplace(tree, [referenceLink, (value, id) => { + // file.data.headings comes from ./remark-headings.js + if (!(id in file.data.headings)) { + throw Error(`ReferenceLinkError: No header found with id "${id}"`); + } + + const headerText = nodeToString(file.data.headings[id]); + const linkText = text(file.data.headings[id].data.section); + return link(`#${id}`, headerText, [linkText]); + }]); +}; + +export default remarkReferenceLinks; diff --git a/build/remark-section-links.js b/build/remark-section-links.js deleted file mode 100644 index 1c41e042..00000000 --- a/build/remark-section-links.js +++ /dev/null @@ -1,43 +0,0 @@ -import { visit } from "unist-util-visit"; - - -const sectionLink = /\{\{(?.*?)\}\}/u; - -const remarkSectionLinks = (options) => (tree, vfile) => { - // Heading data comes from @vcarl/remark-headings - const headings = {}; - for (const heading of vfile.data.headings) { - if (heading?.data?.id) { - headings[heading.data.id] = heading.value; - } - } - - visit(tree, "text", (node, index, parent) => { - const match = node.value.match(sectionLink); - - if (match) { - if (!(match.groups.id in headings)) { - throw Error(`SectionLinkError: No header found with id "${match.groups.id}"`) - } - const headerText = headings[match.groups.id]; - - const beforeNode = { type: "text", value: node.value.slice(0, match.index) }; - const afterNode = { type: "text", value: node.value.slice(match.index + match[0].length) }; - const linkNode = { - type: "link", - title: headerText, - url: `#${match.groups.id}`, - children: [ - { - type: "text", - value: "Section " + headerText.slice(0, headerText.indexOf(". ")) - } - ] - }; - - parent.children.splice(index, 1, beforeNode, linkNode, afterNode); - } - }); -}; - -export default remarkSectionLinks; diff --git a/build/remark-table-of-contents.js b/build/remark-table-of-contents.js new file mode 100644 index 00000000..3fbb3bde --- /dev/null +++ b/build/remark-table-of-contents.js @@ -0,0 +1,65 @@ +import { visit } from "unist-util-visit"; +import { list, listItem } from "mdast-builder"; +import { toString as nodeToString } from "mdast-util-to-string"; + + +const defaultOptions = { + heading: "Table of Contents", + startDepth: 1, + skip: [] +}; + +const remarkTableOfContents = (options) => (tree, file) => { + options = { ...defaultOptions, ...options }; + options.skip.push(options.heading); + options.skip = new RegExp(`^(${options.skip.join("|")})$`, "u"); + + let insertTableOfContents; + + const tableOfContents = list("unordered"); + let currentList = tableOfContents; + const listStack = [currentList]; + let currentDepth = options.startDepth; + + visit(tree, "heading", (headingNode, index, parent) => { + const headingText = nodeToString(headingNode); + + if (headingText === options.heading) { + insertTableOfContents = () => { + parent.children.splice(index + 1, 0, tableOfContents); + }; + } + + if (headingNode.depth < options.startDepth) { + return; + } + + while (headingNode.depth > currentDepth) { + const newList = list("unordered"); + listStack.push(newList); + currentList.children.push(newList); + currentList = newList; + currentDepth++; + } + + while (headingNode.depth < currentDepth) { + listStack.pop(); + currentList = listStack[listStack.length - 1]; + currentDepth--; + } + + if (options.skip.test(headingText)) { + return; + } + + currentList.children.push(listItem(headingNode.children)); + }); + + if (insertTableOfContents) { + insertTableOfContents(); + } else { + file.message(`Table of Contents not added. Add a heading with the text "${options.heading}" or set the 'heading' option to use a different heading.`); + } +}; + +export default remarkTableOfContents; diff --git a/jsonschema-core.md b/jsonschema-core.md index 83997d53..58898e59 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -1,6 +1,7 @@ # JSON Schema: A Media Type for Describing JSON Documents ## Abstract + JSON Schema defines the media type `application/schema+json`, a JSON-based format for describing the structure of JSON data. JSON Schema asserts what a JSON document must look like, ways to extract information from it, and how to @@ -9,6 +10,7 @@ additional feature-rich integration with `application/schema+json` beyond what can be offered for `application/json` documents. ## Note to Readers + The issues list for this draft can be found at . @@ -20,6 +22,7 @@ the homepage, or email the document editors. ## Table of Contents ## Introduction + JSON Schema is a JSON media type for defining the structure of JSON data. JSON Schema is intended to define validation, documentation, hyperlink navigation, and interaction control of JSON data. @@ -33,6 +36,7 @@ Other specifications define the vocabularies that perform assertions about validation, linking, annotation, navigation, and interaction. ## Conventions and Terminology + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](#rfc2119). @@ -42,6 +46,7 @@ The terms "JSON", "JSON text", "JSON value", "member", "element", "object", document are to be interpreted as defined in [RFC 8259](#rfc8259). ## Overview + This document proposes a new media type `application/schema+json` to identify a JSON Schema for describing JSON data. It also proposes a further optional media type, `application/schema-instance+json`, to provide additional integration @@ -87,12 +92,12 @@ that document's purpose. ## Definitions ### JSON Document + A JSON document is an information resource (series of octets) described by the `application/json` media type. In JSON Schema, the terms "JSON document", "JSON text", and "JSON value" are -interchangeable because of the data model it defines in -{{instance-data-model}}. +interchangeable because of the data model it defines in {{data-model}}. JSON Schema is only defined over JSON documents. However, any document or memory structure that can be parsed into or processed according to the JSON Schema data @@ -109,7 +114,7 @@ including media types with the `+json` structured syntax suffix. Among these, this specification defines the `application/schema-instance+json` media type which defines handling for fragments in the IRI. -#### Instance Data Model {#instance-data-model} +#### Instance Data Model {#data-model} JSON Schema interprets documents according to a data model. A JSON value interpreted according to this data model is called an "instance". @@ -133,23 +138,23 @@ string: A string of Unicode code points, from the JSON "string" value Whitespace and formatting concerns, including different lexical representations of numbers that are equal within the data model, are thus outside the scope of -JSON Schema. JSON Schema [vocabularies](#81-meta-schemas-and-vocabularies) that -wish to work with such differences in lexical representations SHOULD define -keywords to precisely interpret formatted strings within the data model rather -than relying on having the original JSON representation Unicode characters -available. +JSON Schema. JSON Schema [vocabularies](#vocabulary) that wish to work with such +differences in lexical representations SHOULD define keywords to precisely +interpret formatted strings within the data model rather than relying on having +the original JSON representation Unicode characters available. Since an object cannot have two properties with the same key, behavior for a JSON document that tries to define two properties with the same key in a single object is undefined. Note that JSON Schema vocabularies are free to define their own extended type -system. This should not be confused with the core data model types defined -here. As an example, "integer" is a reasonable type for a vocabulary to define -as a value for a keyword, but the data model makes no distinction between -integers and other numbers. +system. This should not be confused with the core data model types defined here. +As an example, "integer" is a reasonable type for a vocabulary to define as a +value for a keyword, but the data model makes no distinction between integers +and other numbers. #### Instance Equality + Two JSON instances are said to be equal if and only if they are of the same type and have the same value according to the data model. Specifically, this means: @@ -159,8 +164,8 @@ and have the same value according to the data model. Specifically, this means: - both are strings, and are the same codepoint-for-codepoint; or - both are numbers, and have the same mathematical value; or - both are arrays, and have an equal value item-for-item; or -- both are objects, and each property in one has exactly one property with -a key equal to the other's, and that other property has an equal value. +- both are objects, and each property in one has exactly one property with a key + equal to the other's, and that other property has an equal value. Implied in this definition is that arrays must be the same length, objects must have the same number of members, properties in objects are unordered, there is @@ -169,6 +174,7 @@ differences (indentation, placement of commas, trailing zeros) are insignificant. #### Non-JSON Instances + It is possible to use JSON Schema with a superset of the JSON Schema data model, where an instance may be outside any of the six JSON data types. @@ -179,7 +185,8 @@ A custom vocabulary may define support for a superset of the core data model. The schema itself may only be expressible in this superset; for example, to make use of the `const` keyword. -### JSON Schema Documents +### JSON Schema Documents {#schema-document} + A JSON Schema document, or simply a schema, is a JSON document used to describe an instance. A schema can itself be interpreted as an instance, but SHOULD always be given the media type `application/schema+json` rather than @@ -190,9 +197,9 @@ provided by `application/schema-instance+json`. A JSON Schema MUST be an object or a boolean. #### JSON Schema Objects and Keywords -Object properties that are applied to the instance are called keywords, -or schema keywords. Broadly speaking, keywords fall into one of five -categories: + +Object properties that are applied to the instance are called keywords, or +schema keywords. Broadly speaking, keywords fall into one of five categories: identifiers: control schema identification through setting a IRI for the schema and/or changing how the base IRI is determined @@ -219,19 +226,20 @@ companions, are free to define other behaviors as well. A JSON Schema MAY contain properties which are not schema keywords or are not recognized as schema keywords. The behavior of such keywords is governed by -{{unknown-keywords}}. +{{unrecognized}}. An empty schema is a JSON Schema with no properties. #### Boolean JSON Schemas + The boolean schema values `true` and `false` are trivial schemas that always produce themselves as assertion results, regardless of the instance value. They never produce annotation results. These boolean schemas exist to clarify schema author intent and facilitate -schema processing optimizations. They behave identically to the following -schema objects (where `not` is part of the subschema application vocabulary -defined in this document). +schema processing optimizations. They behave identically to the following schema +objects (where `not` is part of the subschema application vocabulary defined in +this document). `true`: Always passes validation, as if the empty schema `{}` @@ -242,6 +250,7 @@ equivalents to the `false` schema. Using the boolean values ensures that the intent is clear to both human readers and implementations. #### Schema Vocabularies + A schema vocabulary, or simply a vocabulary, is a set of keywords, their syntax, and their semantics. A vocabulary is generally organized around a particular purpose. Different uses of JSON Schema, such as validation, hypermedia, or user @@ -261,6 +270,7 @@ organizations, a vocabulary specification need not be published outside of its scope of use. #### Meta-Schemas + A schema that itself describes a schema is called a meta-schema. Meta-schemas are used to validate JSON Schemas and specify which vocabularies they are using. @@ -271,7 +281,8 @@ conformance more strictly or more loosely than the vocabularies' specifications call for. Meta-schemas may also describe and validate additional keywords that are not part of a formal vocabulary. -#### Root Schema and Subschemas and Resources +#### Root Schema and Subschemas and Resources {#root} + A JSON Schema resource is a schema which is [canonically](#rfc6596) identified by an [absolute IRI](#rfc3987). Schema resources MAY also be identified by IRIs, including IRIs with fragments, if the resulting secondary resource (as defined @@ -281,7 +292,7 @@ in another. Any such IRIs with fragments are considered to be non-canonical. The root schema is the schema that comprises the entire JSON document in question. The root schema is always a schema resource, where the IRI is -determined as described in {{initial-base-iri}}.[^1] +determined as described in {{initial-base}}.[^1] [^1]: Note that documents that embed schemas in another format will not have a root schema resource in this sense. Exactly how such usages fit with the JSON @@ -303,17 +314,18 @@ schema titled "root" is the root schema. As with the root schema, a subschema is either an object or a boolean. -As discussed in {{id-keyword}}, a JSON Schema document -can contain multiple JSON Schema resources. When used without qualification, -the term "root schema" refers to the document's root schema. In some cases, -resource root schemas are discussed. A resource's root schema is its top-level -schema object, which would also be a document root schema if the resource were -to be extracted to a standalone JSON Schema document. +As discussed in {{id-keyword}}, a JSON Schema document can contain multiple JSON +Schema resources. When used without qualification, the term "root schema" refers +to the document's root schema. In some cases, resource root schemas are +discussed. A resource's root schema is its top-level schema object, which would +also be a document root schema if the resource were to be extracted to a +standalone JSON Schema document. Whether multiple schema resources are embedded or linked with a reference, they are processed in the same way, with the same available behaviors. -## Fragment Identifiers {#fragment-identifiers} +## Fragment Identifiers {#fragments} + In accordance with section 3.1 of [RFC 6839](#rfc6839), the syntax and semantics of fragment identifiers specified for any +json media type SHOULD be as specified for `application/json`. (At publication of this document, there is no @@ -324,8 +336,8 @@ identifier structures: plain names and JSON Pointers. The `application/schema-instance+json` media type supports one fragment identifier structure: JSON Pointers. -The use of JSON Pointers as IRI fragment identifiers is described in -[RFC 6901](#rfc6901). For `application/schema+json`, which supports two fragment +The use of JSON Pointers as IRI fragment identifiers is described in [RFC +6901](#rfc6901). For `application/schema+json`, which supports two fragment identifier syntaxes, fragment identifiers matching the JSON Pointer syntax, including the empty string, MUST be interpreted as JSON Pointer fragment identifiers. @@ -346,29 +358,33 @@ interpreted as plain name fragment identifiers. Defining and referencing a plain name fragment identifier within an `application/schema+json` document are specified in the [`$anchor` -keyword](#822-defining-location-independent-identifiers) section. +keyword](#anchors) section. ## General Considerations ### Range of JSON Values + An instance may be any valid JSON value as defined by [JSON](#rfc8259). JSON Schema imposes no restrictions on type: JSON Schema can describe any JSON value, including, for example, null. -### Programming Language Independence +### Programming Language Independence {#language} + JSON Schema is programming language agnostic, and supports the full range of values described in the data model. Be aware, however, that some languages and JSON parsers may not be able to represent in memory the full range of values describable by JSON. -### Mathematical Integers +### Mathematical Integers {#integers} + Some programming languages and parsers use different internal representations for floating point numbers than they do for integers. For consistency, integer JSON numbers SHOULD NOT be encoded with a fractional part. -### Regular Expressions +### Regular Expressions {#regex} + Keywords MAY use regular expressions to express constraints, or constrain the instance value to be a regular expression. These regular expressions SHOULD be valid according to the regular expression dialect described in [ECMA-262, @@ -387,13 +403,13 @@ schema authors SHOULD limit themselves to the following regular expression tokens: - individual Unicode characters, as defined by the [JSON -specification](#rfc8259); + specification](#rfc8259); - simple character classes ([abc]), range character classes ([a-z]); - complemented character classes ([^abc], [^a-z]); - simple quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or one), -and their lazy versions ("+?", "*?", "??"); + and their lazy versions ("+?", "*?", "??"); - range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at least x, at most -y, occurrences), {x,} (x occurrences or more), and their lazy versions; + y, occurrences), {x,} (x occurrences or more), and their lazy versions; - the beginning-of-input ("^") and end-of-input ("$") anchors; - simple grouping ("(...)") and alternation ("|"). @@ -401,7 +417,8 @@ Finally, implementations MUST NOT take regular expressions to be anchored, neither at the beginning nor at the end. This means, for instance, the pattern "es" matches "expression". -### Extending JSON Schema +### Extending JSON Schema {#extending} + Additional schema keywords and schema vocabularies MAY be defined by any entity. Save for explicit agreement, schema authors SHALL NOT expect these additional keywords and vocabularies to be supported by implementations that do not @@ -411,7 +428,8 @@ Implementations MAY provide the ability to register or load handlers for vocabularies that they do not support directly. The exact mechanism for registering and implementing such handlers is implementation-dependent. -#### Explicit annotation keywords +#### Explicit annotation keywords {#explicit-annotations} + The values of keywords which begin with "x-" MUST be collected as annotations. Keywords which begin with "x-" symbol MUST NOT affect evaluation of a schema in @@ -420,13 +438,15 @@ any way other than annotation collection. Consequently, the "x-" prefix is reserved for this purpose, and extension vocabularies MUST NOT define any keywords which begin with this prefix. -#### Handling of unrecognized or unsupported keywords {#unknown-keywords} +#### Handling of unrecognized or unsupported keywords {#unrecognized} + Implementations SHOULD treat keywords they do not recognize, or that they recognize but do not support, as annotations, where the value of the keyword is the value of the annotation. Whether an implementation collects these annotations or not, they MUST otherwise ignore the keywords. ## Keyword Behaviors + JSON Schema keywords fall into several general behavior categories. Assertions validate that an instance satisfies constraints, producing a boolean result. Annotations attach information that applications may use in any way they see @@ -442,12 +462,12 @@ other behaviors for specialized purposes. Evaluating an instance against a schema involves processing all of the keywords in the schema against the appropriate locations within the instance. Typically, applicator keywords are processed until a schema object with no applicators (and -therefore no subschemas) is reached. The appropriate location in the instance -is evaluated against the assertion and annotation keywords in the schema object. +therefore no subschemas) is reached. The appropriate location in the instance is +evaluated against the assertion and annotation keywords in the schema object. The interactions of those keyword results to produce the schema object results -are governed by {{annotations-and-assertions}}, while the -relationship of subschema results to the results of the applicator keyword that -applied them is described by {{applicators}}. +are governed by {{annot-assert}}, while the relationship of subschema results to +the results of the applicator keyword that applied them is described by +{{applicators}}. Evaluation of a parent schema object can complete once all of its subschemas have been evaluated, although in some circumstances evaluation may be @@ -456,15 +476,15 @@ some assertion result short-circuiting is not possible due to the need to examine all subschemas for annotation collection, including those that cannot further change the assertion result. -### Lexical Scope and Dynamic Scope +### Lexical Scope and Dynamic Scope {#scopes} While most JSON Schema keywords can be evaluated on their own, or at most need to take into account the values or results of adjacent keywords in the same schema object, a few have more complex behavior. The lexical scope of a keyword is determined by the nested JSON data structure -of objects and arrays. The largest such scope is an entire schema document. -The smallest scope is a single schema object with no subschemas. +of objects and arrays. The largest such scope is an entire schema document. The +smallest scope is a single schema object with no subschemas. Keywords MAY be defined with a partial value, such as a IRI-reference, which must be resolved against another value, such as another IRI-reference or a full @@ -493,21 +513,21 @@ parent, rather than examining the local lexically enclosing parent. The concept of dynamic scope is primarily used with `$dynamicRef` and `$dynamicAnchor`, and should be considered an advanced feature and used with -caution when defining additional keywords. It also appears when reporting -errors and collected annotations, as it may be possible to revisit the same -lexical scope repeatedly with different dynamic scopes. In such cases, it is -important to inform the user of the evaluation path that produced the error or -annotation. +caution when defining additional keywords. It also appears when reporting errors +and collected annotations, as it may be possible to revisit the same lexical +scope repeatedly with different dynamic scopes. In such cases, it is important +to inform the user of the evaluation path that produced the error or annotation. ### Keyword Interactions + Keyword behavior MAY be defined in terms of the annotation results of -[subschemas](#435-root-schema-and-subschemas-and-resources) and/or adjacent -keywords (keywords within the same schema object) and their subschemas. Such -keywords MUST NOT result in a circular dependency. Keywords MAY modify their -behavior based on the presence or absence of another keyword in the same [schema -object](#43-json-schema-documents). +[subschemas](#root) and/or adjacent keywords (keywords within the same schema +object) and their subschemas. Such keywords MUST NOT result in a circular +dependency. Keywords MAY modify their behavior based on the presence or absence +of another keyword in the same [schema object](#schema-document). ### Default Behaviors {#default-behaviors} + A missing keyword MUST NOT produce a false assertion result, MUST NOT produce annotation results, and MUST NOT cause any other schema to be evaluated as part of its own behavioral definition. However, given that missing keywords do not @@ -524,17 +544,18 @@ Because annotation collection can add significant cost in terms of both computation and memory, implementations MAY opt out of this feature. Keywords that are specified in terms of collected annotations SHOULD describe reasonable alternate approaches when appropriate. This approach is demonstrated by the -[`items`](#10312-items) and -[`additionalProperties`](#10323-additionalproperties) keywords in this document. +[`items`](#items) and [`additionalProperties`](#additionalproperties) keywords +in this document. Note that when no such alternate approach is possible for a keyword, implementations that do not support annotation collections will not be able to support those keywords or vocabularies that contain them. ### Identifiers + Identifiers define IRIs for a schema, or affect how such IRIs are resolved in -[references](#824-schema-references), or both. The Core vocabulary defined in -this document defines several identifying keywords, most notably `$id`. +[references](#referenced), or both. The Core vocabulary defined in this document +defines several identifying keywords, most notably `$id`. Canonical schema IRIs MUST NOT change while processing an instance, but keywords that affect IRI-reference resolution MAY have behavior that is only fully @@ -547,13 +568,13 @@ to the matching `$dynamicRef` keyword, leaving the behavior of `$ref` undisturbed. ### Applicators {#applicators} + Applicators allow for building more complex schemas than can be accomplished with a single schema object. Evaluation of an instance against a [schema -document](#43-json-schema-documents) begins by applying the [root -schema](#435-root-schema-and-subschemas-and-resources) to the complete instance -document. From there, keywords known as applicators are used to determine which -additional schemas are applied. Such schemas may be applied in-place to the -current location, or to a child location. +document](#schema-document) begins by applying the [root schema](#root) to the +complete instance document. From there, keywords known as applicators are used +to determine which additional schemas are applied. Such schemas may be applied +in-place to the current location, or to a child location. The schemas to be applied may be present as subschemas comprising all or part of the keyword's value. Alternatively, an applicator may refer to a schema @@ -561,22 +582,21 @@ elsewhere in the same schema document, or in a different one. The mechanism for identifying such referenced schemas is defined by the keyword. Applicator keywords also define how subschema or referenced schema boolean -[assertion](#76-assertions) results are modified and/or combined to produce the +[assertion](#assertions) results are modified and/or combined to produce the boolean result of the applicator. Applicators may apply any boolean logic operation to the assertion results of subschemas, but MUST NOT introduce new assertion conditions of their own. -[Annotation](#77-annotations) results from subschemas are preserved in -accordance with {{collecting-annotations}} so that -applications can decide how to interpret multiple values. Applicator keywords -do not play a direct role in this preservation. +[Annotation](#annotations) results from subschemas are preserved in accordance +with {{collect}} so that applications can decide how to interpret multiple +values. Applicator keywords do not play a direct role in this preservation. + +#### Referenced and Referencing Schemas {#referenced} -#### Referenced and Referencing Schemas -As noted in {{applicators}}, an applicator keyword may refer to a -schema to be applied, rather than including it as a subschema in the -applicator's value. In such situations, the schema being applied is known as -the referenced schema, while the schema containing the applicator keyword is the -referencing schema. +As noted in {{applicators}}, an applicator keyword may refer to a schema to be +applied, rather than including it as a subschema in the applicator's value. In +such situations, the schema being applied is known as the referenced schema, +while the schema containing the applicator keyword is the referencing schema. While root schemas and subschemas are static concepts based on a schema's position within a schema document, referenced and referencing schemas are @@ -584,14 +604,14 @@ dynamic. Different pairs of schemas may find themselves in various referenced and referencing arrangements during the evaluation of an instance against a schema. -For some by-reference applicators, such as -[`$ref`](#8241-direct-references-with-ref), the referenced schema can be -determined by static analysis of the schema document's lexical scope. Others, -such as `$dynamicRef` (with `$dynamicAnchor`), may make use of dynamic scoping, -and therefore only be resolvable in the process of evaluating the schema with an -instance. +For some by-reference applicators, such as [`$ref`](#ref), the referenced schema +can be determined by static analysis of the schema document's lexical scope. +Others, such as `$dynamicRef` (with `$dynamicAnchor`), may make use of dynamic +scoping, and therefore only be resolvable in the process of evaluating the +schema with an instance. + +### Assertions {#assertions} -### Assertions JSON Schema can be used to assert constraints on a JSON document, which either passes or fails the assertions. This approach can be used to validate conformance with the constraints, or document what is needed to satisfy them. @@ -602,6 +622,7 @@ instance against schema assertions. An instance can only fail an assertion that is present in the schema. #### Assertions and Instance Primitive Types + Most assertions only constrain values within a certain primitive type. When the type of the instance is not of the type targeted by the keyword, the instance is considered to conform to the assertion. @@ -612,8 +633,8 @@ are too long) from being valid. If the instance is a number, boolean, null, array, or object, then it is valid against this assertion. This behavior allows keywords to be used more easily with instances that can be -of multiple primitive types. The companion validation vocabulary also includes -a `type` keyword which can independently restrict the instance to one or more +of multiple primitive types. The companion validation vocabulary also includes a +`type` keyword which can independently restrict the instance to one or more primitive types. This allows for a concise expression of use cases such as a function that might return either a string of a certain length or a null value: @@ -630,7 +651,8 @@ not actually allow null values. Each keyword is evaluated separately unless explicitly specified otherwise, so if `maxLength` restricted the instance to strings, then including `"null"` in `type` would not have any useful effect. -### Annotations +### Annotations {#annotations} + JSON Schema can annotate an instance with information, whenever the instance validates against the schema object containing the annotation, and all of its parent schema objects. The information can be a simple value, or can be @@ -657,7 +679,8 @@ even if they cannot change the overall assertion result. The only exception is that subschemas of a schema object that has failed validation MAY be skipped, as annotations are not retained for failing schemas. -#### Collecting Annotations {#collecting-annotations} +#### Collecting Annotations {#collect} + Annotations are collected by keywords that explicitly define annotation-collecting behavior. Note that boolean schemas cannot produce annotations as they do not make use of keywords. @@ -667,12 +690,13 @@ A collected annotation MUST include the following information: - The name of the keyword that produces the annotation - The instance location to which it is attached, as a JSON Pointer - The evaluation path, indicating how reference keywords such as `$ref` were -followed to reach the absolute schema location. + followed to reach the absolute schema location. - The absolute schema location of the attaching keyword, as a IRI. This MAY be -omitted if it is the same as the evaluation path from above. + omitted if it is the same as the evaluation path from above. - The attached value(s) ##### Distinguishing Among Multiple Values + Applications MAY make decisions on which of multiple annotation values to use based on the schema location that contributed the value. This is intended to allow flexible usage. Collecting the schema location facilitates such usage. @@ -723,9 +747,9 @@ Note that some lines are wrapped for clarity. In this example, both Feature A and Feature B make use of the re-usable "enabledToggle" schema. That schema uses the `title`, `description`, and -`default` annotations. Therefore the application has to decide how to handle -the additional `default` value for Feature A, and the additional `description` -value for Feature B. +`default` annotations. Therefore the application has to decide how to handle the +additional `default` value for Feature A, and the additional `description` value +for Feature B. The application programmer and the schema author need to agree on the usage. For this example, let's assume that they agree that the most specific `default` @@ -752,7 +776,8 @@ might take. For example, an application may consider the presence of two different values for `default` to be an error, regardless of their schema locations. -##### Annotations and Assertions {#annotations-and-assertions} +##### Annotations and Assertions {#annot-assert} + Schema objects that produce a false assertion result MUST NOT produce any annotation results, whether from their own keywords or from keywords in subschemas. @@ -781,6 +806,7 @@ annotation "String Value" is kept, as the instance passes the string type assertions. ### Reserved Locations + A fourth category of keywords simply reserve a location to hold re-usable components or data of interest to schema authors that is not suitable for re-use. These keywords do not affect validation or annotation results. Their @@ -788,11 +814,12 @@ purpose in the core vocabulary is to ensure that locations are available for certain purposes and will not be redefined by extension keywords. While these keywords do not directly affect results, as explained in -{{non-schema-references}} unrecognized extension keywords that reserve -locations for re-usable schemas may have undesirable interactions with -references in certain circumstances. +{{non-schemas}} unrecognized extension keywords that reserve locations for +re-usable schemas may have undesirable interactions with references in certain +circumstances. ### Loading Instance Data + While none of the vocabularies defined as part of this or the associated documents define a keyword which may target and/or load instance data, it is possible that other vocabularies may wish to do so. @@ -803,7 +830,8 @@ examine parts of an instance outside the current evaluation location. Keywords that allow adjusting the location using a Relative JSON Pointer SHOULD default to using the current location if a default is desireable. -## The JSON Schema Core Vocabulary {#core-vocabulary} +## The JSON Schema Core Vocabulary {#core} + Keywords declared in this section, which all begin with "$", make up the JSON Schema Core vocabulary. These keywords are either required in order to process any schema or meta-schema, including those split across multiple documents, or @@ -811,9 +839,9 @@ exist to reserve keywords for purposes that require guaranteed interoperability. The Core vocabulary MUST be considered mandatory at all times, in order to bootstrap the processing of further vocabularies. Meta-schemas that use the -[`$vocabulary`](#81-meta-schemas-and-vocabularies) keyword to declare the -vocabularies in use MUST explicitly list the Core vocabulary, which MUST have a -value of true indicating that it is required. +[`$vocabulary`](#vocabulary) keyword to declare the vocabularies in use MUST +explicitly list the Core vocabulary, which MUST have a value of true indicating +that it is required. The behavior of a false value for this vocabulary (and only this vocabulary) is undefined, as is the behavior when `$vocabulary` is present but the Core @@ -833,7 +861,8 @@ The current IRI for the corresponding meta-schema is: The "$" prefix is reserved for use by the Core vocabulary. Vocabulary extensions MUST NOT define new keywords that begin with "$". -### Meta-Schemas and Vocabularies +### Meta-Schemas and Vocabularies {#vocabulary} + Two concepts, meta-schemas and vocabularies, are used to inform an implementation how to interpret a schema. Every schema has a meta-schema, which can be declared using the `$schema` keyword. @@ -861,7 +890,8 @@ vocabulary's keywords. Meta-schema authoring is an advanced usage of JSON Schema, so the design of meta-schema features emphasizes flexibility over simplicity. -#### The $schema Keyword +#### The $schema Keyword {#keyword-schema} + The `$schema` keyword is both used as a JSON Schema dialect identifier and as the identifier of a resource which is itself a JSON Schema, which describes the set of valid schemas written for this particular dialect. @@ -882,12 +912,13 @@ the following options: - Refuse to process the schema, as with unsupported required vocabularies - Assume a specific, documented meta-schema - Document the process by which it examines the schema and determines which of a -specific set of meta-schemas to assume + specific set of meta-schemas to assume Values for this property are defined elsewhere in this and other documents, and by other parties. #### The $vocabulary Keyword + The `$vocabulary` keyword is used in meta-schemas to identify the vocabularies available for use in schemas described by that meta-schema, and whether each vocabulary is required or optional. Together, this information forms a dialect. @@ -913,13 +944,14 @@ the vocabulary MUST be considered to be required. If the value is false, then the vocabulary MUST be considered to be optional. ##### Required, optional, and omitted vocabularies + A schema is said to use a dialect and its constituent vocabularies if it is associated with a meta-schema defining the dialect with `$vocabulary`, either through `$schema`, through appropriately defined media type parameters or link relation types, or through documented default implementation-defined behavior in the absence of an explicit meta-schema. If a meta-schema does not contain `$vocabulary`, the set of vocabularies in use is determined according to -{{default-vocabularies}}. +{{default-vocabs}}. Any vocabulary in use by a schema and understood by the implementation MUST be processed in a manner consistent with the semantic definitions contained within @@ -927,22 +959,23 @@ the vocabulary, regardless of whether that vocabulary is required or optional. Any vocabulary that is not present in `$vocabulary` MUST NOT be made available for use in schemas described by that meta-schema, except for the core vocabulary -as specified by the introduction to {{core-vocabulary}}. +as specified by the introduction to {{core}}. Implementations that do not support a vocabulary required by a schema MUST refuse to process that schema. Implementations that do not support a vocabulary that is optionally used by a schema SHOULD proceed with processing the schema. The keywords will be -considered to be unrecognized keywords as addressed by -{{unknown-keywords}}. Note that since the recommended behavior for such -keywords is to collect them as annotations, vocabularies consisting only of -annotations will have the same behavior when used optionally whether the -implementation supports them or not. This allows annotation-only vocabularies to -be supported without custom code, even in implementations that do not support -providing custom code for extension vocabularies. +considered to be unrecognized keywords as addressed by {{unrecognized}}. Note +that since the recommended behavior for such keywords is to collect them as +annotations, vocabularies consisting only of annotations will have the same +behavior when used optionally whether the implementation supports them or not. +This allows annotation-only vocabularies to be supported without custom code, +even in implementations that do not support providing custom code for extension +vocabularies. ##### Vocabularies are schema resource-scoped + The `$vocabulary` keyword SHOULD be used in the root schema of any schema resource intended for use as a meta-schema. It MUST NOT appear in subschemas. @@ -952,6 +985,7 @@ own meta-schema M' without requiring the validator to understand the vocabularies declared by M. ##### Vocabulary and non-vocabulary keywords + Keywords from different vocabularies, as well as non-vocabulary extension keywords, can have identical names. These are not considered to be the same keyword from the perspective of enabling or disabling them through @@ -963,9 +997,10 @@ governed by `$vocabulary` even in implementations that do not support any extension vocabularies. Guidance regarding vocabularies with identically-named keywords is provided in -[Appendix D.1](#d1-best-practices-for-vocabulary-and-meta-schema-authors). +{{vocab-practices}}. + +##### Default vocabularies {#default-vocabs} -##### Default vocabularies {#default-vocabularies} If `$vocabulary` is absent, an implementation MAY determine behavior based on the meta-schema if it is recognized from the IRI value of the referring schema's `$schema` keyword. This is how behavior (such as Hyper-Schema usage) has been @@ -981,12 +1016,13 @@ For example, an implementation that is a validator SHOULD assume the use of all vocabularies in this specification and the companion Validation specification. ##### Non-inheritability of vocabularies + Note that the processing restrictions on `$vocabulary` mean that meta-schemas that reference other meta-schemas using `$ref` or similar keywords do not automatically inherit the vocabulary declarations of those other meta-schemas. All such declarations must be repeated in the root of each schema document intended for use as a meta-schema. This is demonstrated in [the example -meta-schema](#d2-example-meta-schema-with-vocabulary-declarations).[^3] +meta-schema](#example-meta-schema).[^3] [^3]: This requirement allows implementations to find all vocabulary requirement information in a single place for each meta-schema. As schema extensibility @@ -996,12 +1032,14 @@ possibilities and search for vocabularies in referenced meta-schemas would be overly burdensome. #### Updates to Meta-Schema and Vocabulary IRIs + Updated vocabulary and meta-schema IRIs MAY be published between specification drafts in order to correct errors. Implementations SHOULD consider IRIs dated after this specification draft and before the next to indicate the same syntax and semantics as those listed here. ### Base IRI, Anchors, and Dereferencing + To differentiate between schemas in a vast ecosystem, schemas are identified by [IRI](#rfc3987), and can embed references to other schemas by specifying their IRI. @@ -1011,6 +1049,7 @@ used to construct a relative IRI-reference. For these keywords, it is necessary to establish a base IRI in order to resolve the reference. #### The $id Keyword {#id-keyword} + The `$id` keyword identifies a schema resource with its [canonical](#rfc6596) IRI. @@ -1035,17 +1074,19 @@ a relative IRI-reference, the base IRI for resolving that reference is the IRI of the parent schema resource. Note that an `$id` consisting of an empty IRI or of the empty fragment only will result in the embedded resource having the same IRI as the encapsulating resource, which SHOULD be considered an error per -{{duplicate-identifiers}}. +{{duplicate-iris}}. If no parent schema object explicitly identifies itself as a resource with `$id`, the base IRI is that of the entire document, as established by the steps -given in the [previous section.](initial-base-iri) +given in the [previous section.](initial-base) ##### Identifying the root schema + The root schema of a JSON Schema document SHOULD contain an `$id` keyword with an [absolute-IRI](#rfc3987) (containing a scheme, but no fragment). -#### Defining location-independent identifiers +#### Defining location-independent identifiers {#anchors} + Using JSON Pointer fragments requires knowledge of the structure of the schema. When writing schema documents with the intention to provide re-usable schemas, it may be preferable to use a plain name fragment that is not tied to any @@ -1066,32 +1107,31 @@ Separately from the usual usage of IRIs, `$dynamicAnchor` indicates that the fragment is an extension point when used with the `$dynamicRef` keyword. This low-level, advanced feature makes it easier to extend recursive schemas such as the meta-schemas, without imposing any particular semantics on that extension. -See the section on [`$dynamicRef`](#8242-dynamic-references-with-dynamicref) -for details. +See the section on [`$dynamicRef`](#dynamic-ref) for details. In most cases, the normal fragment behavior both suffices and is more intuitive. Therefore it is RECOMMENDED that `$anchor` be used to create plain name fragments unless there is a clear need for `$dynamicAnchor`. If present, the value of these keywords MUST be a string and MUST conform to the -plain name fragment identifier syntax defined in -{{fragment-identifiers}}.[^4] +plain name fragment identifier syntax defined in {{fragments}}.[^4] [^4]: Note that the anchor string does not include the "#" character, as it is not a IRI-reference. An `$anchor`: "foo" becomes the fragment `#foo` when used in a IRI. See below for full examples. -#### Duplicate schema identifiers {#duplicate-identifiers} +#### Duplicate schema identifiers {#duplicate-iris} + A schema MAY (and likely will) have multiple IRIs, but there is no way for an IRI to identify more than one schema. When multiple schemas attempt to identify as the same IRI through the use of `$id`, `$anchor`, `$dynamicAnchor`, or any other mechanism, implementations SHOULD raise an error condition. Otherwise the result is undefined, and even if documented will not be interoperable. -#### Schema References -Several keywords can be used to reference a schema which is to be applied to the -current instance location. `$ref` and `$dynamicRef` are applicator keywords, -applying the referenced schema to the instance. +#### Schema References {#references} Several keywords can be used to reference a +schema which is to be applied to the current instance location. `$ref` and +`$dynamicRef` are applicator keywords, applying the referenced schema to the +instance. As the values of `$ref` and `$dynamicRef` are IRI References, this allows the possibility to externalise or divide a schema across multiple files, and @@ -1103,7 +1143,8 @@ if it is a network-addressable URL, and implementations SHOULD NOT assume they should perform a network operation when they encounter a network-addressable IRI. -##### Direct References with $ref +##### Direct References with $ref {#ref} + The `$ref` keyword is an applicator that is used to reference a statically identified schema. Its results are the results of the referenced schema.[^5] @@ -1115,7 +1156,8 @@ Resolved against the current IRI base, it produces the IRI of the schema to apply. This resolution is safe to perform on schema load, as the process of evaluating an instance cannot change how the reference resolves. -##### Dynamic References with $dynamicRef +##### Dynamic References with $dynamicRef {#dynamic-ref} + The `$dynamicRef` keyword is an applicator that allows for deferring the full resolution until runtime, at which point it is resolved each time it is encountered while evaluating an instance. @@ -1126,23 +1168,22 @@ reference themselves). The extension point is defined with `$dynamicAnchor` and only exhibits runtime dynamic behavior when referenced with `$dynamicRef`. The value of the `$dynamicRef` property MUST be a string which is a -IRI-Reference that contains a valid [plain name -fragment](#822-defining-location-independent-identifiers). Resolved against the -current IRI base, it indicates the schema resource used as the starting point -for runtime resolution. This initial resolution is safe to perform on schema -load. +IRI-Reference that contains a valid [plain name fragment](#anchors). Resolved +against the current IRI base, it indicates the schema resource used as the +starting point for runtime resolution. This initial resolution is safe to +perform on schema load. The schema to apply is the outermost schema resource in the [dynamic -scope](#71-lexical-scope-and-dynamic-scope) that defines a `$dynamicAnchor` that -matches the plain name fragment in the initially resolved IRI. +scope](#scopes) that defines a `$dynamicAnchor` that matches the plain name +fragment in the initially resolved IRI. -For a full example using these keyword, see [Appendix -C](#appendix-c-example-of-recursive-schema-extension).[^6] +For a full example using these keyword, see {{recursive-example}}.[^6] [^6]: The difference between the hyper-schema meta-schema in pre-2019 drafts and an this draft dramatically demonstrates the utility of these keywords. -#### Schema Re-Use With $defs +#### Schema Re-Use With $defs {#defs} + The `$defs` keyword reserves a location for schema authors to inline re-usable JSON Schemas into a more general schema. The keyword does not directly affect the validation result. @@ -1167,6 +1208,7 @@ the positive integer constraint is a subschema in `$defs`: ``` ### Comments With $comment + This keyword reserves a location for comments from schema authors to readers or maintainers of the schema. @@ -1176,9 +1218,9 @@ and editing this keyword. The value of this keyword MAY be used in debug or error output which is intended for developers making use of schemas. Schema vocabularies SHOULD allow `$comment` within any object containing -vocabulary keywords. Implementations MAY assume `$comment` is allowed unless -the vocabulary specifically forbids it. Vocabularies MUST NOT specify any -effect of `$comment` beyond what is described in this specification. +vocabulary keywords. Implementations MAY assume `$comment` is allowed unless the +vocabulary specifically forbids it. Vocabularies MUST NOT specify any effect of +`$comment` beyond what is described in this specification. Tools that translate other media types or programming languages to and from `application/schema+json` MAY choose to convert that media type or programming @@ -1198,7 +1240,8 @@ MUST NOT be collected as an annotation result. ### Loading a Schema -#### Initial Base IRI {#initial-base-iri} +#### Initial Base IRI {#initial-base} + [RFC 3987 Section 6.5](#rfc3987) and [RFC 3986 Section 5.1](#rfc3986) defines how to determine the default base IRI of a document. @@ -1212,8 +1255,8 @@ and [RFC 3986 section 5](#rfc3986). If no source is known, or no IRI scheme is known for the source, a suitable implementation-specific default IRI MAY be used as described in [RFC 3987 -Section 6.5](#rfc3987) and [RFC 3986 Section 5.1.4](#rfc3986). It is -RECOMMENDED that implementations document any default base IRI that they assume. +Section 6.5](#rfc3987) and [RFC 3986 Section 5.1.4](#rfc3986). It is RECOMMENDED +that implementations document any default base IRI that they assume. If a schema object is embedded in a document of another media type, then the initial base IRI is determined according to the rules of that media type. @@ -1223,22 +1266,24 @@ schema, this base IRI SHOULD be considered the canonical IRI of the schema document's root schema resource. #### Loading a referenced schema + The use of IRIs to identify remote schemas does not necessarily mean anything is downloaded, but instead JSON Schema implementations SHOULD understand ahead of time which schemas they will be using, and the IRIs that identify them. When schemas are downloaded, for example by a generic user-agent that does not know until runtime which schemas to download, see [Usage for -Hypermedia](#951-usage-for-hypermedia). +Hypermedia](#hypermedia). Implementations SHOULD be able to associate arbitrary IRIs with an arbitrary schema and/or automatically associate a schema's `$id`-given IRI, depending on the trust that the validator has in the schema. Such IRIs and schemas can be supplied to an implementation prior to processing instances, or may be noted within a schema document as it is processed, producing associations as shown in -[Appendix A](#appendix-a-schema-identification-examples). +{{idexamples}}. #### Detecting a Meta-Schema + Implementations MUST recognize a schema as a meta-schema if it is being examined because it was identified as such by another schema's `$schema` keyword. This means that a single schema document might sometimes be considered a regular @@ -1257,9 +1302,10 @@ Meta-schema authors MUST NOT expect such features to be interoperable across implementations. ### Dereferencing + Schemas can be identified by any IRI that has been given to them, including a -JSON Pointer or their IRI given directly by `$id`. In all cases, dereferencing -a `$ref` reference involves first resolving its value as a IRI reference against +JSON Pointer or their IRI given directly by `$id`. In all cases, dereferencing a +`$ref` reference involves first resolving its value as a IRI reference against the current base IRI per [RFC 3986](#rfc3986). If the resulting IRI identifies a schema within the current document, or within @@ -1304,7 +1350,8 @@ described by Hyper-Schema, it is expected that new schemas will be added to the system dynamically, so placing an absolute requirement of pre-loading schema documents is not feasible. -#### JSON Pointer fragments and embedded schema resources {#json-pointer-embedded} +#### JSON Pointer fragments and embedded schema resources {#embedded} + Since JSON Pointer IRI fragments are constructed based on the structure of the schema document, an embedded schema resource and its subschemas can be identified by JSON Pointer fragments relative to either its own canonical IRI, @@ -1312,8 +1359,8 @@ or relative to any containing resource's IRI. Conceptually, a set of linked schema resources should behave identically whether each resource is a separate document connected with [schema -references](#824-schema-references), or is structured as a single document with -one or more schema resources embedded as subschemas. +references](#referenced), or is structured as a single document with one or more +schema resources embedded as subschemas. Since IRIs involving JSON Pointer fragments relative to the parent schema resource's IRI cease to be valid when the embedded schema is moved to a separate @@ -1392,9 +1439,10 @@ behavior (, Further examples of such non-canonical IRI construction, as well as the appropriate canonical IRI-based fragments to use instead, are provided in -[Appendix A](#appendix-a-schema-identification-examples). +{{idexamples}}. ### Compound Documents + A Compound Schema Document is defined as a JSON document (sometimes called a "bundled" schema) which has multiple embedded JSON Schema Resources bundled into the same document to ease transportation. @@ -1404,6 +1452,7 @@ following standard schema loading and processing requirements, including determining vocabulary support. #### Bundling + The bundling process for creating a Compound Schema Document is defined as taking references (such as `$ref`) to an external Schema Resource and embedding the referenced Schema Resources within the referring document. Bundling SHOULD @@ -1442,6 +1491,7 @@ hand, potentially without individual Schema Resources existing on their own previously. #### Differing and Default Dialects + When multiple schema resources are present in a single document, schema resources which do not define with which dialect they should be processed MUST be processed with the same dialect as the enclosing resource. @@ -1451,6 +1501,7 @@ resources MAY specify different processing dialects using the `$schema` values from their enclosing resource. #### Validating + Given that a Compound Schema Document may have embedded resources which identify as using different dialects, these documents SHOULD NOT be validated by applying a meta-schema to the Compound Schema Document as an instance. It is RECOMMENDED @@ -1470,19 +1521,20 @@ meta-schema. ### Caveats #### Guarding Against Infinite Recursion + A schema MUST NOT be run into an infinite loop against an instance. For example, if two schemas `#alice` and `#bob` both have an `allOf` property that refers to the other, a naive validator might get stuck in an infinite recursive loop trying to validate the instance. Schemas SHOULD NOT make use of infinite recursive nesting like this; the behavior is undefined. -#### References to Possible Non-Schemas {#non-schema-references} +#### References to Possible Non-Schemas {#non-schemas} + Subschema objects (or booleans) are recognized by their use with known -applicator keywords or with location-reserving keywords such as -[`$defs`](#825-schema-re-use-with-defs) that take one or more subschemas as a -value. These keywords may be `$defs` and the standard applicators from this -document, or extension keywords from a known vocabulary, or -implementation-specific custom keywords. +applicator keywords or with location-reserving keywords such as [`$defs`](#defs) +that take one or more subschemas as a value. These keywords may be `$defs` and +the standard applicators from this document, or extension keywords from a known +vocabulary, or implementation-specific custom keywords. Multi-level structures of unknown keywords are capable of introducing nested subschemas, which would be subject to the processing rules for `$id`. Therefore, @@ -1507,13 +1559,15 @@ relied upon for interoperability. ### Associating Instances and Schemas -#### Usage for Hypermedia +#### Usage for Hypermedia {#hypermedia} + JSON has been adopted widely by HTTP servers for automated APIs and robots. This section describes how to enhance processing of JSON documents in a more RESTful manner when used with protocols that support media types and [Web linking](#rfc8288). ##### Linking to a Schema + It is RECOMMENDED that instances described by a schema provide a link to a downloadable JSON Schema using the link relation "describedby", as defined by [Linked Data Protocol 1.0, section 8.1](#w3crec-ldp-20150226). @@ -1526,6 +1580,7 @@ Link: ; rel="describedby" ``` ##### Usage Over HTTP + When used for hypermedia systems over a network, [HTTP](#rfc7231) is frequently the protocol of choice for distributing schemas. Misbehaving clients can pose problems for server maintainers if they pull a schema over the network more @@ -1550,6 +1605,7 @@ Clients SHOULD be able to make requests with a "From" header so that server operators can contact the owner of a potentially misbehaving script. ## A Vocabulary for Applying Subschemas + This section defines a vocabulary of applicator keywords that are RECOMMENDED for use as the basis of other vocabularies. @@ -1559,9 +1615,11 @@ vocabulary as if its IRI were present with a value of true. The current IRI for this vocabulary, known as the Applicator vocabulary, is: `https://json-schema.org/draft/next/vocab/applicator`. -The current IRI for the corresponding meta-schema is: `https://json-schema.org/draft/next/meta/applicator`. +The current IRI for the corresponding meta-schema is: +`https://json-schema.org/draft/next/meta/applicator`. ### Keyword Independence + Schema keywords typically operate independently, without affecting each other's outcomes. @@ -1569,12 +1627,13 @@ For schema author convenience, there are some exceptions among the keywords in this vocabulary: - `additionalProperties`, whose behavior is defined in terms of `properties` and -`patternProperties` + `patternProperties` - `items`, whose behavior is defined in terms of `prefixItems` - `contains`, whose behavior is affected by the presence and value of -`minContains` + `minContains` + +### Keywords for Applying Subschemas in Place {#in-place} -### Keywords for Applying Subschemas in Place These keywords apply subschemas to the same location in the instance as the parent schema is being applied. They allow combining or modifying the subschema results in various ways. @@ -1583,14 +1642,16 @@ Subschemas of these keywords evaluate the instance completely independently such that the results of one such subschema MUST NOT impact the results of sibling subschemas. Therefore subschemas may be applied in any order. -#### Keywords for Applying Subschemas With Logic +#### Keywords for Applying Subschemas With Logic {#logic} + These keywords correspond to logical operators for combining or modifying the boolean assertion results of the subschemas. They have no direct impact on annotation collection, although they enable the same annotation keyword to be applied to an instance location with different values. Annotation keywords define their own rules for combining such values. -##### allOf +##### allOf {#allof} + This keyword's value MUST be a non-empty array. Each item of the array MUST be a valid JSON Schema. @@ -1598,6 +1659,7 @@ An instance validates successfully against this keyword if it validates successfully against all schemas defined by this keyword's value. ##### anyOf + This keyword's value MUST be a non-empty array. Each item of the array MUST be a valid JSON Schema. @@ -1607,26 +1669,29 @@ that when annotations are being collected, all subschemas MUST be examined so that annotations are collected from each subschema that validates successfully. ##### oneOf + This keyword's value MUST be a non-empty array. Each item of the array MUST be a valid JSON Schema. An instance validates successfully against this keyword if it validates successfully against exactly one schema defined by this keyword's value. -##### not +##### not {#not} + This keyword's value MUST be a valid JSON Schema. An instance is valid against this keyword if it fails to validate successfully against the schema defined by this keyword. -#### Keywords for Applying Subschemas Conditionally +#### Keywords for Applying Subschemas Conditionally {#conditional} + Three of these keywords work together to implement conditional application of a subschema based on the outcome of another subschema. The fourth is a shortcut for a specific conditional case. `if`, `then`, and `else` MUST NOT interact with each other across subschema -boundaries. In other words, an `if` in one branch of an `allOf` MUST NOT have -an impact on a `then` or `else` in another branch. +boundaries. In other words, an `if` in one branch of an `allOf` MUST NOT have an +impact on a `then` or `else` in another branch. There is no default behavior for `if`, `then`, or `else` when they are not present. In particular, they MUST NOT be treated as if present with an empty @@ -1634,6 +1699,7 @@ schema, and when `if` is not present, both `then` and `else` MUST be entirely ignored. ##### if + This keyword's value MUST be a valid JSON Schema. This validation outcome of this keyword's subschema has no direct effect on the @@ -1646,11 +1712,12 @@ be valid against the subschema value of the `then` keyword, if present. Instances that fail to validate against this keyword's subschema MUST also be valid against the subschema value of the `else` keyword, if present. -If [annotations](#77-annotations) are being collected, they are collected from -this keyword's subschema in the usual way, including when the keyword is present +If [annotations](#annotations) are being collected, they are collected from this +keyword's subschema in the usual way, including when the keyword is present without either `then` or `else`. ##### then + This keyword's value MUST be a valid JSON Schema. When `if` is present, and the instance successfully validates against its @@ -1663,6 +1730,7 @@ against this keyword, for either validation or annotation collection purposes, in such cases. ##### else + This keyword's value MUST be a valid JSON Schema. When `if` is present, and the instance fails to validate against its subschema, @@ -1675,6 +1743,7 @@ the instance against this keyword, for either validation or annotation collection purposes, in such cases. ##### dependentSchemas + This keyword specifies subschemas that are evaluated if the instance is an object and contains a certain property. @@ -1688,6 +1757,7 @@ property. Omitting this keyword has the same behavior as an empty object. ##### propertyDependencies + This keyword specifies subschemas that are evaluated if the instance is an object and contains a certain property with a certain string value. @@ -1702,6 +1772,7 @@ property. Omitting this keyword has the same behavior as an empty object. ### Keywords for Applying Subschemas to Child Instances + Each of these keywords defines a rule for applying its subschema(s) to child instances, specifically object properties and array items, and combining their results. @@ -1709,6 +1780,7 @@ results. #### Keywords for Applying Subschemas to Arrays ##### prefixItems + The value of "prefixItems` MUST be a non-empty array of valid JSON Schemas. Validation succeeds if each element of the instance validates against the @@ -1719,12 +1791,12 @@ and the instance value are affected by this keyword. This keyword produces an annotation value which is the largest index to which this keyword applied a subschema. The value MAY be a boolean true if a subschema was applied to every index of the instance, such as is produced by the `items` -keyword. This annotation affects the behavior of `items` and -`unevaluatedItems`. +keyword. This annotation affects the behavior of `items` and `unevaluatedItems`. Omitting this keyword has the same assertion behavior as an empty array. -##### items +##### items {#items} + The value of `items` MUST be a valid JSON Schema. This keyword applies its subschema to all instance elements at indexes greater @@ -1754,6 +1826,7 @@ collection MUST do so. #### Keywords for Applying Subschemas to Objects ##### properties + The value of `properties` MUST be an object. Each value of this object MUST be a valid JSON Schema. @@ -1769,6 +1842,7 @@ the Unevaluated vocabulary. Omitting this keyword has the same assertion behavior as an empty object. ##### patternProperties + The value of `patternProperties` MUST be an object. Each property name of this object SHOULD be a valid regular expression, according to the ECMA-262 regular expression dialect. Each property value of this object MUST be a valid JSON @@ -1787,7 +1861,8 @@ behavior of `additionalProperties` (in this vocabulary) and Omitting this keyword has the same assertion behavior as an empty object. -##### additionalProperties +##### additionalProperties {#additionalproperties} + The value of `additionalProperties` MUST be a valid JSON Schema. The behavior of this keyword depends on the presence and annotation results of @@ -1821,6 +1896,7 @@ Record](https://github.com/json-schema-org/json-schema-spec/tree/HEAD/adr/2022-0 for further details. ##### propertyNames + The value of `propertyNames` MUST be a valid JSON Schema. If the instance is an object, this keyword validates if every property name in @@ -1832,6 +1908,7 @@ Omitting this keyword has the same behavior as an empty schema. #### Other Keywords for Applying Subschemas ##### maxContains + The value of this keyword MUST be a non-negative integer. This keyword modifies the behavior of `contains` within the same schema object, @@ -1841,6 +1918,7 @@ Validation MUST always succeed against this keyword. The value of this keyword is used as its annotation result. ##### minContains + The value of this keyword MUST be a non-negative integer. This keyword modifies the behavior of `contains` within the same schema object, @@ -1849,11 +1927,12 @@ as described below in the section for that keyword. Validation MUST always succeed against this keyword. The value of this keyword is used as its annotation result. -Per {{default-behaviors}}, omitted keywords MUST NOT produce annotation -results. However, as described in the section for `contains`, the absence of -this keyword's annotation causes `contains` to assume a minimum value of 1. +Per {{default-behaviors}}, omitted keywords MUST NOT produce annotation results. +However, as described in the section for `contains`, the absence of this +keyword's annotation causes `contains` to assume a minimum value of 1. ##### contains + The value of this keyword MUST be a valid JSON Schema. This keyword applies its subschema to array elements or object property values. @@ -1890,6 +1969,7 @@ use by other keywords. This is to ensure that all possible annotations are collected. ## A Vocabulary for Unevaluated Locations + The purpose of these keywords is to enable schema authors to apply subschemas to array items or object properties that have not been successfully evaluated against any dynamic-scope subschema of any adjacent keywords. @@ -1925,16 +2005,18 @@ The current IRI for the corresponding meta-schema is: `https://json-schema.org/draft/next/meta/unevaluated`. ### Keyword Independence + Schema keywords typically operate independently, without affecting each other's outcomes. However, the keywords in this vocabulary are notable exceptions: - `unevaluatedItems`, whose behavior is defined in terms of annotations from -`prefixItems`, `items`, `contains`, and itself + `prefixItems`, `items`, `contains`, and itself - `unevaluatedProperties`, whose behavior is defined in terms of annotations -from `properties`, `patternProperties`, `additionalProperties`, `contains`, and -itself + from `properties`, `patternProperties`, `additionalProperties`, `contains`, + and itself + +### unevaluatedItems {#unevaluateditems} -### unevaluatedItems The value of `unevaluatedItems` MUST be a valid JSON Schema. The behavior of this keyword depends on the annotation results of adjacent @@ -1942,10 +2024,8 @@ keywords that apply to the instance location being validated. Specifically, the annotations from `prefixItems`, `items`, and `contains`, which can come from those keywords when they are adjacent to the `unevaluatedItems` keyword. Those three annotations, as well as `unevaluatedItems`, can also result from any and -all adjacent [in-place -applicator](#102-keywords-for-applying-subschemas-in-place) keywords. This -includes but is not limited to the in-place applicators defined in this -document. +all adjacent [in-place applicator](#in-place) keywords. This includes but is not +limited to the in-place applicators defined in this document. If no relevant annotations are present, the `unevaluatedItems` subschema MUST be applied to all locations in the array. If a boolean true value is present from @@ -1966,7 +2046,8 @@ the behavior of `items`. This annotation affects the behavior of Omitting this keyword has the same assertion behavior as an empty schema. -### unevaluatedProperties +### unevaluatedProperties {#unevaluatedproperties} + The value of `unevaluatedProperties` MUST be a valid JSON Schema. The behavior of this keyword depends on the annotation results of adjacent @@ -1975,9 +2056,8 @@ annotations from `properties`, `patternProperties`, `contains`, and `additionalProperties`, which can come from those keywords when they are adjacent to the `unevaluatedProperties` keyword. Those four annotations, as well as `unevaluatedProperties`, can also result from any and all adjacent [in-place -applicator](#102-keywords-for-applying-subschemas-in-place) keywords. This -includes but is not limited to the in-place applicators defined in this -document. +applicator](#in-place) keywords. This includes but is not limited to the +in-place applicators defined in this document. Validation with `unevaluatedProperties` applies only to the child values of instance names that do not appear in the `properties`, `patternProperties`, @@ -1998,13 +2078,15 @@ validated by this keyword's subschema. This annotation affects the behavior of Omitting this keyword has the same assertion behavior as an empty schema. -## Output Formatting +## Output Formatting {#output} + JSON Schema is defined to be platform-independent. As such, to increase compatibility across platforms, implementations SHOULD conform to a standard validation output format. This section describes the minimum requirements that consumers will need to properly interpret validation results. ### Format + JSON Schema output is defined using the JSON Schema data instance model as described in section 4.2.1. Implementations MAY deviate from this as supported by their specific languages and platforms, however it is RECOMMENDED that the @@ -2012,6 +2094,7 @@ output be convertible to the JSON format defined herein via serialization or other means. ### Output Formats + This specification defines three output formats. See the "Output Structure" section for the requirements of each format. @@ -2028,6 +2111,7 @@ of the "list" or "hierarchical" formats. Implementations SHOULD specify in their documentation which formats they support. ### Minimum Information + Beyond the simplistic "flag" output, additional information is useful to aid in debugging a schema or instance. Each sub-result SHOULD contain the information contained within this section at a minimum. @@ -2038,6 +2122,7 @@ unit. Implementations MAY elect to provide additional information. #### Evaluation path + The evaluation path to the schema object that produced the output unit. The value MUST be expressed as a JSON Pointer, and it MUST include any by-reference applicators such as `$ref` or `$dynamicRef`.[^13] @@ -2055,11 +2140,12 @@ due to the inclusion of these by-reference applicator keywords. The JSON key for this information is "evaluationPath". #### Schema Location + The absolute, dereferenced location of the schema object that produced the -output unit. The value MUST be expressed using the canonical IRI of the -relevant schema resource plus a JSON Pointer fragment that indicates the schema -object that produced the output. It MUST NOT include by-reference applicators -such as `$ref` or `$dynamicRef`.[^14] +output unit. The value MUST be expressed using the canonical IRI of the relevant +schema resource plus a JSON Pointer fragment that indicates the schema object +that produced the output. It MUST NOT include by-reference applicators such as +`$ref` or `$dynamicRef`.[^14] [^14]: Note that "absolute" here is in the sense of "absolute filesystem path" (meaning the complete location) rather than the "absolute-IRI" terminology from @@ -2073,12 +2159,14 @@ https://example.com/schemas/common#/$defs/allOf/1 The JSON key for this information is "schemaLocation". #### Instance Location + The location of the JSON value within the instance being validated. The value MUST be expressed as a JSON Pointer. The JSON key for this information is "instanceLocation". #### Errors + Any errors produced by the validation. This property MUST NOT be included if the validation was successful. The value for this property MUST be an object where the keys are the names of keywords and the values are the error message produced @@ -2098,6 +2186,7 @@ Implementations will need to provide this. The JSON key for this information is "errors". #### Annotations + Any annotations produced by the evaluation. This property MUST NOT be included if the validation result of the containing subschema was unsuccessful. @@ -2110,6 +2199,7 @@ list of keywords, whereas `title` produces a string). The JSON key for this information is "annotations". #### Dropped Annotations + Any annotations produced and subsequently dropped by the evaluation due to an unsuccessful validation result of the containing subschema. This property MAY be included if the validation result of the containing subschema was unsuccessful. @@ -2129,6 +2219,7 @@ list of keywords, whereas `title` produces a string). The JSON key for this information is "droppedAnnotations". #### Results from Subschemas + Evaluation results generated by applying a subschema to the instance or a child of the instance. Keywords which have multiple subschemas (e.g. `anyOf`) will generally generate an output unit for each subschema. In order to accommodate @@ -2225,15 +2316,15 @@ Passing instance The failing instance will produce the following errors: - The value at `/foo` evaluated at `/properties/foo/allOf/0` by following the -path `/properties/foo/allOf/0` by the `required` keyword is missing the property -`unspecified-prop`. + path `/properties/foo/allOf/0` by the `required` keyword is missing the + property `unspecified-prop`. - The value at `/foo/foo-prop` evaluated at -`/properties/foo/allOf/1/properties/foo-prop` by following the path -`/properties/foo/allOf/1/properties/foo-prop` by the `const` keyword is not the -constant value 1. + `/properties/foo/allOf/1/properties/foo-prop` by following the path + `/properties/foo/allOf/1/properties/foo-prop` by the `const` keyword is not + the constant value 1. - The value at `/bar/bar-prop` evaluated at `/$defs/bar/properties/bar-prop` by -following the path `/properties/bar/$ref/properties/bar-prop` by the `type` -keyword is not a number.[^16][^17] + following the path `/properties/bar/$ref/properties/bar-prop` by the `type` + keyword is not a number.[^16][^17] [^16]: `minimum` doesn't produce an error because it only operates on instances that are numbers. @@ -2246,28 +2337,29 @@ allows their users to craft their own messages. The passing instance will produce the following annotations: - The keyword `title` evaluated at `` by following the path `` will produce -`"root"`. + `"root"`. - The keyword `properties` evaluated at `` by following the path `` will produce -`["foo", "bar"]`. + `["foo", "bar"]`. - The keyword `title` evaluated at `/properties/foo` by following the path -`/properties/foo` will produce `"foo-title"`. + `/properties/foo` will produce `"foo-title"`. - The keyword `properties` evaluated at `/properties/foo/allOf/1` by following -the path `/properties/foo/allOf/1` will produce `["foo-prop"]`. + the path `/properties/foo/allOf/1` will produce `["foo-prop"]`. - The keyword `additionalProperties` evaluated at `/properties/foo/allOf/1` by -following the path `/properties/foo/allOf/1` will produce -`["unspecified-prop"]`. + following the path `/properties/foo/allOf/1` will produce + `["unspecified-prop"]`. - The keyword `title` evaluated at `/properties/foo/allOf/1/properties/foo-prop` -by following the path `/properties/foo/allOf/1/properties/foo-prop` will produce -`"foo-prop-title"`. + by following the path `/properties/foo/allOf/1/properties/foo-prop` will + produce `"foo-prop-title"`. - The keyword `title` evaluated at `/$defs/bar` by following the path -`/properties/bar/$ref` will produce `"bar-title"`. + `/properties/bar/$ref` will produce `"bar-title"`. - The keyword `properties` evaluated at `/$defs/bar` by following the path -`/properties/var/$ref` will produce `["bar-prop"]`. + `/properties/var/$ref` will produce `["bar-prop"]`. - The keyword `title` evaluated at `/$defs/bar/properties/bar-prop` by following -the path `/properties/bar/$ref/properties/bar-prop` will produce -`"bar-prop-title"`. + the path `/properties/bar/$ref/properties/bar-prop` will produce + `"bar-prop-title"`. #### Flag + In the simplest case, merely the boolean result for the "valid" valid property needs to be fulfilled. For this format, all other information is explicitly omitted. @@ -2285,6 +2377,7 @@ keyword contains five subschemas, and the second one passes, there is no need to check the other three. The logic can simply return with success. #### List + The "List" structure is a flat list of output units contained within a root output unit. @@ -2402,6 +2495,7 @@ Passing results ``` #### Hierarchical + The "Hierarchical" structure is a tree structure that follows the evaluation path during the validation process. Typically, it will resemble the schema as if all referenced schemas were inlined in place of their associated by-reference @@ -2599,10 +2693,12 @@ Passing results (annotations) ``` #### Output validation schemas + For convenience, JSON Schema has been provided to validate output generated by implementations. Its IRI is: . -## Security Considerations {#security-considerations} +## Security Considerations {#security} + Both schemas and instances are JSON values. As such, all security considerations defined in [RFC 8259](#rfc8259) apply. @@ -2633,6 +2729,7 @@ action based on `$comment` contents. ## IANA Considerations ### application/schema+json + The proposed MIME media type for JSON Schema is defined as follows: Type name:: application @@ -2644,15 +2741,15 @@ Required parameters:: N/A Encoding considerations:: Encoding considerations are identical to those specified for the `application/json` media type. See [JSON](#rfc8259). -Security considerations:: See {{security-considerations}} above. +Security considerations:: See {{security}} above. -Interoperability considerations:: See Sections -[6.2](#62-programming-language-independence), [6.3](#63-mathematical-integers), -and [6.4](#64-regular-expressions) above. +Interoperability considerations:: See Sections [6.2](#language), +[6.3](#integers), and [6.4](#regex) above. -Fragment identifier considerations:: See {{fragment-identifiers}} +Fragment identifier considerations:: See {{fragments}} ### application/schema-instance+json + The proposed MIME media type for JSON Schema Instances that require a JSON Schema-specific media type is defined as follows: @@ -2665,107 +2762,125 @@ Required parameters:: N/A Encoding considerations:: Encoding considerations are identical to those specified for the `application/json` media type. See [JSON](#rfc8259). -Security considerations:: See {{security-considerations}} above. +Security considerations:: See {{security}} above. -Interoperability considerations:: See Sections -[6.2](#62-programming-language-independence), [6.3](#63-mathematical-integers), -and [6.4](#64-regular-expressions) above. +Interoperability considerations:: See Sections [6.2](#language), +[6.3](#integers), and [6.4](#regex) above. -Fragment identifier considerations:: See {{fragment-identifiers}} +Fragment identifier considerations:: See {{fragments}} ## References ### Normative References -#### [RFC2119] +#### [RFC2119] {#rfc2119} + Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>. -#### [RFC3986] +#### [RFC3986] {#rfc3986} + Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <>. -#### [RFC3987] +#### [RFC3987] {#rfc3987} + Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <>. -#### [RFC6839] +#### [RFC6839] {#rfc6839} + Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, <>. -#### [RFC6901] +#### [RFC6901] {#rfc6901} + Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <>. -#### [RFC8259] +#### [RFC8259] {#rfc8259} + Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <>. -#### [W3C.REC-ldp-20150226] +#### [W3C.REC-ldp-20150226] {#w3crec-ldp-20150226} + Malhotra, A., Ed., Arwe, J., Ed., and S. Speicher, Ed., "Linked Data Platform 1.0", W3C REC REC-ldp-20150226, W3C REC-ldp-20150226, 26 February 2015, <>. -#### [ecma262] +#### [ecma262] {#ecma262} + "ECMA-262, 11th edition specification", June 2020, <>. ### Informative References -#### [RFC6596] +#### [RFC6596] {#rfc6596} + Ohye, M. and J. Kupke, "The Canonical Link Relation", RFC 6596, DOI 10.17487/RFC6596, April 2012, <>. -#### [RFC7049] +#### [RFC7049] {#rfc7049} + Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <>. -#### [RFC7231] +#### [RFC7231] {#rfc7231} + Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <>. -#### [RFC8288] +#### [RFC8288] {#rfc8288} + Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <>. #### [W3C.WD-fragid-best-practices-20121025] +{#w3cwd-fragid-best-practices-20121025} + Tennison, J., Ed., "Best Practices for Fragment Identifiers and Media Type Definitions", W3C WD WD-fragid-best-practices-20121025, W3C WD-fragid-best-practices-20121025, 25 October 2012, <>. -#### [W3C.REC-xptr-framework-20030325] +#### [W3C.REC-xptr-framework-20030325] {#w3crec-xptr-framework-20030325} + Maler, E., Ed., Marsh, J., Ed., Walsh, N., Ed., and P. Grosso, Ed., "XPointer Framework", W3C REC REC-xptr-framework-20030325, W3C REC-xptr-framework-20030325, 25 March 2003, <>. -#### [json-schema-validation] +#### [json-schema-validation] {#json-schema-validation} + Wright, A., Andrews, H., and B. Hutton, "JSON Schema Validation: A Vocabulary for Structural Validation of JSON", Work in Progress, Internet-Draft, draft-bhutton-json-schema-validation-01, June 2022, <>. -#### [json-hyper-schema] +#### [json-hyper-schema] {#json-hyper-schema} + Andrews, H. and A. Wright, "JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON", Work in Progress, Internet-Draft, draft-handrews-json-schema-hyperschema-02, November 2017, <>. -#### [xml-names] +#### [xml-names] {#xml-names} + Bray, T., Ed., Hollander, D., Ed., Layman, A., Ed., and R. Tobin, Ed., "Namespaces in XML 1.1 (Second Edition)", August 2006, <>. -## [Appendix] Schema identification examples +## [Appendix] Schema identification examples {#idexamples} + Consider the following schema, which shows `$id` being used to identify both the root schema and various subschemas, and `$anchor` being used to define plain name fragment identifiers. @@ -2794,39 +2909,46 @@ name fragment identifiers. The schemas at the following IRI-encoded [JSON Pointers](#rfc6901) (relative to the root schema) have the following base IRIs, and are identifiable by any -listed IRI in accordance with {{fragment-identifiers}} and -#section(json-pointer-embedded) above. +listed IRI in accordance with {{fragments}} and {{embedded}} above. `#` (document root): canonical (and base) IRI: `https://example.com/root.json` -canonical resource IRI plus pointer fragment: `https://example.com/root.json#` +- canonical resource IRI plus pointer fragment: `https://example.com/root.json#` -`#/$defs/A`: base IRI: `https://example.com/root.json` canonical resource IRI -plus plain fragment: `https://example.com/root.json#foo` canonical resource IRI -plus pointer fragment: `https://example.com/root.json#/$defs/A` +`#/$defs/A`: base IRI: `https://example.com/root.json` +- canonical resource IRI plus plain fragment: + `https://example.com/root.json#foo` +- canonical resource IRI plus pointer fragment: + `https://example.com/root.json#/$defs/A` `#/$defs/B`: canonical (and base) `IRI: https://example.com/other.json` -canonical resource IRI plus pointer fragment: `https://example.com/other.json#` -base IRI of enclosing (root.json) resource plus fragment: -`https://example.com/root.json#/$defs/B` - -`#/$defs/B/$defs/X`: base IRI: `https://example.com/other.json` canonical -resource IRI plus plain fragment: `https://example.com/other.json#bar` canonical -resource IRI plus pointer fragment: `https://example.com/other.json#/$defs/X` -base IRI of enclosing (root.json) resource plus fragment: -`https://example.com/root.json#/$defs/B/$defs/X` +- canonical resource IRI plus pointer fragment: + `https://example.com/other.json#` +- base IRI of enclosing (root.json) resource plus fragment: + `https://example.com/root.json#/$defs/B` + +`#/$defs/B/$defs/X`: base IRI: `https://example.com/other.json` +- canonical resource IRI plus plain fragment: + `https://example.com/other.json#bar` +- canonical resource IRI plus pointer fragment: + `https://example.com/other.json#/$defs/X` +- base IRI of enclosing (root.json) resource plus fragment: + `https://example.com/root.json#/$defs/B/$defs/X` `#/$defs/B/$defs/Y`: canonical (and base) IRI: -`https://example.com/t/inner.json` canonical IRI plus plain fragment: -`https://example.com/t/inner.json#bar` canonical IRI plus pointer fragment: -`https://example.com/t/inner.json#` base IRI of enclosing (other.json) resource -plus fragment: `https://example.com/other.json#/$defs/Y` base IRI of enclosing -(root.json) resource plus fragment: -`https://example.com/root.json#/$defs/B/$defs/Y` +`https://example.com/t/inner.json` +- canonical IRI plus plain fragment: `https://example.com/t/inner.json#bar` +- canonical IRI plus pointer fragment: `https://example.com/t/inner.json#` +- base IRI of enclosing (other.json) resource plus fragment: + `https://example.com/other.json#/$defs/Y` +- base IRI of enclosing (root.json) resource plus fragment: + `https://example.com/root.json#/$defs/B/$defs/Y` `#/$defs/C`: canonical (and base) IRI: -`urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f` canonical IRI plus pointer -fragment: `urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f#` base IRI of enclosing -(root.json) resource plus fragment: `https://example.com/root.json#/$defs/C` +`urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f` +- canonical IRI plus pointer fragment: + `urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f#` +- base IRI of enclosing (root.json) resource plus fragment: + `https://example.com/root.json#/$defs/C` Note: The fragment part of the IRI does not make it canonical or non-canonical, rather, the base IRI used (as part of the full IRI with any fragment) is what @@ -2834,14 +2956,16 @@ determines the canonical nature of the resulting full IRI.[^18] [^18]: Multiple "canonical" IRIs? We Acknowledge this is potentially confusing, and direct you to read the CREF located in the [JSON Pointer fragments and -embedded schema resources](#json-pointer-embedded) section for further comments. +embedded schema resources](#embedded) section for further comments. ## [Appendix] Manipulating schema documents and references + Various tools have been created to rearrange schema documents based on how and where references (`$ref`) appear. This appendix discusses which use cases and actions are compliant with this specification. ### Bundling schema resources into a single document + A set of schema resources intended for use together can be organized with each in its own schema document, all in the same schema document, or any granularity of document grouping in between. @@ -2864,6 +2988,7 @@ schemas under `$defs` do not affect behavior, assuming they are each unique, as they do not appear in the canonical IRIs for the embedded resources. ### Reference removal is not always safe + Attempting to remove all references and produce a single schema document does not, in all cases, produce a schema with identical behavior to the original form. @@ -2875,7 +3000,8 @@ scope of this specification to determine or provide a set of safe `$ref` removal transformations, as they depend not only on the schema structure but also on the intended usage. -## [Appendix] Example of recursive schema extension +## [Appendix] Example of recursive schema extension {#recursive-example} + Consider the following two schemas describing a simple recursive tree structure, where each node in the tree can have a "data" field of any type. The first schema allows and ignores other instance properties. The second is more strict @@ -2973,7 +3099,8 @@ any sort of correlation in JSON structure. ## [Appendix] Working with vocabularies -### Best practices for vocabulary and meta-schema authors +### Best practices for vocabulary and meta-schema authors {#vocab-practices} + Vocabulary authors should take care to avoid keyword name collisions if the vocabulary is intended for broad use, and potentially combined with other vocabularies. JSON Schema does not provide any formal namespacing system, but @@ -3000,8 +3127,8 @@ forbid additional keywords, and MUST not forbid any keywords from the Core vocabulary. It is recommended that meta-schema authors reference each vocabulary's -meta-schema using the [`allOf`](#10211-allof) keyword, although other mechanisms -for constructing the meta-schema may be appropriate for certain use cases. +meta-schema using the [`allOf`](#allof) keyword, although other mechanisms for +constructing the meta-schema may be appropriate for certain use cases. The recursive nature of meta-schemas makes the `$dynamicAnchor` and `$dynamicRef` keywords particularly useful for extending existing meta-schemas, @@ -3021,7 +3148,8 @@ resulting behavior is undefined. Meta-schemas intended for local use, with no need to test for vocabulary support in arbitrary implementations, can safely omit `$vocabulary` entirely. -### Example meta-schema with vocabulary declarations +### Example meta-schema with vocabulary declarations {#example-meta-schema} + This meta-schema explicitly declares both the Core and Applicator vocabularies, together with an extension vocabulary, and combines their meta-schemas with an `allOf`. The extension vocabulary's meta-schema, which describes only the @@ -3114,6 +3242,7 @@ annotation, as explained in the [Validation specification](#json-schema-validation). ## [Appendix] References and generative use cases + While the presence of references is expected to be transparent to validation results, generative use cases such as code generators and UI renderers often consider references to be semantically significant. @@ -3163,6 +3292,7 @@ This style of usage requires the annotation to be in the same object as the reference, which must be recognizable as a reference. ## [Appendix] Acknowledgments + Thanks to Gary Court, Francis Galiegue, Kris Zyp, Geraint Luff, and Henry Andrews for their work on the initial drafts of JSON Schema. @@ -3172,6 +3302,7 @@ Sturgeon, Shawn Silverman, and Karen Etheridge for their submissions and patches to the document. ## [Appendix] Change Log[^19] + [^19]: This section to be removed before leaving Internet-Draft status. ### draft-bhutton-json-schema-next @@ -3182,7 +3313,7 @@ to the document. ### draft-bhutton-json-schema-01 - Improve and clarify the `type`, `contains`, `unevaluatedProperties`, and -`unevaluatedItems` keyword explanations + `unevaluatedItems` keyword explanations - Clarify various aspects of "canonical URIs" - Comment on ambiguity around annotations and `additionalProperties` - Clarify Vocabularies need not be formally defined @@ -3194,7 +3325,7 @@ to the document. - Array-value `items` functionality is now `prefixItems` - `items` subsumes the old function of `additionalItems` - `contains` annotation behavior, and `contains` and `unevaluatedItems` -interactions now specified + interactions now specified - Rename $recursive* to $dynamic*, with behavior modification - $dynamicAnchor defines a fragment like $anchor - $dynamic* (previously $recursive) no longer use runtime base URI determination @@ -3204,33 +3335,33 @@ interactions now specified - Remove media type parameters - Specify Unknown keywords are collected as annotations - Moved `unevaluatedItems` and `unevaluatedProperties` from core into their own -vocabulary + vocabulary ### draft-handrews-json-schema-02 - Update to RFC 8259 for JSON specification - Moved `definitions` from the Validation specification here as `$defs` - Moved applicator keywords from the Validation specification as their own -vocabulary + vocabulary - Moved the schema form of `dependencies` from the Validation specification as -`dependentSchemas` + `dependentSchemas` - Formalized annotation collection - Specified recommended output formats - Defined keyword interactions in terms of annotation and assertion results - Added `unevaluatedProperties` and `unevaluatedItems` - Define `$ref` behavior in terms of the assertion, applicator, and annotation -model + model - Allow keywords adjacent to `$ref` - Note undefined behavior for `$ref` targets involving unknown keywords - Add recursive referencing, primarily for meta-schema extension - Add the concept of formal vocabularies, and how they can be recognized through -meta-schemas + meta-schemas - Additional guidance on initial base URIs beyond network retrieval - Allow "schema" media type parameter for `application/schema+json` - Better explanation of media type parameters and the HTTP Accept header - Use `$id` to establish canonical and base absolute-URIs only, no fragments - Replace plain-name-fragment-only form of `$id` with `$anchor` - Clarified that the behavior of JSON Pointers across `$id` boundary is -unreliable + unreliable ### draft-handrews-json-schema-01 - This draft is purely a clarification with no functional changes @@ -3238,18 +3369,18 @@ unreliable - Clarified $id by use cases - Exhaustive schema identification examples - Replaced "external referencing" with how and when an implementation might know -of a schema from another document + of a schema from another document - Replaced "internal referencing" with how an implementation should recognized -schema identifiers during parsing + schema identifiers during parsing - Dereferencing the former "internal" or "external" references is always the -same process + same process - Minor formatting improvements ### draft-handrews-json-schema-00 - Make the concept of a schema keyword vocabulary more clear - Note that the concept of "integer" is from a vocabulary, not the data model - Classify keywords as assertions or annotations and describe their general -behavior + behavior - Explain the boolean schemas in terms of generalized assertions - Reserve `$comment` for non-user-visible notes about the schema - Wording improvements around `$id` and fragments @@ -3264,7 +3395,7 @@ behavior - Changed `id` to `$id`; all core keywords prefixed with "$" - Clarify and formalize fragments for `application/schema+json` - Note applicability to formats such as CBOR that can be represented in the JSON -data model + data model ### draft-wright-json-schema-00 - Updated references to JSON diff --git a/jsonschema-validation.md b/jsonschema-validation.md index 60ead15a..3d5ed61f 100644 --- a/jsonschema-validation.md +++ b/jsonschema-validation.md @@ -1,6 +1,7 @@ # JSON Schema Validation: A Vocabulary for Structural Validation of JSON ## Abstract + JSON Schema (application/schema+json) has several purposes, one of which is JSON instance validation. This document specifies a vocabulary for JSON Schema to describe the meaning of JSON documents, provide hints for user interfaces @@ -8,6 +9,7 @@ working with JSON data, and to make assertions about what a valid document must look like. ## Note to Readers + The issues list for this draft can be found at . @@ -19,6 +21,7 @@ the homepage, or email the document editors. ## Table of Contents ## Introduction + JSON Schema can be used to require that a given JSON document (an instance) satisfies a certain number of criteria. These criteria are asserted by using keywords described in this specification. In addition, a set of keywords is also @@ -40,6 +43,7 @@ Elements in an array value are said to be unique if no two elements of this array are [equal](#json-schema). ## Overview + JSON Schema validation asserts constraints on the structure of instance data. An instance location that satisfies all asserted constraints is then annotated with any keywords that contain non-assertion information, such as descriptive @@ -53,31 +57,34 @@ document-wide validation process. This specification defines a set of assertion keywords, as well as a small vocabulary of metadata keywords that can be used to annotate the JSON instance -with useful information. The {{format-vocabulary}} keyword is intended -primarily as an annotation, but can optionally be used as an assertion. The -{{content-vocabulary}} keywords +with useful information. The {{format}} keyword is intended primarily as an +annotation, but can optionally be used as an assertion. The {{content}} keywords are annotations for working with documents embedded as JSON strings. ## Interoperability Considerations ### Validation of String Instances + It should be noted that the nul character (\u0000) is valid in a JSON string. An instance to validate may contain a string value with this character, regardless of the ability of the underlying programming language to deal with such data. ### Validation of Numeric Instances + The JSON specification allows numbers with arbitrary precision, and JSON Schema does not add any such bounds. This means that numeric instances processed by JSON Schema can be arbitrarily large and/or have an arbitrarily long decimal part, regardless of the ability of the underlying programming language to deal with such data. -### Regular Expressions +### Regular Expressions {#regexinterop} + Keywords that use regular expressions, or constrain the instance value to be a regular expression, are subject to the interoperability considerations for regular expressions in the [JSON Schema Core](#json-schema) specification. -## Meta-Schema +## Meta-Schema {#meta-schema} + The current IRI for the default JSON Schema dialect meta-schema is `https://json-schema.org/draft/next/schema`. For schema author convenience, this meta-schema describes a dialect consisting of all vocabularies defined in this @@ -93,6 +100,7 @@ after this specification draft and before the next to indicate the same syntax and semantics as those listed here. ## A Vocabulary for Structural Validation + Validation keywords in a schema impose requirements for successful validation of an instance. These keywords are all assertions without any annotation behavior. @@ -105,9 +113,10 @@ The current IRI for this vocabulary, known as the Validation vocabulary, is: The current IRI for the corresponding meta-schema is: `https://json-schema.org/draft/next/meta/validation`. -### Validation Keywords for Any Instance Type +### Validation Keywords for Any Instance Type {#general} #### type + The value of this keyword MUST be either a string or an array. If it is an array, elements of the array MUST be strings and MUST be unique. @@ -120,7 +129,8 @@ its type matches the type represented by the value of the string. If the value of "type" is an array, then an instance validates successfully if its type matches any of the types indicated by the strings in the array. -#### enum +#### enum {#enum} + The value of this keyword MUST be an array. This array SHOULD have at least one element. Elements in the array SHOULD be unique. @@ -130,23 +140,26 @@ one of the elements in this keyword's array value. Elements in the array might be of any type, including null. #### const + The value of this keyword MAY be of any type, including null. -Use of this keyword is functionally equivalent to an [`enum`](#612-enum) with a +Use of this keyword is functionally equivalent to an [`enum`](#enum) with a single value. An instance validates successfully against this keyword if its value is equal to the value of the keyword. -### Validation Keywords for Numeric Instances (number and integer) +### Validation Keywords for Numeric Instances (number and integer) {#numeric} #### multipleOf + The value of `multipleOf` MUST be a number, strictly greater than 0. A numeric instance is valid only if division by this keyword's value results in an integer. #### maximum + The value of `maximum` MUST be a number, representing an inclusive upper limit for a numeric instance. @@ -154,6 +167,7 @@ If the instance is a number, then this keyword validates only if the instance is less than or exactly equal to `maximum`. #### exclusiveMaximum + The value of `exclusiveMaximum` MUST be a number, representing an exclusive upper limit for a numeric instance. @@ -161,6 +175,7 @@ If the instance is a number, then the instance is valid only if it has a value strictly less than (not equal to) `exclusiveMaximum`. #### minimum + The value of `minimum` MUST be a number, representing an inclusive lower limit for a numeric instance. @@ -168,15 +183,17 @@ If the instance is a number, then this keyword validates only if the instance is greater than or exactly equal to `minimum`. #### exclusiveMinimum + The value of `exclusiveMinimum` MUST be a number, representing an exclusive lower limit for a numeric instance. If the instance is a number, then the instance is valid only if it has a value strictly greater than (not equal to) `exclusiveMinimum`. -### Validation Keywords for Strings +### Validation Keywords for Strings {#string} #### maxLength + The value of this keyword MUST be a non-negative integer. A string instance is valid against this keyword if its length is less than, or @@ -186,6 +203,7 @@ The length of a string instance is defined as the number of its characters as defined by [RFC 8259](#rfc8259). #### minLength + The value of this keyword MUST be a non-negative integer. A string instance is valid against this keyword if its length is greater than, @@ -196,7 +214,8 @@ defined by [RFC 8259](#rfc8259). Omitting this keyword has the same behavior as a value of 0. -#### pattern +#### pattern {#pattern} + The value of this keyword MUST be a string. This string SHOULD be a valid regular expression, according to the ECMA-262 regular expression dialect. @@ -206,12 +225,14 @@ instance successfully. Recall: regular expressions are not implicitly anchored. ### Validation Keywords for Arrays #### maxItems + The value of this keyword MUST be a non-negative integer. An array instance is valid against `maxItems` if its size is less than, or equal to, the value of this keyword. #### minItems + The value of this keyword MUST be a non-negative integer. An array instance is valid against `minItems` if its size is greater than, or @@ -220,6 +241,7 @@ equal to, the value of this keyword. Omitting this keyword has the same behavior as a value of 0. #### uniqueItems + The value of this keyword MUST be a boolean. If this keyword has boolean value false, the instance validates successfully. If @@ -231,12 +253,14 @@ Omitting this keyword has the same behavior as a value of false. ### Validation Keywords for Objects #### maxProperties + The value of this keyword MUST be a non-negative integer. An object instance is valid against `maxProperties` if its number of properties is less than, or equal to, the value of this keyword. #### minProperties + The value of this keyword MUST be a non-negative integer. An object instance is valid against `minProperties` if its number of properties @@ -245,6 +269,7 @@ is greater than, or equal to, the value of this keyword. Omitting this keyword has the same behavior as a value of 0. #### required + The value of this keyword MUST be an array. Elements of this array, if any, MUST be strings, and MUST be unique. @@ -254,6 +279,7 @@ the name of a property in the instance. Omitting this keyword has the same behavior as an empty array. #### dependentRequired + The value of this keyword MUST be an object. Properties in this object, if any, MUST be arrays. Elements in each array, if any, MUST be strings, and MUST be unique. @@ -268,9 +294,10 @@ the name of a property in the instance. Omitting this keyword has the same behavior as an empty object. -## Vocabularies for Semantic Content With format {#format-vocabulary} +## Vocabularies for Semantic Content With format {#format} ### Foreword + Structural validation alone may be insufficient to allow an application to correctly utilize certain values. The `format` annotation keyword is defined to allow schema authors to convey semantic information for a fixed subset of values @@ -311,12 +338,13 @@ functionally equivalent to specifying only the Format-Assertion vocabulary since its requirements are a superset of the Format-Annotation vocabulary. ### Implementation Requirements + The `format` keyword functions as defined by the vocabulary which is referenced. -#### Format-Annotation Vocabulary -The value of format MUST be collected as an annotation, if the implementation -supports annotation collection. This enables application-level validation when -schema validation is unavailable or inadequate. +#### Format-Annotation Vocabulary The value of format MUST be collected as an +annotation, if the implementation supports annotation collection. This enables +application-level validation when schema validation is unavailable or +inadequate. Implementations MAY still treat `format` as an assertion in addition to an annotation and attempt to validate the value's conformance to the specified @@ -332,9 +360,9 @@ full validation support when the Format-Assertion vocabulary is not specified. When the implementation is configured for assertion behavior, it: - SHOULD provide an implementation-specific best effort validation for each -format attribute defined below; + format attribute defined below; - MAY choose to implement validation of any or all format attributes as a no-op -by always producing a validation result of true;[^3] + by always producing a validation result of true;[^3] [^3]: This matches the current reality of implementations, which provide widely varying levels of validation, including no validation at all, for some or all @@ -343,6 +371,7 @@ annotation behavior and performing semantic validation in the application, which is the recommended best practice. #### Format-Assertion Vocabulary + When the Format-Assertion vocabulary is declared with a value of true, implementations MUST provide full validation support for all of the formats defined by this specificaion. Implementations that cannot provide full @@ -350,12 +379,12 @@ validation support MUST refuse to process the schema. An implementation that supports the Format-Assertion vocabulary: - MUST still collect `format` as an annotation if the implementation supports -annotation collection; + annotation collection; - MUST evaluate `format` as an assertion; - MUST implement syntactic validation for all format attributes defined in this -specification, and for any additional format attributes that it recognizes, such -that there exist possible instance values of the correct type that will fail -validation. The requirement for minimal validation of format attributes is + specification, and for any additional format attributes that it recognizes, +such that there exist possible instance values of the correct type that will +fail validation. The requirement for minimal validation of format attributes is intentionally vague and permissive, due to the complexity involved in many of the attributes. Note in particular that the requirement is limited to syntactic checking; it is not to be expected that an implementation would send an email, @@ -375,7 +404,7 @@ It is RECOMMENDED that implementations use a common parsing library for each format, or a well-known regular expression. Implementations SHOULD clearly document how and to what degree each format attribute is validated. -The [standard core and validation meta-schema](#5-meta-schema) includes this +The [standard core and validation meta-schema](#meta-schema) includes this vocabulary in its `$vocabulary` keyword with a value of false, since by default implementations are not required to support this keyword as an assertion. Supporting the format vocabulary with a value of true is understood to greatly @@ -383,6 +412,7 @@ increase code size and in some cases execution time, and will not be appropriate for all implementations. #### Custom format attributes + Implementations MAY support custom format attributes. Save for agreement between parties, schema authors SHALL NOT expect a peer implementation to support such custom format attributes. An implementation MUST NOT fail to collect unknown @@ -398,6 +428,7 @@ desired. ### Defined Formats #### Dates, Times, and Duration + These attributes apply to string instances. Date and time format names are derived from [RFC 3339, section 5.6](#rfc3339). @@ -408,13 +439,13 @@ Implementations supporting formats SHOULD implement support for the following attributes: - *date-time:* A string instance is valid against this attribute if it is a -valid representation according to the "date-time" ABNF rule (referenced above) + valid representation according to the "date-time" ABNF rule (referenced above) - *date:* A string instance is valid against this attribute if it is a valid -representation according to the "full-date" ABNF rule (referenced above) + representation according to the "full-date" ABNF rule (referenced above) - *time:* A string instance is valid against this attribute if it is a valid -representation according to the "full-time" ABNF rule (referenced above) + representation according to the "full-time" ABNF rule (referenced above) - *duration:* A string instance is valid against this attribute if it is a valid -representation according to the "duration" ABNF rule (referenced above) + representation according to the "duration" ABNF rule (referenced above) Implementations MAY support additional attributes using the other format names defined anywhere in that RFC. If "full-date" or "full-time" are implemented, the @@ -430,6 +461,7 @@ implementation requirements will become more flexible in general, or these will likely either be promoted to fully specified attributes or dropped. #### Email Addresses + These attributes apply to string instances. A string instance is valid against these attributes if it is a valid Internet @@ -437,48 +469,49 @@ email address as follows: - *email:* As defined by the "Mailbox" ABNF rule in [RFC 5321, section 4.1.2](#rfc5321). - *idn-email:* As defined by the extended "Mailbox" ABNF rule in [RFC 6531, -section 3.3](#rfc6531). Note that all strings valid against the "email" -attribute are also valid against the "idn-email" attribute. + section 3.3](#rfc6531). Note that all strings valid against the "email" + attribute are also valid against the "idn-email" attribute. #### Hostnames + These attributes apply to string instances. A string instance is valid against these attributes if it is a valid representation for an Internet hostname as follows: - *hostname:* As defined by [RFC 1123, section 2.1](#rfc1123), including host -names produced using the Punycode algorithm specified in [RFC 5891, section -4.4](#rfc5891). + names produced using the Punycode algorithm specified in [RFC 5891, section + 4.4](#rfc5891). - *idn-hostname:* As defined by either RFC 1123 as for hostname, or an -internationalized hostname as defined by [RFC 5890, section 2.3.2.3](#rfc5890). -Note that all strings valid against the "hostname" attribute are also valid -against the "idn-hostname" attribute. + internationalized hostname as defined by [RFC 5890, section + 2.3.2.3](#rfc5890). Note that all strings valid against the "hostname" + attribute are also valid against the "idn-hostname" attribute. #### IP Addresses + These attributes apply to string instances. A string instance is valid against these attributes if it is a valid representation of an IP address as follows: - *ipv4:* An IPv4 address according to the "dotted-quad" ABNF syntax as defined -in [RFC 2673, section 3.2](#rfc2673). + in [RFC 2673, section 3.2](#rfc2673). - *ipv6:* An IPv6 address as defined in [RFC 4291, section 2.2](#rfc4291). -#### Resource Identifiers -These attributes apply to string instances. +#### Resource Identifiers These attributes apply to string instances. - *uri:* A string instance is valid against this attribute if it is a valid IRI, -according to [Appendix RFC3987](#rfc3987). + according to [RFC3987](#rfc3987). - *uri-reference:* A string instance is valid against this attribute if it is a -valid URI Reference (either a URI or a relative-reference), according to -[Appendix RFC3986](#rfc3986). + valid URI Reference (either a URI or a relative-reference), according to + [RFC3986](#rfc3986). - *iri:* A string instance is valid against this attribute if it is a valid IRI, -according to [Appendix RFC3987](#rfc3987). + according to [RFC3987](#rfc3987). - *iri-reference:* A string instance is valid against this attribute if it is a -valid IRI Reference (either an IRI or a relative-reference), according to -[Appendix RFC3987](#rfc3987). + valid IRI Reference (either an IRI or a relative-reference), according to + [RFC3987](#rfc3987). - *uuid:* A string instance is valid against this attribute if it is a valid -string representation of a UUID, according to [Appendix RFC4122](#rfc4122). + string representation of a UUID, according to [RFC4122](#rfc4122). Note that all valid URIs are valid IRIs, and all valid URI References are also valid IRI References. @@ -489,38 +522,42 @@ example is "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". For UUIDs as URNs, use the the URI scheme and URN namespace. #### uri-template + This attribute applies to string instances. A string instance is valid against this attribute if it is a valid URI Template -(of any level), according to [Appendix RFC6570](#rfc6570). +(of any level), according to [RFC6570](#rfc6570). Note that URI Templates may be used for IRIs; there is no separate IRI Template specification. #### JSON Pointers + These attributes apply to string instances. - *json-pointer:* A string instance is valid against this attribute if it is a -valid JSON string representation of a JSON Pointer, according to [RFC 6901, -section 5](#rfc6901). + valid JSON string representation of a JSON Pointer, according to [RFC 6901, + section 5](#rfc6901). - *relative-json-pointer:* A string instance is valid against this attribute if -it is a valid [Relative JSON Pointer](#relative-json-pointer). To allow for both -absolute and relative JSON Pointers, use `anyOf` or `oneOf` to indicate support -for either format. + it is a valid [Relative JSON Pointer](#relative-json-pointer). To allow for + both absolute and relative JSON Pointers, use `anyOf` or `oneOf` to indicate + support for either format. #### regex + This attribute applies to string instances. A regular expression, which SHOULD be valid according to the [ECMA-262](#ecma262) regular expression dialect. Implementations that validate formats MUST accept at least the subset of -ECMA-262 defined in the [Regular Expressions](#43-regular-expressions) section -of this specification, and SHOULD accept all valid ECMA-262 expressions. +ECMA-262 defined in {{regexinterop}}), and SHOULD accept all valid ECMA-262 +expressions. -## A Vocabulary for the Contents of String-Encoded Data {#content-vocabulary} +## A Vocabulary for the Contents of String-Encoded Data {#content} ### Foreword + Annotations defined in this section indicate that an instance contains non-JSON data encoded in a JSON string. @@ -540,6 +577,7 @@ The current IRI for the corresponding meta-schema is: `https://json-schema.org/draft/next/meta/content`. ### Implementation Requirements + Due to security and performance concerns, as well as the open-ended nature of possible content types, implementations MUST NOT automatically decode, parse, and/or validate the string contents. Applications are expected to use these @@ -549,6 +587,7 @@ All keywords in this section apply only to strings, and have no effect on other data types. ### contentEncoding + If the instance value is a string, this property defines that the string SHOULD be interpreted as encoded binary data and applications wishing to decode it SHOULD do so using the encoding named by this property. @@ -574,6 +613,7 @@ needed in order to represent the content in a UTF-8 string. The value of this property MUST be a string. ### contentMediaType + If the instance is a string, this property indicates the media type of the contents of the string. If `contentEncoding` is present, this property describes the decoded string. @@ -582,6 +622,7 @@ The value of this property MUST be a string, which MUST be a media type, as defined by [RFC 2046](#rfc2046). ### contentSchema + If the instance is a string, and if `contentMediaType` is present, this property contains a schema which describes the structure of the string. @@ -597,6 +638,7 @@ safe if the schema is an embedded resource with both `$schema` and an absolute-IRI `$id`. ### Example + Here is an example schema, illustrating the use of `contentEncoding` and `contentMediaType`: @@ -662,11 +704,11 @@ structures: first the header, and then the payload. Since the JWT media type ensures that the JWT can be represented in a JSON string, there is no need for further encoding or decoding. -## A Vocabulary for Basic Meta-Data Annotations -These general-purpose annotation keywords provide commonly used information for -documentation and user interface display purposes. They are not intended to form -a comprehensive set of features. Rather, additional vocabularies can be defined -for more complex annotation-based applications. +## A Vocabulary for Basic Meta-Data Annotations These general-purpose annotation +keywords provide commonly used information for documentation and user interface +display purposes. They are not intended to form a comprehensive set of features. +Rather, additional vocabularies can be defined for more complex annotation-based +applications. Meta-schemas that do not use `$vocabulary` SHOULD be considered to require this vocabulary as if its IRI were present with a value of true. @@ -678,6 +720,7 @@ The current IRI for the corresponding meta-schema is: `https://json-schema.org/draft/next/meta/meta-data`. ### title and description + The value of both of these keywords MUST be a string. Both of these keywords can be used to decorate a user interface with information @@ -686,6 +729,7 @@ short, whereas a description will provide explanation about the purpose of the instance described by this schema. ### default + There are no restrictions placed on the value of this keyword. When multiple occurrences of this keyword are applicable to a single sub-instance, implementations SHOULD remove duplicates. @@ -695,6 +739,7 @@ particular schema. It is RECOMMENDED that a default value be valid against the associated schema. ### deprecated + The value of this keyword MUST be a boolean. When multiple occurrences of this keyword are applicable to a single sub-instance, applications SHOULD consider the instance location to be deprecated if any occurrence specifies a true value. @@ -714,6 +759,7 @@ containing array or object is not. Omitting this keyword has the same behavior as a value of false. ### readOnly and writeOnly + The value of these keywords MUST be a boolean. When multiple occurrences of these keywords are applicable to a single sub-instance, the resulting behavior SHOULD be as for a true value if any occurrence specifies a true value, and @@ -748,6 +794,7 @@ they are typed for write-only fields. Omitting these keywords has the same behavior as values of false. ### examples + The value of this keyword MUST be an array. There are no restrictions placed on the values within the array. When multiple occurrences of this keyword are applicable to a single sub-instance, implementations MUST provide a flat array @@ -760,7 +807,8 @@ these values be valid against the associated schema. Implementations MAY use the value(s) of `default`, if present, as an additional example. If `examples` is absent, `default` MAY still be used in this manner. -## Security Considerations +## Security Considerations {#security} + JSON Schema validation defines a vocabulary for JSON Schema core and concerns all the security considerations listed there. @@ -787,102 +835,122 @@ ECMAScript encoded within a JSON string. ### Normative References -#### [RFC2119] +#### [RFC2119] {#rfc2119} + Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>. -#### [RFC1123] +#### [RFC1123] {#rfc1123} + Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <>. -#### [RFC2045] +#### [RFC2045] {#rfc2045} + Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <>. -#### [RFC2046] +#### [RFC2046] {#rfc2046} + Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <>. -#### [RFC2673] +#### [RFC2673] {#rfc2673} + Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, DOI 10.17487/RFC2673, August 1999, <>. -#### [RFC3339] +#### [RFC3339] {#rfc3339} + Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <>. -#### [RFC3986] +#### [RFC3986] {#rfc3986} + Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <>. -#### [RFC3987] +#### [RFC3987] {#rfc3987} + Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <>. -#### [RFC4122] +#### [RFC4122] {#rfc4122} + Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <>. -#### [RFC4291] +#### [RFC4291] {#rfc4291} + Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <>. -#### [RFC4648] +#### [RFC4648] {#rfc4648} + Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <>. -#### [RFC5321] +#### [RFC5321] {#rfc5321} + Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <>. -#### [RFC5890] +#### [RFC5890] {#rfc5890} + Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <>. -#### [RFC5891] +#### [RFC5891] {#rfc5891} + Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <>. -#### [RFC6570] +#### [RFC6570] {#rfc6570} + Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <>. -#### [RFC6531] +#### [RFC6531] {#rfc6531} Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, <>. -#### [RFC6901] +#### [RFC6901] {#rfc6901} + Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <>. -#### [RFC8259] +#### [RFC8259] {#rfc8259} + Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <>. -#### [ecma262] -"ECMA-262, 11th edition specification", June 2020, +#### [ecma262] {#ecma262} + +ECMA-262, 11th edition specification", June 2020, <>. -#### [relative-json-pointer] +#### [relative-json-pointer] {#relative-json-pointer} + Luff, G., Andrews, H., and B. Hutton, Ed., "Relative JSON Pointers", Work in Progress, Internet-Draft, draft-handrews-relative-json-pointer-01, December 2020, <>. -#### [json-schema] +#### [json-schema] {#json-schema} + Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON Schema: A Media Type for Describing JSON Documents", Work in Progress, Internet-Draft, draft-bhutton-json-schema-01, June 2022, @@ -890,44 +958,47 @@ draft-bhutton-json-schema-01, June 2022, ### Informative References -#### [RFC4329] +#### [RFC4329] {#rfc4329} + Hoehrmann, B., "Scripting Media Types", RFC 4329, DOI 10.17487/RFC4329, April 2006, <>. ## [Appendix] Keywords Moved from Validation to Core + Several keywords have been moved from this document into the [Core Specification](#json-schema) starting with draft 2019-09, in some cases with re-naming or other changes. This affects the following former validation keywords: - *`definitions`* Renamed to `$defs` to match `$ref` and be shorter to type. -Schema vocabulary authors SHOULD NOT define a `definitions` keyword with -different behavior in order to avoid invalidating schemas that still use the -older name. While `definitions` is absent in the single-vocabulary meta-schemas -referenced by this document, it remains present in the default meta-schema, and -implementations SHOULD assume that `$defs` and `definitions` have the same -behavior when that meta-schema is used. + Schema vocabulary authors SHOULD NOT define a `definitions` keyword with + different behavior in order to avoid invalidating schemas that still use the + older name. While `definitions` is absent in the single-vocabulary + meta-schemas referenced by this document, it remains present in the default + meta-schema, and implementations SHOULD assume that `$defs` and `definitions` + have the same behavior when that meta-schema is used. - *`allOf`, `anyOf`, `oneOf`, `not`, `if`, `then`, `else`, `items`, -`additionalItems`, `contains`, `propertyNames`, `properties`, -`patternProperties`, `additionalProperties`* All of these keywords apply -subschemas to the instance and combine their results, without asserting any -conditions of their own. Without assertion keywords, these applicators can only -cause assertion failures by using the false boolean schema, or by inverting the -result of the true boolean schema (or equivalent schema objects). For this -reason, they are better defined as a generic mechanism on which validation, -hyper-schema, and extension vocabularies can all be based. + `additionalItems`, `contains`, `propertyNames`, `properties`, + `patternProperties`, `additionalProperties`* All of these keywords apply + subschemas to the instance and combine their results, without asserting any + conditions of their own. Without assertion keywords, these applicators can + only cause assertion failures by using the false boolean schema, or by + inverting the result of the true boolean schema (or equivalent schema + objects). For this reason, they are better defined as a generic mechanism on + which validation, hyper-schema, and extension vocabularies can all be based. - *`maxContains`, `minContains`* These keywords modify the behavior of -`contains`, and are therefore grouped with it in the applicator vocabulary. + `contains`, and are therefore grouped with it in the applicator vocabulary. - *`dependencies`* This keyword had two different modes of behavior, which made -it relatively challenging to implement and reason about. The schema form has -been moved to Core and renamed to `dependentSchemas`, as part of the applicator -vocabulary. It is analogous to `properties`, except that instead of applying its -subschema to the property value, it applies it to the object containing the -property. The property name array form is retained here and renamed to -`dependentRequired`, as it is an assertion which is a shortcut for the -conditional use of the `required` assertion keyword. + it relatively challenging to implement and reason about. The schema form has + been moved to Core and renamed to `dependentSchemas`, as part of the + applicator vocabulary. It is analogous to `properties`, except that instead of + applying its subschema to the property value, it applies it to the object + containing the property. The property name array form is retained here and + renamed to `dependentRequired`, as it is an assertion which is a shortcut for + the conditional use of the `required` assertion keyword. ## [Appendix] Acknowledgments + Thanks to Gary Court, Francis Galiegue, Kris Zyp, Geraint Luff, and Henry Andrews for their work on the initial drafts of JSON Schema. @@ -955,7 +1026,7 @@ to the document. - Grouped keywords into formal vocabularies - Update `format` implementation requirements in terms of vocabularies - By default, `format` MUST NOT be validated, although validation can be - enabled + enabled - A vocabulary declaration can be used to require `format` validation - Moved `definitions` to the core spec as `$defs` - Moved applicator keywords to the core spec diff --git a/package.json b/package.json index 36b667b9..fded7279 100644 --- a/package.json +++ b/package.json @@ -12,9 +12,9 @@ }, "license": "MIT", "dependencies": { - "@vcarl/remark-headings": "^0.1.0", - "rehype-autolink-headings": "^6.1.1", - "rehype-slug": "^5.1.0", + "mdast-builder": "^1.1.1", + "mdast-util-find-and-replace": "^3.0.0", + "mdast-util-to-string": "^4.0.0", "rehype-stringify": "^9.0.3", "remark": "^14.0.3", "remark-flexible-containers": "^1.0.6", @@ -22,9 +22,9 @@ "remark-heading-id": "^1.0.0", "remark-preset-lint-markdown-style-guide": "^5.1.3", "remark-rehype": "^10.1.0", - "remark-toc": "^8.0.1", "remark-torchlight": "^0.0.5", "remark-validate-links": "^12.1.1", + "unist-builder": "^4.0.0", "vfile-reporter": "^8.0.0" }, "devDependencies": { From 9486b51b1cb7bf8ec9f123a6732993e9f357d519 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Tue, 1 Aug 2023 17:51:51 -0700 Subject: [PATCH 494/780] Fix some markdown bugs and style issues --- jsonschema-core.md | 115 ++++++++++++++++++--------------------- jsonschema-validation.md | 82 +++++++++++++++------------- 2 files changed, 97 insertions(+), 100 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index 58898e59..23eda176 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -122,19 +122,14 @@ interpreted according to this data model is called an "instance". An instance has one of six primitive types, and a range of possible values depending on the type: -null: A JSON "null" value - -boolean: A "true" or "false" value, from the JSON "true" or "false" value - -object: An unordered set of properties mapping a string to an instance, from the -JSON "object" value - -array: An ordered list of instances, from the JSON "array" value - -number: An arbitrary-precision, base-10 decimal number value, from the JSON -"number" value - -string: A string of Unicode code points, from the JSON "string" value +- *null*: A JSON "null" value +- boolean: A "true" or "false" value, from the JSON "true" or "false" value +- *object*: An unordered set of properties mapping a string to an instance, from + the JSON "object" value +- *array*: An ordered list of instances, from the JSON "array" value +- *number*: An arbitrary-precision, base-10 decimal number value, from the JSON + "number" value +- *string*: A string of Unicode code points, from the JSON "string" value Whitespace and formatting concerns, including different lexical representations of numbers that are equal within the data model, are thus outside the scope of @@ -201,18 +196,14 @@ A JSON Schema MUST be an object or a boolean. Object properties that are applied to the instance are called keywords, or schema keywords. Broadly speaking, keywords fall into one of five categories: -identifiers: control schema identification through setting a IRI for the schema -and/or changing how the base IRI is determined - -assertions: produce a boolean result when applied to an instance - -annotations: attach information to an instance for application use - -applicators: apply one or more subschemas to a particular location in the -instance, and combine or modify their results - -reserved locations: do not directly affect results, but reserve a place for a -specific purpose to ensure interoperability +- *identifiers*: control schema identification through setting a IRI for the + schema and/or changing how the base IRI is determined +- *assertions*: produce a boolean result when applied to an instance +- *annotations*: attach information to an instance for application use +- *applicators*: apply one or more subschemas to a particular location in the + instance, and combine or modify their results +- *reserved locations*: do not directly affect results, but reserve a place for + a specific purpose to ensure interoperability Keywords may fall into multiple categories, although applicators SHOULD only produce assertion results based on their subschemas' results. They should not @@ -241,9 +232,8 @@ schema processing optimizations. They behave identically to the following schema objects (where `not` is part of the subschema application vocabulary defined in this document). -`true`: Always passes validation, as if the empty schema `{}` - -`false`: Always fails validation, as if the schema `{ "not": {} }` +- `true`: Always passes validation, as if the empty schema `{}` +- `false`: Always fails validation, as if the schema `{ "not": {} }` While the empty schema object is unambiguous, there are many possible equivalents to the `false` schema. Using the boolean values ensures that the @@ -890,7 +880,7 @@ vocabulary's keywords. Meta-schema authoring is an advanced usage of JSON Schema, so the design of meta-schema features emphasizes flexibility over simplicity. -#### The $schema Keyword {#keyword-schema} +#### The `$schema` Keyword {#keyword-schema} The `$schema` keyword is both used as a JSON Schema dialect identifier and as the identifier of a resource which is itself a JSON Schema, which describes the @@ -917,7 +907,7 @@ the following options: Values for this property are defined elsewhere in this and other documents, and by other parties. -#### The $vocabulary Keyword +#### The `$vocabulary` Keyword The `$vocabulary` keyword is used in meta-schemas to identify the vocabularies available for use in schemas described by that meta-schema, and whether each @@ -1048,7 +1038,7 @@ Several keywords can accept a relative [IRI-reference](#rfc3987), or a value used to construct a relative IRI-reference. For these keywords, it is necessary to establish a base IRI in order to resolve the reference. -#### The $id Keyword {#id-keyword} +#### The `$id` Keyword {#id-keyword} The `$id` keyword identifies a schema resource with its [canonical](#rfc6596) IRI. @@ -1128,10 +1118,11 @@ as the same IRI through the use of `$id`, `$anchor`, `$dynamicAnchor`, or any other mechanism, implementations SHOULD raise an error condition. Otherwise the result is undefined, and even if documented will not be interoperable. -#### Schema References {#references} Several keywords can be used to reference a -schema which is to be applied to the current instance location. `$ref` and -`$dynamicRef` are applicator keywords, applying the referenced schema to the -instance. +#### Schema References {#references} + +Several keywords can be used to reference a schema which is to be applied to the +current instance location. `$ref` and `$dynamicRef` are applicator keywords, +applying the referenced schema to the instance. As the values of `$ref` and `$dynamicRef` are IRI References, this allows the possibility to externalise or divide a schema across multiple files, and @@ -1143,7 +1134,7 @@ if it is a network-addressable URL, and implementations SHOULD NOT assume they should perform a network operation when they encounter a network-addressable IRI. -##### Direct References with $ref {#ref} +##### Direct References with `$ref` {#ref} The `$ref` keyword is an applicator that is used to reference a statically identified schema. Its results are the results of the referenced schema.[^5] @@ -1156,7 +1147,7 @@ Resolved against the current IRI base, it produces the IRI of the schema to apply. This resolution is safe to perform on schema load, as the process of evaluating an instance cannot change how the reference resolves. -##### Dynamic References with $dynamicRef {#dynamic-ref} +##### Dynamic References with `$dynamicRef` {#dynamic-ref} The `$dynamicRef` keyword is an applicator that allows for deferring the full resolution until runtime, at which point it is resolved each time it is @@ -1182,7 +1173,7 @@ For a full example using these keyword, see {{recursive-example}}.[^6] [^6]: The difference between the hyper-schema meta-schema in pre-2019 drafts and an this draft dramatically demonstrates the utility of these keywords. -#### Schema Re-Use With $defs {#defs} +#### Schema Re-Use With `$defs` {#defs} The `$defs` keyword reserves a location for schema authors to inline re-usable JSON Schemas into a more general schema. The keyword does not directly affect @@ -1207,7 +1198,7 @@ the positive integer constraint is a subschema in `$defs`: } ``` -### Comments With $comment +### Comments With `$comment` This keyword reserves a location for comments from schema authors to readers or maintainers of the schema. @@ -1650,7 +1641,7 @@ annotation collection, although they enable the same annotation keyword to be applied to an instance location with different values. Annotation keywords define their own rules for combining such values. -##### allOf {#allof} +##### `allOf` {#allof} This keyword's value MUST be a non-empty array. Each item of the array MUST be a valid JSON Schema. @@ -1658,7 +1649,7 @@ valid JSON Schema. An instance validates successfully against this keyword if it validates successfully against all schemas defined by this keyword's value. -##### anyOf +##### `anyOf` This keyword's value MUST be a non-empty array. Each item of the array MUST be a valid JSON Schema. @@ -1668,7 +1659,7 @@ successfully against at least one schema defined by this keyword's value. Note that when annotations are being collected, all subschemas MUST be examined so that annotations are collected from each subschema that validates successfully. -##### oneOf +##### `oneOf` This keyword's value MUST be a non-empty array. Each item of the array MUST be a valid JSON Schema. @@ -1676,7 +1667,7 @@ valid JSON Schema. An instance validates successfully against this keyword if it validates successfully against exactly one schema defined by this keyword's value. -##### not {#not} +##### `not` {#not} This keyword's value MUST be a valid JSON Schema. @@ -1698,7 +1689,7 @@ present. In particular, they MUST NOT be treated as if present with an empty schema, and when `if` is not present, both `then` and `else` MUST be entirely ignored. -##### if +##### `if` This keyword's value MUST be a valid JSON Schema. @@ -1716,7 +1707,7 @@ If [annotations](#annotations) are being collected, they are collected from this keyword's subschema in the usual way, including when the keyword is present without either `then` or `else`. -##### then +##### `then` This keyword's value MUST be a valid JSON Schema. @@ -1729,7 +1720,7 @@ validate against its subschema. Implementations MUST NOT evaluate the instance against this keyword, for either validation or annotation collection purposes, in such cases. -##### else +##### `else` This keyword's value MUST be a valid JSON Schema. @@ -1742,7 +1733,7 @@ successfully validates against its subschema. Implementations MUST NOT evaluate the instance against this keyword, for either validation or annotation collection purposes, in such cases. -##### dependentSchemas +##### `dependentSchemas` This keyword specifies subschemas that are evaluated if the instance is an object and contains a certain property. @@ -1756,7 +1747,7 @@ property. Omitting this keyword has the same behavior as an empty object. -##### propertyDependencies +##### `propertyDependencies` This keyword specifies subschemas that are evaluated if the instance is an object and contains a certain property with a certain string value. @@ -1779,7 +1770,7 @@ results. #### Keywords for Applying Subschemas to Arrays -##### prefixItems +##### `prefixItems` The value of "prefixItems` MUST be a non-empty array of valid JSON Schemas. @@ -1795,7 +1786,7 @@ keyword. This annotation affects the behavior of `items` and `unevaluatedItems`. Omitting this keyword has the same assertion behavior as an empty array. -##### items {#items} +##### `items` {#items} The value of `items` MUST be a valid JSON Schema. @@ -1825,7 +1816,7 @@ collection MUST do so. #### Keywords for Applying Subschemas to Objects -##### properties +##### `properties` The value of `properties` MUST be an object. Each value of this object MUST be a valid JSON Schema. @@ -1841,7 +1832,7 @@ the Unevaluated vocabulary. Omitting this keyword has the same assertion behavior as an empty object. -##### patternProperties +##### `patternProperties` The value of `patternProperties` MUST be an object. Each property name of this object SHOULD be a valid regular expression, according to the ECMA-262 regular @@ -1861,7 +1852,7 @@ behavior of `additionalProperties` (in this vocabulary) and Omitting this keyword has the same assertion behavior as an empty object. -##### additionalProperties {#additionalproperties} +##### `additionalProperties` {#additionalproperties} The value of `additionalProperties` MUST be a valid JSON Schema. @@ -1895,7 +1886,7 @@ failing schemas are dropped. See our [Decision Record](https://github.com/json-schema-org/json-schema-spec/tree/HEAD/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md) for further details. -##### propertyNames +##### `propertyNames` The value of `propertyNames` MUST be a valid JSON Schema. @@ -1907,7 +1898,7 @@ Omitting this keyword has the same behavior as an empty schema. #### Other Keywords for Applying Subschemas -##### maxContains +##### `maxContains` The value of this keyword MUST be a non-negative integer. @@ -1917,7 +1908,7 @@ as described below in the section for that keyword. Validation MUST always succeed against this keyword. The value of this keyword is used as its annotation result. -##### minContains +##### `minContains` The value of this keyword MUST be a non-negative integer. @@ -1931,7 +1922,7 @@ Per {{default-behaviors}}, omitted keywords MUST NOT produce annotation results. However, as described in the section for `contains`, the absence of this keyword's annotation causes `contains` to assume a minimum value of 1. -##### contains +##### `contains` The value of this keyword MUST be a valid JSON Schema. @@ -2015,7 +2006,7 @@ outcomes. However, the keywords in this vocabulary are notable exceptions: from `properties`, `patternProperties`, `additionalProperties`, `contains`, and itself -### unevaluatedItems {#unevaluateditems} +### `unevaluatedItems` {#unevaluateditems} The value of `unevaluatedItems` MUST be a valid JSON Schema. @@ -2046,7 +2037,7 @@ the behavior of `items`. This annotation affects the behavior of Omitting this keyword has the same assertion behavior as an empty schema. -### unevaluatedProperties {#unevaluatedproperties} +### `unevaluatedProperties` {#unevaluatedproperties} The value of `unevaluatedProperties` MUST be a valid JSON Schema. @@ -2238,7 +2229,7 @@ if they contain the same units, in any order. The JSON key for these additional results is "details". -### 12.4. Output Structure +### Output Structure The output MUST be an object containing a boolean property named "valid". When additional information about the result is required, the output MUST also @@ -2728,7 +2719,7 @@ action based on `$comment` contents. ## IANA Considerations -### application/schema+json +### `application/schema+json` The proposed MIME media type for JSON Schema is defined as follows: @@ -2748,7 +2739,7 @@ Interoperability considerations:: See Sections [6.2](#language), Fragment identifier considerations:: See {{fragments}} -### application/schema-instance+json +### `application/schema-instance+json` The proposed MIME media type for JSON Schema Instances that require a JSON Schema-specific media type is defined as follows: diff --git a/jsonschema-validation.md b/jsonschema-validation.md index 3d5ed61f..840f73e3 100644 --- a/jsonschema-validation.md +++ b/jsonschema-validation.md @@ -115,7 +115,7 @@ The current IRI for the corresponding meta-schema is: ### Validation Keywords for Any Instance Type {#general} -#### type +#### `type` The value of this keyword MUST be either a string or an array. If it is an array, elements of the array MUST be strings and MUST be unique. @@ -125,11 +125,12 @@ String values MUST be one of the six primitive types ("null", "boolean", with a zero fractional part. If the value of "type" is a string, then an instance validates successfully if -its type matches the type represented by the value of the string. If the value -of "type" is an array, then an instance validates successfully if its type -matches any of the types indicated by the strings in the array. +its type matches the type represented by the value of the string. -#### enum {#enum} +If the value of "type" is an array, then an instance validates successfully if +its type matches any of the types indicated by the strings in the array. + +#### `enum` {#enum} The value of this keyword MUST be an array. This array SHOULD have at least one element. Elements in the array SHOULD be unique. @@ -139,7 +140,7 @@ one of the elements in this keyword's array value. Elements in the array might be of any type, including null. -#### const +#### `const` The value of this keyword MAY be of any type, including null. @@ -151,14 +152,14 @@ the value of the keyword. ### Validation Keywords for Numeric Instances (number and integer) {#numeric} -#### multipleOf +#### `multipleOf` The value of `multipleOf` MUST be a number, strictly greater than 0. A numeric instance is valid only if division by this keyword's value results in an integer. -#### maximum +#### `maximum` The value of `maximum` MUST be a number, representing an inclusive upper limit for a numeric instance. @@ -166,7 +167,7 @@ for a numeric instance. If the instance is a number, then this keyword validates only if the instance is less than or exactly equal to `maximum`. -#### exclusiveMaximum +#### `exclusiveMaximum` The value of `exclusiveMaximum` MUST be a number, representing an exclusive upper limit for a numeric instance. @@ -174,7 +175,7 @@ upper limit for a numeric instance. If the instance is a number, then the instance is valid only if it has a value strictly less than (not equal to) `exclusiveMaximum`. -#### minimum +#### `minimum` The value of `minimum` MUST be a number, representing an inclusive lower limit for a numeric instance. @@ -182,7 +183,7 @@ for a numeric instance. If the instance is a number, then this keyword validates only if the instance is greater than or exactly equal to `minimum`. -#### exclusiveMinimum +#### `exclusiveMinimum` The value of `exclusiveMinimum` MUST be a number, representing an exclusive lower limit for a numeric instance. @@ -192,7 +193,7 @@ strictly greater than (not equal to) `exclusiveMinimum`. ### Validation Keywords for Strings {#string} -#### maxLength +#### `maxLength` The value of this keyword MUST be a non-negative integer. @@ -202,7 +203,7 @@ equal to, the value of this keyword. The length of a string instance is defined as the number of its characters as defined by [RFC 8259](#rfc8259). -#### minLength +#### `minLength` The value of this keyword MUST be a non-negative integer. @@ -214,7 +215,7 @@ defined by [RFC 8259](#rfc8259). Omitting this keyword has the same behavior as a value of 0. -#### pattern {#pattern} +#### `pattern` {#pattern} The value of this keyword MUST be a string. This string SHOULD be a valid regular expression, according to the ECMA-262 regular expression dialect. @@ -224,14 +225,14 @@ instance successfully. Recall: regular expressions are not implicitly anchored. ### Validation Keywords for Arrays -#### maxItems +#### `maxItems` The value of this keyword MUST be a non-negative integer. An array instance is valid against `maxItems` if its size is less than, or equal to, the value of this keyword. -#### minItems +#### `minItems` The value of this keyword MUST be a non-negative integer. @@ -240,7 +241,7 @@ equal to, the value of this keyword. Omitting this keyword has the same behavior as a value of 0. -#### uniqueItems +#### `uniqueItems` The value of this keyword MUST be a boolean. @@ -252,14 +253,14 @@ Omitting this keyword has the same behavior as a value of false. ### Validation Keywords for Objects -#### maxProperties +#### `maxProperties` The value of this keyword MUST be a non-negative integer. An object instance is valid against `maxProperties` if its number of properties is less than, or equal to, the value of this keyword. -#### minProperties +#### `minProperties` The value of this keyword MUST be a non-negative integer. @@ -268,7 +269,7 @@ is greater than, or equal to, the value of this keyword. Omitting this keyword has the same behavior as a value of 0. -#### required +#### `required` The value of this keyword MUST be an array. Elements of this array, if any, MUST be strings, and MUST be unique. @@ -278,7 +279,7 @@ the name of a property in the instance. Omitting this keyword has the same behavior as an empty array. -#### dependentRequired +#### `dependentRequired` The value of this keyword MUST be an object. Properties in this object, if any, MUST be arrays. Elements in each array, if any, MUST be strings, and MUST be @@ -294,7 +295,7 @@ the name of a property in the instance. Omitting this keyword has the same behavior as an empty object. -## Vocabularies for Semantic Content With format {#format} +## Vocabularies for Semantic Content With `format` {#format} ### Foreword @@ -341,10 +342,11 @@ its requirements are a superset of the Format-Annotation vocabulary. The `format` keyword functions as defined by the vocabulary which is referenced. -#### Format-Annotation Vocabulary The value of format MUST be collected as an -annotation, if the implementation supports annotation collection. This enables -application-level validation when schema validation is unavailable or -inadequate. +#### Format-Annotation Vocabulary + +The value of format MUST be collected as an annotation, if the implementation +supports annotation collection. This enables application-level validation when +schema validation is unavailable or inadequate. Implementations MAY still treat `format` as an assertion in addition to an annotation and attempt to validate the value's conformance to the specified @@ -378,13 +380,16 @@ defined by this specificaion. Implementations that cannot provide full validation support MUST refuse to process the schema. An implementation that supports the Format-Assertion vocabulary: + - MUST still collect `format` as an annotation if the implementation supports annotation collection; - MUST evaluate `format` as an assertion; - MUST implement syntactic validation for all format attributes defined in this specification, and for any additional format attributes that it recognizes, -such that there exist possible instance values of the correct type that will -fail validation. The requirement for minimal validation of format attributes is + such that there exist possible instance values of the correct type that will + fail validation. + +The requirement for minimal validation of format attributes is intentionally vague and permissive, due to the complexity involved in many of the attributes. Note in particular that the requirement is limited to syntactic checking; it is not to be expected that an implementation would send an email, @@ -465,9 +470,10 @@ likely either be promoted to fully specified attributes or dropped. These attributes apply to string instances. A string instance is valid against these attributes if it is a valid Internet -email address as follows: - *email:* As defined by the "Mailbox" ABNF rule in -[RFC 5321, section 4.1.2](#rfc5321). +email address as follows: +- *email:* As defined by the "Mailbox" ABNF rule in [RFC 5321, section + 4.1.2](#rfc5321). - *idn-email:* As defined by the extended "Mailbox" ABNF rule in [RFC 6531, section 3.3](#rfc6531). Note that all strings valid against the "email" attribute are also valid against the "idn-email" attribute. @@ -586,7 +592,7 @@ annotations to invoke the appropriate libraries separately. All keywords in this section apply only to strings, and have no effect on other data types. -### contentEncoding +### `contentEncoding` If the instance value is a string, this property defines that the string SHOULD be interpreted as encoded binary data and applications wishing to decode it @@ -612,7 +618,7 @@ needed in order to represent the content in a UTF-8 string. The value of this property MUST be a string. -### contentMediaType +### `contentMediaType` If the instance is a string, this property indicates the media type of the contents of the string. If `contentEncoding` is present, this property describes @@ -621,7 +627,7 @@ the decoded string. The value of this property MUST be a string, which MUST be a media type, as defined by [RFC 2046](#rfc2046). -### contentSchema +### `contentSchema` If the instance is a string, and if `contentMediaType` is present, this property contains a schema which describes the structure of the string. @@ -719,7 +725,7 @@ The current IRI for this vocabulary, known as the Meta-Data vocabulary, is: The current IRI for the corresponding meta-schema is: `https://json-schema.org/draft/next/meta/meta-data`. -### title and description +### `title` and `description` The value of both of these keywords MUST be a string. @@ -728,7 +734,7 @@ about the data produced by this user interface. A title will preferably be short, whereas a description will provide explanation about the purpose of the instance described by this schema. -### default +### `default` There are no restrictions placed on the value of this keyword. When multiple occurrences of this keyword are applicable to a single sub-instance, @@ -738,7 +744,7 @@ This keyword can be used to supply a default JSON value associated with a particular schema. It is RECOMMENDED that a default value be valid against the associated schema. -### deprecated +### `deprecated` The value of this keyword MUST be a boolean. When multiple occurrences of this keyword are applicable to a single sub-instance, applications SHOULD consider @@ -758,7 +764,7 @@ containing array or object is not. Omitting this keyword has the same behavior as a value of false. -### readOnly and writeOnly +### `readOnly` and `writeOnly` The value of these keywords MUST be a boolean. When multiple occurrences of these keywords are applicable to a single sub-instance, the resulting behavior @@ -793,7 +799,7 @@ they are typed for write-only fields. Omitting these keywords has the same behavior as values of false. -### examples +### `examples` The value of this keyword MUST be an array. There are no restrictions placed on the values within the array. When multiple occurrences of this keyword are From 63c32f4b697556da559636c10cf77b909c4bb0cd Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Wed, 2 Aug 2023 17:46:27 -0700 Subject: [PATCH 495/780] Fix bugs --- jsonschema-core.md | 7 +++---- jsonschema-validation.md | 4 ++-- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index 23eda176..d3ad7d56 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -2089,10 +2089,9 @@ other means. This specification defines three output formats. See the "Output Structure" section for the requirements of each format. -Flag: A boolean which simply indicates the overall validation result with no -further details. - -List: Provides validation information in a flat list structure. +- *Flag*: A boolean which simply indicates the overall validation result with no + further details. +- *List*: Provides validation information in a flat list structure. Hierarchical: Provides validation information in a hierarchical structure that follows the evaluation paths generated while processing the schema. diff --git a/jsonschema-validation.md b/jsonschema-validation.md index 840f73e3..2804b26b 100644 --- a/jsonschema-validation.md +++ b/jsonschema-validation.md @@ -124,10 +124,10 @@ String values MUST be one of the six primitive types ("null", "boolean", "object", "array", "number", or "string"), or "integer" which matches any number with a zero fractional part. -If the value of "type" is a string, then an instance validates successfully if +If the value of `type` is a string, then an instance validates successfully if its type matches the type represented by the value of the string. -If the value of "type" is an array, then an instance validates successfully if +If the value of `type` is an array, then an instance validates successfully if its type matches any of the types indicated by the strings in the array. #### `enum` {#enum} From 8c02c04f147158517cfe5a2a03e97c46fdd7e0b2 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Wed, 2 Aug 2023 22:09:49 -0700 Subject: [PATCH 496/780] Add code-titles plugin --- README.md | 14 +++++++- build/build.js | 43 ++++++++++++++++++++---- build/remark-code-titles.js | 65 +++++++++++++++++++++++++++++++++++++ jsonschema-core.md | 59 ++++++++++++++------------------- jsonschema-validation.md | 6 ++-- 5 files changed, 143 insertions(+), 44 deletions(-) create mode 100644 build/remark-code-titles.js diff --git a/README.md b/README.md index 00646e62..44e55482 100644 --- a/README.md +++ b/README.md @@ -69,11 +69,23 @@ features they make available to you. - [remark-table-of-contents](/json-schema-org/json-schema-spec/blob/main/remark-table-of-contents.js) -- Adds a table of contents in a section with a header called "Table of Contents". +- [remark-code-titles](/json-schema-org/json-schema-spec/blob/main/remark-code-titles.js) + -- Add titles to code blocks + - Example: + ```markdown + \`\`\`jsonschema "My Fun Title" + { "type": "string" } + \`\`\` + ``` + - The languages `jsonschema` and `json` have special styling + - The title will be parsed as a JSON string, but you have to double escape + escaped characters. So, to get `My "quoted" title`, you would need to be + `"My \\\\"quoted\\\\" title"`. - [remark-torchlight](https://github.com/torchlight-api/remark-torchlight) -- Syntax highlighting and more using https://torchlight.dev. Features include line numbers and line highlighting. - [remark-flexible-containers](https://github.com/ipikuka/remark-flexible-containers) - - Add a callout box using the following syntax. Supported container types are + -- Add a callout box using the following syntax. Supported container types are `warning`, `note`, and `experimental`. ``` diff --git a/build/build.js b/build/build.js index 6fce20ab..e8b3f0ef 100644 --- a/build/build.js +++ b/build/build.js @@ -2,6 +2,7 @@ import dotenv from "dotenv"; import { readFileSync, writeFileSync } from "node:fs"; import { reporter } from "vfile-reporter"; import { remark } from "remark"; +import remarkCodeTitles from "./remark-code-titles.js"; import remarkFlexibleContainers from "remark-flexible-containers"; import remarkGfm from "remark-gfm"; import remarkHeadingId from "remark-heading-id"; @@ -29,6 +30,7 @@ dotenv.config(); }) .use(remarkReferenceLinks) .use(remarkFlexibleContainers) + .use(remarkCodeTitles) .use(remarkTorchLight) .use(remarkTableOfContents, { startDepth: 2, @@ -43,7 +45,6 @@ dotenv.config(); - - ${html.toString()} + ${file.toString()} `); - console.error(reporter(html)); + console.error(reporter(file)); + + return file.messages.length; }; (async function () { @@ -177,9 +179,14 @@ const build = async (filename) => { console.error("WARNING: No files built. Usage: 'npm run build -- filename.md'"); } + let messageCount = 0; for (const filename of files) { console.log(`Building: ${filename} ...`); - await build(filename); + messageCount += await build(filename); console.log(""); } + + if (messageCount > 0) { + process.exit(1); + } }()); From 999f73b1fd97b7d8cf50efd11f9145a64f97fec0 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Wed, 16 Oct 2024 14:59:00 -0700 Subject: [PATCH 649/780] Fix spec markdown lint errors --- build/build.js | 2 + jsonschema-core.md | 52 ++++++++++++------- jsonschema-validation.md | 32 +++++++----- .../jsonschema-validation-output-machines.md | 8 ++- proposals/propertyDependencies-adr.md | 45 +++++++++------- proposals/propertyDependencies.md | 32 +++++++----- proposals/proposal-template.md | 4 +- proposals/vocabularies-adr.md | 49 +++++++++-------- proposals/vocabularies.md | 20 ++++--- 9 files changed, 146 insertions(+), 98 deletions(-) diff --git a/build/build.js b/build/build.js index 99c6facd..25533986 100644 --- a/build/build.js +++ b/build/build.js @@ -11,6 +11,7 @@ import remarkGfm from "remark-gfm"; import remarkHeadingId from "remark-heading-id"; import remarkHeadings from "./remark-headings.js"; import remarkPresetLintMarkdownStyleGuide from "remark-preset-lint-markdown-style-guide"; +import remarkLintMaximumHeadingLength from "remark-lint-maximum-heading-length"; import remarkRehype from "remark-rehype"; import remarkReferenceLinks from "./remark-reference-links.js"; import remarkTableOfContents from "./remark-table-of-contents.js"; @@ -25,6 +26,7 @@ const build = async (filename) => { const md = readFileSync(filename, "utf-8"); const file = await remark() .use(remarkPresetLintMarkdownStyleGuide) + .use(remarkLintMaximumHeadingLength, false) .use(remarkGfm) .use(remarkHeadingId) .use(remarkHeadings, { diff --git a/jsonschema-core.md b/jsonschema-core.md index d3c7963b..7ea5cc15 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -2051,7 +2051,7 @@ specified for the `application/json` media type. See [JSON](#rfc8259). Security considerations:: See {{security}} above. Interoperability considerations:: See Sections [6.2](#language), -[6.3](#integers), and [6.4](#regex) above. +[6.3](#data-model), and [6.4](#regex) above. Fragment identifier considerations:: See {{fragments}} @@ -2072,7 +2072,7 @@ specified for the `application/json` media type. See [JSON](#rfc8259). Security considerations:: See {{security}} above. Interoperability considerations:: See Sections [6.2](#language), -[6.3](#integers), and [6.4](#regex) above. +[6.3](#data-model), and [6.4](#regex) above. Fragment identifier considerations:: See {{fragments}} @@ -2467,32 +2467,48 @@ to the document. ### draft-bhutton-json-schema-next - Use IRIs instead of URIs, including allowing unicode in plain-name fragments -- Clarify that detecting duplicate IRIs for different schemas SHOULD raise an error +- Clarify that detecting duplicate IRIs for different schemas SHOULD raise an + error - Consolidate and clarify the syntax and rationale for plain-name fragments - "$id" MUST be an absolute-IRI, without any fragment, even an empty one -- Note that an empty string "$id" results in duplicate IRIs for different schemas +- Note that an empty string "$id" results in duplicate IRIs for different + schemas - Define empty schemas as empty (no longer allowing unrecognized keywords) -- Clarify that if unknown properties are not treated as annotations, they MUST be ignored -- Remove outdated pre-annotation-collection section on annotation-applicator interaction +- Clarify that if unknown properties are not treated as annotations, they MUST + be ignored +- Remove outdated pre-annotation-collection section on annotation-applicator + interaction - Clarify that regular expressions are not anchored -- Specify valid implementation-defined options for handling schemas without "$schema" -- Clarify that vocabularies omitted from "$vocabulary" MUST NOT be available for use -- Clarify that standard keywords are only available as vocabulary keywords, subject to "$vocabulary" control -- Clarify the nature and purpose of optional (set to false in "$vocabulary") vocabularies -- Clarify that optional simple-annotation-only vocabularies can be supported without custom code -- Fix typo that "$vocabulary" can only be in a document root; it is legal in resource roots +- Specify valid implementation-defined options for handling schemas without + "$schema" +- Clarify that vocabularies omitted from "$vocabulary" MUST NOT be available for + use +- Clarify that standard keywords are only available as vocabulary keywords, + subject to "$vocabulary" control +- Clarify the nature and purpose of optional (set to false in "$vocabulary") + vocabularies +- Clarify that optional simple-annotation-only vocabularies can be supported + without custom code +- Fix typo that "$vocabulary" can only be in a document root; it is legal in + resource roots - Remove bookending requirement for `$dynamicRef` - Clarify that "prefixItems" does not constrain the length of an array -- Move "minContains" and "maxContains" to the applicator vocabulary from validation +- Move "minContains" and "maxContains" to the applicator vocabulary from + validation - "minContains" and "maxContains" no longer have their own assertion results - "contains" assertion result now depends on "minContains" and "maxContains" -- Affirm that no keyword can un-fail an adjacent keyword ("minContains" previously violated this) -- "contains", "minContains", and "maxContains" now apply to objects as well as arrays +- Affirm that no keyword can un-fail an adjacent keyword ("minContains" + previously violated this) +- "contains", "minContains", and "maxContains" now apply to objects as well as + arrays - As an object keyword, "contains" now affects "unevaluatedProperties" - Add `propertyDependencies` keyword -- Add new "list" and "hierarchical" output formats in place of "basic", "detailed", and "verbose" -- Rename "absoluteKeywordLocation" and "keywordLocation" to "schemaLocation" and "evaluationPath" -- Output units in new format group by "schemaLocation", "instanceLocation", and "evaluationPath" +- Add new "list" and "hierarchical" output formats in place of "basic", + "detailed", and "verbose" +- Rename "absoluteKeywordLocation" and "keywordLocation" to "schemaLocation" and + "evaluationPath" +- Output units in new format group by "schemaLocation", "instanceLocation", and + "evaluationPath" - Add "droppedAnnotations" to output formats ### draft-bhutton-json-schema-01 diff --git a/jsonschema-validation.md b/jsonschema-validation.md index 78c53f91..2251d9a3 100644 --- a/jsonschema-validation.md +++ b/jsonschema-validation.md @@ -234,9 +234,9 @@ Omitting this keyword has the same behavior as a value of 0. The value of this keyword MUST be a boolean. -If this keyword has boolean value `false`, the instance validates successfully. If -it has boolean value `true`, the instance validates successfully if all of its -elements are unique. +If this keyword has boolean value `false`, the instance validates successfully. +If it has boolean value `true`, the instance validates successfully if all of +its elements are unique. Omitting this keyword has the same behavior as a value of `false`. @@ -317,8 +317,8 @@ which choose to support assertion behavior: - MUST still collect the keyword's value as an annotation (if the implementation supports annotation collection), -- MUST provide a configuration option to enable assertion behavior, defaulting to - annotation-only behavior +- MUST provide a configuration option to enable assertion behavior, defaulting + to annotation-only behavior - SHOULD provide an implementation-specific best effort validation for each format attribute defined below;[^3] - MAY choose to implement validation of any or all format attributes as a no-op @@ -662,7 +662,8 @@ associated schema. The value of this keyword MUST be a boolean. When multiple occurrences of this keyword are applicable to a single sub-instance, applications SHOULD consider -the instance location to be deprecated if any occurrence specifies a `true` value. +the instance location to be deprecated if any occurrence specifies a `true` +value. If `deprecated` has a value of boolean `true`, it indicates that applications SHOULD refrain from usage of the declared property. It MAY mean the property is @@ -695,11 +696,11 @@ An instance document that is marked as `readOnly` for the entire document MAY be ignored if sent to the owning authority, or MAY result in an error, at the authority's discretion. -If `writeOnly` has a value of boolean `true`, it indicates that the value is never -present when the instance is retrieved from the owning authority. It can be -present when sent to the owning authority to update or create the document (or -the resource it represents), but it will not be included in any updated or newly -created version of the instance. +If `writeOnly` has a value of boolean `true`, it indicates that the value is +never present when the instance is retrieved from the owning authority. It can +be present when sent to the owning authority to update or create the document +(or the resource it represents), but it will not be included in any updated or +newly created version of the instance. An instance document that is marked as `writeOnly` for the entire document MAY be returned as a blank document of some sort, or MAY produce an error upon @@ -899,9 +900,12 @@ to the document. - *draft-next* - Use IRIs instead of URIs - - Move "minContains" and "maxContains" to the applicator vocabulary (see also that changelog) - - Remove the optional automatic second-pass validation of "content*" keywords - - Clarify that "contentSchema"'s value is a schema just like any other subschema + - Move "minContains" and "maxContains" to the applicator vocabulary (see + also that changelog) + - Remove the optional automatic second-pass validation of "content*" + keywords + - Clarify that "contentSchema"'s value is a schema just like any other + subschema - *draft-bhutton-json-schema-validation-01* - Improve and clarify the `minContains` keyword explanation - Remove the use of "production" in favour of "ABNF rule" diff --git a/output/jsonschema-validation-output-machines.md b/output/jsonschema-validation-output-machines.md index 398162bb..9012da2e 100644 --- a/output/jsonschema-validation-output-machines.md +++ b/output/jsonschema-validation-output-machines.md @@ -172,10 +172,14 @@ The failing instance will produce the following errors: is not a number. The passing instance will produce the following annotations: diff --git a/proposals/propertyDependencies-adr.md b/proposals/propertyDependencies-adr.md index 315357b6..f6ae0200 100644 --- a/proposals/propertyDependencies-adr.md +++ b/proposals/propertyDependencies-adr.md @@ -1,14 +1,16 @@ # Add New Keyword: `propertyDependencies` -* Status: proposed -* Deciders: @gregsdennis, @jdesrosiers, @relequestual -* Date: 2022-04-07 +- Status: proposed +- Deciders: @gregsdennis, @jdesrosiers, @relequestual +- Date: 2022-04-07 Technical Story: -- Issue discussing feature - https://github.com/json-schema-org/json-schema-spec/issues/1082 -- PR to add to the spec - https://github.com/json-schema-org/json-schema-spec/pull/1143 -- ADR to extract from the spec and use feature life cycle - https://github.com/json-schema-org/json-schema-spec/pull/1505 +- Issue discussing feature - +- PR to add to the spec - +- ADR to extract from the spec and use feature life cycle - + +## Table of Contents ## Context and Problem Statement @@ -33,7 +35,8 @@ adopt or redefine `discriminator`. ## Considered Options -All of the following options have the same validation result as the following schema. +All of the following options have the same validation result as the following +schema. ```json { @@ -64,10 +67,10 @@ that concept to solve this problem. } ``` -* Good, because it handle the most common use case: string property values -* Good, because all property values are grouped together -* Good, because it's less verbose -* Bad, because it doesn't handle non-string property values +- Good, because it handle the most common use case: string property values +- Good, because all property values are grouped together +- Good, because it's less verbose +- Bad, because it doesn't handle non-string property values ### Option 2 @@ -97,7 +100,9 @@ prone. * Good, because it supports all use cases * Bad, because properties are not naturally grouped together * Bad, because it's quite verbose -* Bad, because we have no precedent for a keyword which explicitly defines its own properties. This would be new operational functionality, which we try to avoid if we can. +* Bad, because we have no precedent for a keyword which explicitly defines its + own properties. This would be new operational functionality, which we try to + avoid if we can. ### Option 3 @@ -124,7 +129,9 @@ object. It's still too verbose. * Good, because it supports all use cases * Good, because all property values are grouped together * Bad, because it's quite verbose -* Bad, because we have no precedent for a keyword which explicitly defines its own properties. This would be new operational functionality, which we try to avoid if we can. +* Bad, because we have no precedent for a keyword which explicitly defines its + own properties. This would be new operational functionality, which we try to + avoid if we can. ### Option 4 @@ -148,10 +155,11 @@ naming aside), but otherwise has all the same problems as the other examples. } ``` -* Good, because it supports all use cases -* Bad, because properties are not naturally grouped together -* Bad, because it's very verbose -* Bad, because it introduces a lot of inter-keyword dependencies, which we'd have to exhaustively define +- Good, because it supports all use cases +- Bad, because properties are not naturally grouped together +- Bad, because it's very verbose +- Bad, because it introduces a lot of inter-keyword dependencies, which we'd + have to exhaustively define ### Option 5 @@ -183,7 +191,8 @@ verbose. * Good, because it's a familiar syntax * Bad, because properties are not naturally grouped together * Bad, because it's very verbose -* Bad, because `ifProperties` is very niche. Will this spawn a new series of `if*` keywords? How would it interact with `if`? +* Bad, because `ifProperties` is very niche. Will this spawn a new series of + `if*` keywords? How would it interact with `if`? ### Option 6 diff --git a/proposals/propertyDependencies.md b/proposals/propertyDependencies.md index 757b5652..ffc45a5f 100644 --- a/proposals/propertyDependencies.md +++ b/proposals/propertyDependencies.md @@ -39,7 +39,8 @@ specification](../jsonschema-core.html) also apply to this document. A common need in JSON Schema is to select between one schema or another to validate an instance based on the value of some property in the JSON instance. There are a several patterns people use to accomplish this, but they all have -significant [problems](propertyDependencies-adr.md#problems). +significant [problems](propertyDependencies-adr.md#problems). OpenAPI solves this problem with the `discriminator` keyword. However, their approach is more oriented toward code generation concerns, is poorly specified @@ -88,26 +89,31 @@ those goals means that some trade-offs need to be made. ## Change Description -The `propertyDependencies` keyword will be added to the `https://json-schema.org/vocab/applicator` [applicator +The `propertyDependencies` keyword will be added to the +`https://json-schema.org/vocab/applicator` [applicator vocabulary](../jsonschema-core.html#applicatorvocab). -1. The following will be added to the JSON Schema Core specification as a +1. The following will be added to the JSON Schema Core specification as a subsection of "Keywords for Applying Subschemas Conditionally". > ### `propertyDependencies` > > This keyword specifies subschemas that are evaluated if the instance is an > object and contains a certain property with a certain string value. > - > This keyword's value MUST be an object. Each value in the object MUST be an - > object whose values MUST be valid JSON Schemas. + > This keyword's value MUST be an object. Each value in the object MUST be + > an object whose values MUST be valid JSON Schemas. > - > If the outer object key is a property in the instance and the inner object key - > is equal to the value of that property, the entire instance must validate - > against the schema. Its use is dependent on the presence and value of the - > property. + > If the outer object key is a property in the instance and the inner object + > key is equal to the value of that property, the entire instance must + > validate against the schema. Its use is dependent on the presence and + > value of the property. > > Omitting this keyword has the same behavior as an empty object. -2. The following subschema will be added to the Applicator Vocabulary schema, `https://json-schema.org///meta/applicator` at `/properties/propertyDependencies`: + +2. The following subschema will be added to the Applicator Vocabulary schema, + `https://json-schema.org///meta/applicator` at + `/properties/propertyDependencies`: + ```json { "type": "object", @@ -124,9 +130,9 @@ subsection of "Keywords for Applying Subschemas Conditionally". ## [Appendix] Change Log -* [March 2021] - Initially proposed -* [October 2021] Added to specification document -* [May 2024] Extracted from specification document as experimental feature +- [March 2021] - Initially proposed +- [October 2021] Added to specification document +- [May 2024] Extracted from specification document as experimental feature ## Champions diff --git a/proposals/proposal-template.md b/proposals/proposal-template.md index 62381696..1c65f770 100644 --- a/proposals/proposal-template.md +++ b/proposals/proposal-template.md @@ -3,8 +3,8 @@ ## Abstract +- Good, because [argument a] +- Good, because [argument b] +- Bad, because [argument c] +- ... ### [option 3] [example | description | pointer to more information | …] -* Good, because [argument a] -* Good, because [argument b] -* Bad, because [argument c] -* … +- Good, because [argument a] +- Good, because [argument b] +- Bad, because [argument c] +- ... ## Decision Outcome -_TBD_ +*TBD* ### Positive Consequences -_TBD_ +*TBD* ### Negative Consequences -_TBD_ +*TBD* diff --git a/proposals/vocabularies.md b/proposals/vocabularies.md index 619688bd..9690fa64 100644 --- a/proposals/vocabularies.md +++ b/proposals/vocabularies.md @@ -112,9 +112,9 @@ The boolean values in `$vocabulary` signify implementation requirements for each vocabulary. - A `true` value indicates that the implementation must recognize the vocabulary - and be able to process each of the keywords defined in it. If an implementation - does not recognize the vocabulary or cannot process all of its defined - keywords, the implementation must refuse to process the schema. These + and be able to process each of the keywords defined in it. If an + implementation does not recognize the vocabulary or cannot process all of its + defined keywords, the implementation must refuse to process the schema. These vocabularies are also known as "required" vocabularies. - A `false` value indicates that the implementation is not required to recognize the vocabulary or its keywords and may continue processing the schema anyway. @@ -153,7 +153,8 @@ reference (via `$ref`) to the vocabulary schema's `$id` value. Finally, the keywords in both the Core and Validation specifications will be divided into multiple vocabularies. The keyword definitions will be removed from the meta-schema and added to vocabulary schemas to which the meta-schema will -contain references. In this way, the meta-schema's functionality remains the same. +contain references. In this way, the meta-schema's functionality remains the +same. ```json { @@ -252,7 +253,10 @@ For example ``` --> -_**NOTE** Since the design of vocabularies will be changing anyway, it's not worth the time and effort to fill in this section just yet. As such, please read the above sections for loose requirements. For tighter requirements, please assume conformance with the 2020-12 Core and Validation specifications._ +***NOTE** Since the design of vocabularies will be changing anyway, it's not +worth the time and effort to fill in this section just yet. As such, please +read the above sections for loose requirements. For tighter requirements, +please assume conformance with the 2020-12 Core and Validation specifications.* ## [Appendix] Change Log @@ -260,6 +264,6 @@ _**NOTE** Since the design of vocabularies will be changing anyway, it's not wor ## [Appendix] Champions -| Champion | Company | Email | URI | -|----------------------------|---------|-------------------------|----------------------------------| -| Greg Dennis | | gregsdennis@yahoo.com | https://github.com/gregsennis | +| Champion | Company | Email | URI | +|-------------|---------|--------------------------------|---------------------------------| +| Greg Dennis | | | | From 936cf2ddb343f8c23a5d050394f7636b82bc9963 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Mon, 21 Oct 2024 11:13:44 -0700 Subject: [PATCH 650/780] Build spec files to the "web" folder --- .gitignore | 11 +++++++---- README.md | 3 ++- build/build.js | 21 +++++++++++++-------- package.json | 2 +- 4 files changed, 23 insertions(+), 14 deletions(-) diff --git a/.gitignore b/.gitignore index 593a560e..7007b640 100644 --- a/.gitignore +++ b/.gitignore @@ -1,10 +1,13 @@ -jsonschema-*.html -jsonschema-*.pdf -jsonschema-*.txt +# Markdown builds +web/ + +# IETF builds +json-schema-use-cases.html +json-schema-use-cases.pdf +json-schema-use-cases.txt relative-json-pointer.html relative-json-pointer.pdf relative-json-pointer.txt -proposals/*.html # For the Python enviornment .venv diff --git a/README.md b/README.md index d57a233b..9b5bb701 100644 --- a/README.md +++ b/README.md @@ -29,7 +29,8 @@ To build the spec files to HTML from the Markdown sources, run `npm run build-all`. You can also build each individually with `npm run build -- filename.md` (Example: `npm run build -- jsonschema-core.md`). You can also use wildcards to -build multiple specs at the same time: `npm run build -- jsonschema-*.md`. +build multiple specs at the same time: `npm run build -- jsonschema-*.md`. The +HTML files will be available in the `web` folder. The spec is built using [Remark](https://remark.js.org/), a markdown engine with good support for plugins and lots of existing plugins we can use. diff --git a/build/build.js b/build/build.js index 25533986..81afbfc8 100644 --- a/build/build.js +++ b/build/build.js @@ -1,8 +1,8 @@ /* eslint-disable no-console */ import dotenv from "dotenv"; -import { readFileSync, writeFileSync } from "node:fs"; -import { dirname, basename } from "node:path"; -import { argv } from "node:process"; +import { mkdir, readFile, writeFile } from "node:fs/promises"; +import { dirname, resolve, relative } from "node:path"; +import { argv, cwd } from "node:process"; import { reporter } from "vfile-reporter"; import { remark } from "remark"; import remarkCodeTitles from "./remark-code-titles.js"; @@ -22,8 +22,8 @@ import rehypeStringify from "rehype-stringify"; dotenv.config(); -const build = async (filename) => { - const md = readFileSync(filename, "utf-8"); +const build = async (filePath) => { + const md = await readFile(filePath, "utf-8"); const file = await remark() .use(remarkPresetLintMarkdownStyleGuide) .use(remarkLintMaximumHeadingLength, false) @@ -62,8 +62,12 @@ const build = async (filename) => { .use(rehypeStringify) .process(md); - const outfile = `${dirname(filename)}/${basename(filename, ".md")}.html`; - writeFileSync(outfile, ` + const rootPath = resolve(import.meta.dirname, ".."); + const outPath = resolve(rootPath, "web"); + const sourceRelativePath = relative(rootPath, filePath); + const outfile = resolve(outPath, sourceRelativePath).replace(/\.md$/, ".html"); + await mkdir(dirname(outfile), { recursive: true }); + await writeFile(outfile, ` @@ -184,7 +188,8 @@ const build = async (filename) => { let messageCount = 0; for (const filename of files) { console.log(`Building: ${filename} ...`); - messageCount += await build(filename); + const filePath = resolve(cwd(), filename); + messageCount += await build(filePath); console.log(""); } diff --git a/package.json b/package.json index 7a7c22bd..bb25a6bc 100644 --- a/package.json +++ b/package.json @@ -6,7 +6,7 @@ "main": "index.js", "scripts": { "lint": "eslint build/", - "build-all": "node build/build.js jsonschema-*.md proposals/*.md", + "build-all": "node build/build.js jsonschema-*.md proposals/*.md output/*.md", "build": "node build/build.js" }, "license": "MIT", From 08943f7995b551ce609661f0cd9b5e382411bc9b Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Mon, 21 Oct 2024 11:17:27 -0700 Subject: [PATCH 651/780] Restore ietf build automation --- .github/workflows/ci.yml | 36 +++++++++++++++++++++++++++--------- 1 file changed, 27 insertions(+), 9 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index ca742dc6..df0006d7 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -4,14 +4,32 @@ on: - pull_request jobs: - specs: + specs-markdown: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v4 - - uses: actions/setup-node@v4 - with: - node-version: latest - cache: npm - - run: npm ci - - run: npm run lint - - run: npm run build-all + - uses: actions/checkout@v4 + - uses: actions/setup-node@v4 + with: + node-version: latest + cache: npm + - run: npm ci + - run: npm run lint + - run: npm run build-all + + specs-ietf: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v3 + - uses: actions/setup-python@v4 + with: + python-version: "3.10" + - run: pip install --requirement requirements.txt + - run: xml2rfc --version + - run: make all + - uses: actions/upload-artifact@v3 + with: + name: specification-docs + path: | + *.html + *.txt + !requirements.txt From 71dd8164bd124da0d1967ab9d56ad71033dda8e9 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 1 Oct 2024 10:44:29 +1300 Subject: [PATCH 652/780] replace 'IRI' ABNF symbol references with plain language --- jsonschema-core.md | 32 ++++++++++++++++---------------- jsonschema-validation.md | 6 +++--- 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index 7ea5cc15..c7faeec6 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -452,8 +452,8 @@ The lexical scope of a keyword is determined by the nested JSON data structure of objects and arrays. The largest such scope is an entire schema document. The smallest scope is a single schema object with no subschemas. -Keywords MAY be defined with a partial value, such as a IRI-reference, which -must be resolved against another value, such as another IRI-reference or a full +Keywords MAY be defined with a partial value, such as a IRI reference, which +must be resolved against another value, such as another IRI reference or a full IRI, which is found through the lexical structure of the JSON document. The `$id`, `$ref`, and `$dynamicRef` core keywords, and the "base" JSON Hyper-Schema keyword, are examples of this sort of behavior. @@ -542,7 +542,7 @@ Identifiers define IRIs for a schema, or affect how such IRIs are resolved in keywords, most notably `$id`. Canonical schema IRIs MUST NOT change while processing an instance, but keywords -that affect IRI-reference resolution MAY have behavior that is only fully +that affect IRI reference resolution MAY have behavior that is only fully determined at runtime. While custom identifier keywords are possible, extension designers should take @@ -898,8 +898,8 @@ To differentiate between schemas in a vast ecosystem, schemas are identified by [IRI](#rfc3987), and can embed references to other schemas by specifying their IRI. -Several keywords can accept a relative [IRI-reference](#rfc3987), or a value -used to construct a relative IRI-reference. For these keywords, it is necessary +Several keywords can accept a relative [IRI reference](#rfc3987), or a value +used to construct a relative IRI reference. For these keywords, it is necessary to establish a base IRI in order to resolve the reference. #### The `$id` Keyword {#id-keyword} @@ -912,10 +912,10 @@ the case of a network-addressable URL, a schema need not be downloadable from its canonical IRI. If present, the value for this keyword MUST be a string, and MUST represent a -valid [IRI-reference](#rfc3987). This IRI-reference SHOULD be normalized, and -MUST resolve to an [absolute-IRI](#rfc3987) (without a fragment). +valid [IRI reference](#rfc3987). This IRI reference SHOULD be normalized, and +MUST resolve to an [absolute IRI](#rfc3987) (without a fragment). -The resulting absolute-IRI serves as the base IRI for relative IRI-references in +The resulting absolute IRI serves as the base IRI for relative IRI references in keywords within the schema resource, in accordance with [RFC 3987 section 6.5](#rfc3987) and [RFC 3986 section 5.1.1](#rfc3986) regarding base IRIs embedded in content. @@ -924,7 +924,7 @@ The presence of `$id` in a subschema indicates that the subschema constitutes a distinct schema resource within a single schema document. Furthermore, in accordance with [RFC 3987 section 6.5](#rfc3987) and [RFC 3986 section 5.1.2](#rfc3986) regarding encapsulating entities, if an `$id` in a subschema is -a relative IRI-reference, the base IRI for resolving that reference is the IRI +a relative IRI reference, the base IRI for resolving that reference is the IRI of the parent schema resource. Note that an `$id` consisting of an empty IRI or of the empty fragment only will result in the embedded resource having the same IRI as the encapsulating resource, which SHOULD be considered an error per @@ -937,7 +937,7 @@ given in the [previous section.](initial-base) ##### Identifying the root schema The root schema of a JSON Schema document SHOULD contain an `$id` keyword with -an [absolute-IRI](#rfc3987) (containing a scheme, but no fragment). +an [absolute IRI](#rfc3987) (containing a scheme, but no fragment). #### Defining location-independent identifiers {#anchors} @@ -971,7 +971,7 @@ If present, the value of these keywords MUST be a string and MUST conform to the plain name fragment identifier syntax defined in {{fragments}}.[^4] [^4]: Note that the anchor string does not include the "#" character, as it is -not a IRI-reference. An `$anchor`: "foo" becomes the fragment `#foo` when used +not a IRI reference. An `$anchor`: "foo" becomes the fragment `#foo` when used in a IRI. See below for full examples. #### Duplicate schema identifiers {#duplicate-iris} @@ -1005,7 +1005,7 @@ identified schema. Its results are the results of the referenced schema.[^5] [^5]: Note that this definition of how the results are determined means that other keywords can appear alongside of `$ref` in the same schema object. -The value of the `$ref` keyword MUST be a string which is a IRI-Reference. +The value of the `$ref` keyword MUST be a string which is a IRI reference. Resolved against the current IRI base, it produces the IRI of the schema to apply. This resolution is safe to perform on schema load, as the process of evaluating an instance cannot change how the reference resolves. @@ -1022,7 +1022,7 @@ reference themselves). The extension point is defined with `$dynamicAnchor` and only exhibits runtime dynamic behavior when referenced with `$dynamicRef`. The value of the `$dynamicRef` property MUST be a string which is a -IRI-Reference that contains a valid [plain name fragment](#anchors). Resolved +IRI reference that contains a valid [plain name fragment](#anchors). Resolved against the current IRI base, it indicates the schema resource used as the starting point for runtime resolution. This initial resolution is safe to perform on schema load. @@ -2284,9 +2284,9 @@ simplify coding so that various invocations of JSON Schema libraries do not have to keep track of and load a large number of resources. This transformation can be safely and reversibly done as long as all static -references (e.g. `$ref`) use IRI-references that resolve to IRIs using the +references (e.g. `$ref`) use IRI references that resolve to IRIs using the canonical resource IRI as the base, and all schema resources have an -absolute-IRI as the `$id` in their root schema. +absolute IRI as the `$id` in their root schema. With these conditions met, each external resource can be copied under `$defs`, without breaking any references among the resources' schema objects, and without @@ -2470,7 +2470,7 @@ to the document. - Clarify that detecting duplicate IRIs for different schemas SHOULD raise an error - Consolidate and clarify the syntax and rationale for plain-name fragments -- "$id" MUST be an absolute-IRI, without any fragment, even an empty one +- "$id" MUST be an absolute IRI, without any fragment, even an empty one - Note that an empty string "$id" results in duplicate IRIs for different schemas - Define empty schemas as empty (no longer allowing unrecognized keywords) diff --git a/jsonschema-validation.md b/jsonschema-validation.md index 2251d9a3..2768cb12 100644 --- a/jsonschema-validation.md +++ b/jsonschema-validation.md @@ -444,7 +444,7 @@ representation of an IP address as follows: [RFC3986](#rfc3986). - *iri:* A string instance is valid against this attribute if it is a valid IRI, according to [RFC3987](#rfc3987). -- *iri-reference:* A string instance is valid against this attribute if it is a +- *IRI reference:* A string instance is valid against this attribute if it is a valid IRI Reference (either an IRI or a relative-reference), according to [RFC3987](#rfc3987). - *uuid:* A string instance is valid against this attribute if it is a valid @@ -563,7 +563,7 @@ The value of this property MUST be a valid JSON schema. It SHOULD be ignored if location IRI included as part of the annotation will ensure that it is correctly processed as a subschema. Using the extracted annotation value directly is only safe if the schema is an embedded resource with both `$schema` and an -absolute-IRI `$id`. +absolute IRI `$id`. ### Example @@ -952,7 +952,7 @@ schema form to the core spec - Restored "regex" format (removal was unintentional) - Added "date" and "time" formats, and reserved additional RFC 3339 format names - - I18N formats: "iri", "iri-reference", "idn-hostname", "idn-email" + - I18N formats: "iri", "IRI reference", "idn-hostname", "idn-email" - Clarify that "json-pointer" format means string encoding, not URI fragment - Fixed typo that inverted the meaning of `minimum` and `exclusiveMinimum` - Move format syntax references into Normative References From 16c475a81a80059ced3b848aacdc47c842453d0e Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 1 Oct 2024 11:21:03 +1300 Subject: [PATCH 653/780] resolves #1349 - add explicit pointer to IRI normalization process --- jsonschema-core.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index c7faeec6..b0018bf5 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -912,8 +912,9 @@ the case of a network-addressable URL, a schema need not be downloadable from its canonical IRI. If present, the value for this keyword MUST be a string, and MUST represent a -valid [IRI reference](#rfc3987). This IRI reference SHOULD be normalized, and -MUST resolve to an [absolute IRI](#rfc3987) (without a fragment). +valid [IRI reference](#rfc3987). This IRI reference SHOULD be normalized per RFC +3987, section 5.3, and MUST resolve to an [absolute IRI](#rfc3987) (without a +fragment). The resulting absolute IRI serves as the base IRI for relative IRI references in keywords within the schema resource, in accordance with [RFC 3987 section From 64fbf863e0530bd59fdeb595bb9f3a8752696060 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 1 Oct 2024 13:19:06 +1300 Subject: [PATCH 654/780] pointers across resource boundary is undefined --- jsonschema-core.md | 56 +++++++++++++++++++++++++--------------------- 1 file changed, 31 insertions(+), 25 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index b0018bf5..a2754809 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -933,7 +933,7 @@ IRI as the encapsulating resource, which SHOULD be considered an error per If no parent schema object explicitly identifies itself as a resource with `$id`, the base IRI is that of the entire document, as established by the steps -given in the [previous section.](initial-base) +given in {{initial-base}}. ##### Identifying the root schema @@ -1191,15 +1191,9 @@ automatically. When an implementation encounters the reference to "other.json", it resolves this to `https://example.net/other.json`, which is not defined in this document. -If a schema with that identifier has otherwise been supplied to the -implementation, it can also be used automatically.[^7] - -[^7]: What should implementations do when the referenced schema is not known? -Are there circumstances in which automatic network dereferencing is allowed? A -same origin policy? A user-configurable option? In the case of an evolving API -described by Hyper-Schema, it is expected that new schemas will be added to the -system dynamically, so placing an absolute requirement of pre-loading schema -documents is not feasible. +If an implementation has been configured to resolve that identifier to a schema +via pre-loading or other means, it can be used automatically; otherwise, the +behavior described in {{failed-refs}} MUST be used. #### JSON Pointer fragments and embedded schema resources {#embedded} @@ -1272,10 +1266,10 @@ the `$id` of the embedded or referenced resource unless it is specifically desired to identify the object containing the `$ref` in the second (non-embedded) arrangement. -An implementation MAY choose not to support addressing schema resource contents -by IRIs using a base other than the resource's canonical IRI, plus a JSON -Pointer fragment relative to that base. Therefore, schema authors SHOULD NOT -rely on such IRIs, as using them may reduce interoperability.[^8] +Due to the potential break in functionality described above, the behavior for +using JSON Pointer fragments that point to or cross a resource boundary is +undefined. Schema authors SHOULD NOT rely on such IRIs, as using them may +reduce interoperability. [^8]: This is to avoid requiring implementations to keep track of a whole stack of possible base IRIs and JSON Pointer fragments for each, given that all but @@ -1408,7 +1402,7 @@ behave correctly under implementations that attempt to use any reference target as a schema. However, this behavior is implementation-specific and MUST NOT be relied upon for interoperability. -#### Failure to resolve references +#### Failure to resolve references {#failed-refs} If for any reason a reference cannot be resolved, the evaluation MUST halt and return an indeterminant result. Specifically, it MUST NOT return a passing or @@ -2231,32 +2225,22 @@ listed IRI in accordance with {{fragments}} and {{embedded}} above. `#/$defs/B`: canonical (and base) `IRI: https://example.com/other.json` - canonical resource IRI plus pointer fragment: `https://example.com/other.json#` -- base IRI of enclosing (root.json) resource plus fragment: - `https://example.com/root.json#/$defs/B` `#/$defs/B/$defs/X`: base IRI: `https://example.com/other.json` - canonical resource IRI plus plain fragment: `https://example.com/other.json#bar` - canonical resource IRI plus pointer fragment: `https://example.com/other.json#/$defs/X` -- base IRI of enclosing (root.json) resource plus fragment: - `https://example.com/root.json#/$defs/B/$defs/X` `#/$defs/B/$defs/Y`: canonical (and base) IRI: `https://example.com/t/inner.json` - canonical IRI plus plain fragment: `https://example.com/t/inner.json#bar` - canonical IRI plus pointer fragment: `https://example.com/t/inner.json#` -- base IRI of enclosing (other.json) resource plus fragment: - `https://example.com/other.json#/$defs/Y` -- base IRI of enclosing (root.json) resource plus fragment: - `https://example.com/root.json#/$defs/B/$defs/Y` `#/$defs/C`: canonical (and base) IRI: `urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f` - canonical IRI plus pointer fragment: `urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f#` -- base IRI of enclosing (root.json) resource plus fragment: - `https://example.com/root.json#/$defs/C` Note: The fragment part of the IRI does not make it canonical or non-canonical, rather, the base IRI used (as part of the full IRI with any fragment) is what @@ -2266,6 +2250,28 @@ determines the canonical nature of the resulting full IRI.[^18] and direct you to read the CREF located in the [JSON Pointer fragments and embedded schema resources](#embedded) section for further comments. +While the following IRIs do correctly indicate specific schemas, per the reasons outlined in {{embedded}}, they are to be avoided: + +`#/$defs/B`: canonical (and base) `IRI: https://example.com/other.json` +- base IRI of enclosing (root.json) resource plus fragment: + `https://example.com/root.json#/$defs/B` + +`#/$defs/B/$defs/X`: base IRI: `https://example.com/other.json` +- base IRI of enclosing (root.json) resource plus fragment: + `https://example.com/root.json#/$defs/B/$defs/X` + +`#/$defs/B/$defs/Y`: canonical (and base) IRI: +`https://example.com/t/inner.json` +- base IRI of enclosing (other.json) resource plus fragment: + `https://example.com/other.json#/$defs/Y` +- base IRI of enclosing (root.json) resource plus fragment: + `https://example.com/root.json#/$defs/B/$defs/Y` + +`#/$defs/C`: canonical (and base) IRI: +`urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f` +- base IRI of enclosing (root.json) resource plus fragment: + `https://example.com/root.json#/$defs/C` + ## [Appendix] Manipulating schema documents and references Various tools have been created to rearrange schema documents based on how and From a38117ac8609e7cad9e0ab7480490b9d401dbc54 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 1 Oct 2024 13:27:56 +1300 Subject: [PATCH 655/780] remove paragraphs about ref-ing into unknown keywords --- jsonschema-core.md | 17 +---------------- 1 file changed, 1 insertion(+), 16 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index a2754809..f1b2f2e7 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -1313,7 +1313,7 @@ When the Schema Resource referenced by a by-reference applicator is bundled, it is RECOMMENDED that the Schema Resource be located as a value of a `$defs` object at the containing schema's root. The key of the `$defs` for the now embedded Schema Resource MAY be the `$id` of the bundled schema or some other -form of application defined unique identifer (such as a UUID). This key is not +form of application defined unique identifier (such as a UUID). This key is not intended to be referenced in JSON Schema, but may be used by an application to aid the bundling process. @@ -1381,21 +1381,6 @@ applicator keywords or with location-reserving keywords such as be `$defs` and the standard applicators from this document or implementation-specific custom keywords. -Multi-level structures of unknown keywords are capable of introducing nested -subschemas, which would be subject to the processing rules for `$id`. Therefore, -having a reference target in such an unrecognized structure cannot be reliably -implemented, and the resulting behavior is undefined. Similarly, a reference -target under a known keyword, for which the value is known not to be a schema, -results in undefined behavior in order to avoid burdening implementations with -the need to detect such targets.[^10] - -[^10]: These scenarios are analogous to fetching a schema over HTTP but -receiving a response with a Content-Type other than `application/schema+json`. -An implementation can certainly try to interpret it as a schema, but the origin -server offered no guarantee that it actually is any such thing. Therefore, -interpreting it as such has security implication and may produce unpredictable -results. - Note that single-level custom keywords with identical syntax and semantics to `$defs` do not allow for any intervening `$id` keywords, and therefore will behave correctly under implementations that attempt to use any reference target From e9aed4ae88268b41e425dd9733d52167326513fe Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 1 Oct 2024 13:33:11 +1300 Subject: [PATCH 656/780] fix line wrapping --- jsonschema-core.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index f1b2f2e7..47602947 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -2235,7 +2235,8 @@ determines the canonical nature of the resulting full IRI.[^18] and direct you to read the CREF located in the [JSON Pointer fragments and embedded schema resources](#embedded) section for further comments. -While the following IRIs do correctly indicate specific schemas, per the reasons outlined in {{embedded}}, they are to be avoided: +While the following IRIs do correctly indicate specific schemas, per the reasons +outlined in {{embedded}}, they are to be avoided: `#/$defs/B`: canonical (and base) `IRI: https://example.com/other.json` - base IRI of enclosing (root.json) resource plus fragment: From 1d61c8737d5d00bf6f333d38dde3462710ecce65 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 2 Oct 2024 21:04:10 +1300 Subject: [PATCH 657/780] add comment ref back; update appendix format per PR discussion --- jsonschema-core.md | 42 ++++++++++++++++++++++++++---------------- 1 file changed, 26 insertions(+), 16 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index 47602947..51e7a7df 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -1269,7 +1269,7 @@ desired to identify the object containing the `$ref` in the second Due to the potential break in functionality described above, the behavior for using JSON Pointer fragments that point to or cross a resource boundary is undefined. Schema authors SHOULD NOT rely on such IRIs, as using them may -reduce interoperability. +reduce interoperability.[^8] [^8]: This is to avoid requiring implementations to keep track of a whole stack of possible base IRIs and JSON Pointer fragments for each, given that all but @@ -2194,35 +2194,42 @@ name fragment identifiers. } ``` -The schemas at the following IRI-encoded [JSON Pointers](#rfc6901) (relative to -the root schema) have the following base IRIs, and are identifiable by any -listed IRI in accordance with {{fragments}} and {{embedded}} above. +The schemas at the following locations (indicated by plain +[JSON Pointers](#rfc6901) relative to the root document) have the following base +IRIs, and are identifiable by any listed IRI in accordance with {{fragments}} +and {{embedded}} above. -`#` (document root): canonical (and base) IRI: `https://example.com/root.json` +Document root: +- canonical (and base) IRI: `https://example.com/root.json` - canonical resource IRI plus pointer fragment: `https://example.com/root.json#` -`#/$defs/A`: base IRI: `https://example.com/root.json` +Document location `/$defs/A`: +- base IRI: `https://example.com/root.json` - canonical resource IRI plus plain fragment: `https://example.com/root.json#foo` - canonical resource IRI plus pointer fragment: `https://example.com/root.json#/$defs/A` -`#/$defs/B`: canonical (and base) `IRI: https://example.com/other.json` +Document location `/$defs/B`: +- canonical (and base) `IRI: https://example.com/other.json` - canonical resource IRI plus pointer fragment: `https://example.com/other.json#` -`#/$defs/B/$defs/X`: base IRI: `https://example.com/other.json` +Document location `/$defs/B/$defs/X`: +- base IRI: `https://example.com/other.json` - canonical resource IRI plus plain fragment: `https://example.com/other.json#bar` - canonical resource IRI plus pointer fragment: `https://example.com/other.json#/$defs/X` -`#/$defs/B/$defs/Y`: canonical (and base) IRI: +Document location `/$defs/B/$defs/Y`: +- canonical (and base) IRI: `https://example.com/t/inner.json` - canonical IRI plus plain fragment: `https://example.com/t/inner.json#bar` - canonical IRI plus pointer fragment: `https://example.com/t/inner.json#` -`#/$defs/C`: canonical (and base) IRI: +Document location `/$defs/C`: +- canonical (and base) IRI: `urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f` - canonical IRI plus pointer fragment: `urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f#` @@ -2232,28 +2239,31 @@ rather, the base IRI used (as part of the full IRI with any fragment) is what determines the canonical nature of the resulting full IRI.[^18] [^18]: Multiple "canonical" IRIs? We Acknowledge this is potentially confusing, -and direct you to read the CREF located in the [JSON Pointer fragments and -embedded schema resources](#embedded) section for further comments. +and direct you to read the CREF located in {{#embedded}} for further comments. While the following IRIs do correctly indicate specific schemas, per the reasons outlined in {{embedded}}, they are to be avoided: -`#/$defs/B`: canonical (and base) `IRI: https://example.com/other.json` +Document location `/$defs/B`: +- canonical (and base) `IRI: https://example.com/other.json` - base IRI of enclosing (root.json) resource plus fragment: `https://example.com/root.json#/$defs/B` -`#/$defs/B/$defs/X`: base IRI: `https://example.com/other.json` +Document location `/$defs/B/$defs/X`: +- base IRI: `https://example.com/other.json` - base IRI of enclosing (root.json) resource plus fragment: `https://example.com/root.json#/$defs/B/$defs/X` -`#/$defs/B/$defs/Y`: canonical (and base) IRI: +Document location `/$defs/B/$defs/Y`: +- canonical (and base) IRI: `https://example.com/t/inner.json` - base IRI of enclosing (other.json) resource plus fragment: `https://example.com/other.json#/$defs/Y` - base IRI of enclosing (root.json) resource plus fragment: `https://example.com/root.json#/$defs/B/$defs/Y` -`#/$defs/C`: canonical (and base) IRI: +Document location `/$defs/C`: +- canonical (and base) IRI: `urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f` - base IRI of enclosing (root.json) resource plus fragment: `https://example.com/root.json#/$defs/C` From 4392b2598af53bcfaabe0fe19f1d466fafd698a4 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 12 Oct 2024 08:26:32 +1300 Subject: [PATCH 658/780] reorganize the $id section and remove redundancies --- jsonschema-core.md | 50 +++++++++++++++++++++++++--------------------- 1 file changed, 27 insertions(+), 23 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index 51e7a7df..13803955 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -895,8 +895,10 @@ by other parties. ### Base IRI, Anchors, and Dereferencing To differentiate between schemas in a vast ecosystem, schemas are identified by -[IRI](#rfc3987), and can embed references to other schemas by specifying their -IRI. +[absolute IRIs](#rfc3987) (without fragments), and can embed references to other +schemas by specifying their IRI. When comparing IRIs, implementations SHOULD +interpret them using the normalization procedures defined in +[RFC 3987](#rfc3987), section 5.3. Several keywords can accept a relative [IRI reference](#rfc3987), or a value used to construct a relative IRI reference. For these keywords, it is necessary @@ -904,32 +906,23 @@ to establish a base IRI in order to resolve the reference. #### The `$id` Keyword {#id-keyword} -The `$id` keyword identifies a schema resource with its [canonical](#rfc6596) -IRI. +The `$id` keyword identifies a schema resource. The value for this keyword MUST +be a string, and MUST represent a valid [IRI reference](#rfc3987) (without a +fragment). + +When the value of this keyword is resolved against the current base IRI, the +resulting absolute IRI then serves as the identifier for the schema resource and +as a base IRI for relative IRI references in keywords within that schema +resource, in accordance with [RFC 3987 section 6.5](#rfc3987) and +[RFC 3986 section 5.1.1](#rfc3986) regarding base IRIs embedded in content. Note that this IRI is an identifier and not necessarily a network locator. In the case of a network-addressable URL, a schema need not be downloadable from its canonical IRI. -If present, the value for this keyword MUST be a string, and MUST represent a -valid [IRI reference](#rfc3987). This IRI reference SHOULD be normalized per RFC -3987, section 5.3, and MUST resolve to an [absolute IRI](#rfc3987) (without a -fragment). - -The resulting absolute IRI serves as the base IRI for relative IRI references in -keywords within the schema resource, in accordance with [RFC 3987 section -6.5](#rfc3987) and [RFC 3986 section 5.1.1](#rfc3986) regarding base IRIs -embedded in content. - -The presence of `$id` in a subschema indicates that the subschema constitutes a -distinct schema resource within a single schema document. Furthermore, in -accordance with [RFC 3987 section 6.5](#rfc3987) and [RFC 3986 section -5.1.2](#rfc3986) regarding encapsulating entities, if an `$id` in a subschema is -a relative IRI reference, the base IRI for resolving that reference is the IRI -of the parent schema resource. Note that an `$id` consisting of an empty IRI or -of the empty fragment only will result in the embedded resource having the same -IRI as the encapsulating resource, which SHOULD be considered an error per -{{duplicate-iris}}. +Also note that an `$id` consisting of an empty IRI only will result in the +embedded resource having the same IRI as the encapsulating resource, which +SHOULD be considered an error per {{duplicate-iris}}. If no parent schema object explicitly identifies itself as a resource with `$id`, the base IRI is that of the entire document, as established by the steps @@ -1387,6 +1380,17 @@ behave correctly under implementations that attempt to use any reference target as a schema. However, this behavior is implementation-specific and MUST NOT be relied upon for interoperability. +A reference target under a keyword for which the value is known not to be a +schema results in undefined behavior in order to avoid burdening implementations +with the need to detect such targets.[^10] + +[^10]: These scenarios are analogous to fetching a schema over HTTP but +receiving a response with a Content-Type other than `application/schema+json`. +An implementation can certainly try to interpret it as a schema, but the origin +server offered no guarantee that it actually is any such thing. Therefore, +interpreting it as such has security implication and may produce unpredictable +results. + #### Failure to resolve references {#failed-refs} If for any reason a reference cannot be resolved, the evaluation MUST halt and From 43c8889e599345cd718c62a863d421f84e09fcd6 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 3 Oct 2024 08:24:33 +1300 Subject: [PATCH 659/780] Apply suggestions from code review Co-authored-by: Jason Desrosiers --- jsonschema-validation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-validation.md b/jsonschema-validation.md index 2768cb12..4a5ca2d1 100644 --- a/jsonschema-validation.md +++ b/jsonschema-validation.md @@ -444,7 +444,7 @@ representation of an IP address as follows: [RFC3986](#rfc3986). - *iri:* A string instance is valid against this attribute if it is a valid IRI, according to [RFC3987](#rfc3987). -- *IRI reference:* A string instance is valid against this attribute if it is a +- *iri-reference:* A string instance is valid against this attribute if it is a valid IRI Reference (either an IRI or a relative-reference), according to [RFC3987](#rfc3987). - *uuid:* A string instance is valid against this attribute if it is a valid @@ -952,7 +952,7 @@ schema form to the core spec - Restored "regex" format (removal was unintentional) - Added "date" and "time" formats, and reserved additional RFC 3339 format names - - I18N formats: "iri", "IRI reference", "idn-hostname", "idn-email" + - I18N formats: "iri", "iri-reference", "idn-hostname", "idn-email" - Clarify that "json-pointer" format means string encoding, not URI fragment - Fixed typo that inverted the meaning of `minimum` and `exclusiveMinimum` - Move format syntax references into Normative References From 39c0e186ed728eb325d7c414335f9bfb1c253bec Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 4 Oct 2024 09:56:02 +1300 Subject: [PATCH 660/780] Update jsonschema-core.md --- jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index 13803955..793159a1 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -2246,7 +2246,7 @@ determines the canonical nature of the resulting full IRI.[^18] and direct you to read the CREF located in {{#embedded}} for further comments. While the following IRIs do correctly indicate specific schemas, per the reasons -outlined in {{embedded}}, they are to be avoided: +outlined in {{embedded}}, they are to be avoided as they may not work in all implementations: Document location `/$defs/B`: - canonical (and base) `IRI: https://example.com/other.json` From 43c260ca8c79c87374e695241fcc04b9d7bfa893 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 12 Oct 2024 08:45:07 +1300 Subject: [PATCH 661/780] some more clarification on when implementations should normalize IRIs --- jsonschema-core.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index 793159a1..1f7adca7 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -895,9 +895,9 @@ by other parties. ### Base IRI, Anchors, and Dereferencing To differentiate between schemas in a vast ecosystem, schemas are identified by -[absolute IRIs](#rfc3987) (without fragments), and can embed references to other -schemas by specifying their IRI. When comparing IRIs, implementations SHOULD -interpret them using the normalization procedures defined in +[absolute IRIs](#rfc3987) (without fragments) and can embed references to other +schemas by specifying their respective IRIs. When comparing IRIs, +implementations SHOULD first follow the IRI normalization procedures defined in [RFC 3987](#rfc3987), section 5.3. Several keywords can accept a relative [IRI reference](#rfc3987), or a value From 878517d2052b419fdb2b053e4613f6592c7ac9a9 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 12 Oct 2024 08:46:32 +1300 Subject: [PATCH 662/780] more clarity --- jsonschema-core.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index 1f7adca7..cf855640 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -896,9 +896,9 @@ by other parties. To differentiate between schemas in a vast ecosystem, schemas are identified by [absolute IRIs](#rfc3987) (without fragments) and can embed references to other -schemas by specifying their respective IRIs. When comparing IRIs, -implementations SHOULD first follow the IRI normalization procedures defined in -[RFC 3987](#rfc3987), section 5.3. +schemas by specifying their respective IRIs. When comparing IRIs for the +purposes of resource identification, implementations SHOULD first follow the IRI +normalization procedures defined in [RFC 3987](#rfc3987), section 5.3. Several keywords can accept a relative [IRI reference](#rfc3987), or a value used to construct a relative IRI reference. For these keywords, it is necessary From 636aa373d6ab8a5bbda3ffb8ee31a6bf8cc3ad7d Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Mon, 14 Oct 2024 07:47:08 +1300 Subject: [PATCH 663/780] add that the base IRI is also a base for nested resources --- jsonschema-core.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index cf855640..3a7ad536 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -913,8 +913,9 @@ fragment). When the value of this keyword is resolved against the current base IRI, the resulting absolute IRI then serves as the identifier for the schema resource and as a base IRI for relative IRI references in keywords within that schema -resource, in accordance with [RFC 3987 section 6.5](#rfc3987) and -[RFC 3986 section 5.1.1](#rfc3986) regarding base IRIs embedded in content. +resource and for nested schema resources, in accordance with [RFC 3987 section +6.5](#rfc3987) and [RFC 3986 section 5.1.1](#rfc3986) regarding base IRIs +embedded in content. Note that this IRI is an identifier and not necessarily a network locator. In the case of a network-addressable URL, a schema need not be downloadable from From 8407415d21339caa51938b2a2a391f48f7ca2851 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 22 Oct 2024 07:58:31 +1300 Subject: [PATCH 664/780] Apply suggestions from code review Co-authored-by: Jason Desrosiers --- jsonschema-core.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index 3a7ad536..2dd06fb7 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -907,8 +907,8 @@ to establish a base IRI in order to resolve the reference. #### The `$id` Keyword {#id-keyword} The `$id` keyword identifies a schema resource. The value for this keyword MUST -be a string, and MUST represent a valid [IRI reference](#rfc3987) (without a -fragment). +be a string, and MUST represent a valid [IRI reference](#rfc3987) without a +fragment. When the value of this keyword is resolved against the current base IRI, the resulting absolute IRI then serves as the identifier for the schema resource and @@ -1262,7 +1262,7 @@ desired to identify the object containing the `$ref` in the second Due to the potential break in functionality described above, the behavior for using JSON Pointer fragments that point to or cross a resource boundary is -undefined. Schema authors SHOULD NOT rely on such IRIs, as using them may +undefined. Schema authors SHOULD NOT rely on such IRIs, as using them may reduce interoperability.[^8] [^8]: This is to avoid requiring implementations to keep track of a whole stack From cd52a3e3a5fc5de39ec3cb709173defc5f97614c Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 22 Oct 2024 18:43:18 +1300 Subject: [PATCH 665/780] fix incorrect anchor reference --- jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index 2dd06fb7..ce3c365c 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -2244,7 +2244,7 @@ rather, the base IRI used (as part of the full IRI with any fragment) is what determines the canonical nature of the resulting full IRI.[^18] [^18]: Multiple "canonical" IRIs? We Acknowledge this is potentially confusing, -and direct you to read the CREF located in {{#embedded}} for further comments. +and direct you to read the CREF located in {{embedded}} for further comments. While the following IRIs do correctly indicate specific schemas, per the reasons outlined in {{embedded}}, they are to be avoided as they may not work in all implementations: From 9a8ae1470629904f0f1d9f6be2c42e8400ea50ca Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 23 Oct 2024 15:21:43 +1300 Subject: [PATCH 666/780] update general summary about identifiers --- jsonschema-core.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index 2dd06fb7..57fda6aa 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -894,11 +894,11 @@ by other parties. ### Base IRI, Anchors, and Dereferencing -To differentiate between schemas in a vast ecosystem, schemas are identified by -[absolute IRIs](#rfc3987) (without fragments) and can embed references to other -schemas by specifying their respective IRIs. When comparing IRIs for the -purposes of resource identification, implementations SHOULD first follow the IRI -normalization procedures defined in [RFC 3987](#rfc3987), section 5.3. +To differentiate between schemas in a vast ecosystem, schema resources are +identified by [absolute IRIs](#rfc3987) (without fragments). These identifiers +are used to created references between schema resources. When comparing IRIs for +the purposes of resource identification, implementations SHOULD first follow the +IRI normalization procedures defined in [RFC 3987](#rfc3987), section 5.3. Several keywords can accept a relative [IRI reference](#rfc3987), or a value used to construct a relative IRI reference. For these keywords, it is necessary From 4d6fdb50e078620c6fb962f6c5444e936d0349b6 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 24 Oct 2024 07:43:58 +1300 Subject: [PATCH 667/780] Update jsonschema-core.md Co-authored-by: Jason Desrosiers --- jsonschema-core.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index e11c6dd9..660f5ccf 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -895,8 +895,8 @@ by other parties. ### Base IRI, Anchors, and Dereferencing To differentiate between schemas in a vast ecosystem, schema resources are -identified by [absolute IRIs](#rfc3987) (without fragments). These identifiers -are used to created references between schema resources. When comparing IRIs for +identified by [absolute IRIs](#rfc3987) (without fragments). These identifiers +are used to create references between schema resources. When comparing IRIs for the purposes of resource identification, implementations SHOULD first follow the IRI normalization procedures defined in [RFC 3987](#rfc3987), section 5.3. From 7f04f62d7ba534c5e9c28f5e301d32463bdcbfa1 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 25 Oct 2024 20:25:45 +1300 Subject: [PATCH 668/780] further edits for $id and referencing unknown location --- jsonschema-core.md | 31 +++++++++++++------------------ 1 file changed, 13 insertions(+), 18 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index 660f5ccf..a5cfa268 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -906,14 +906,14 @@ to establish a base IRI in order to resolve the reference. #### The `$id` Keyword {#id-keyword} -The `$id` keyword identifies a schema resource. The value for this keyword MUST -be a string, and MUST represent a valid [IRI reference](#rfc3987) without a -fragment. +An `$id` keyword in a schema or subschema identifies that schema or subschema as +a distinct schema resource. The value for this keyword MUST be a string, and +MUST represent a valid [IRI reference](#rfc3987) without a fragment. When the value of this keyword is resolved against the current base IRI, the resulting absolute IRI then serves as the identifier for the schema resource and as a base IRI for relative IRI references in keywords within that schema -resource and for nested schema resources, in accordance with [RFC 3987 section +resource and for embedded schema resources, in accordance with [RFC 3987 section 6.5](#rfc3987) and [RFC 3986 section 5.1.1](#rfc3986) regarding base IRIs embedded in content. @@ -1370,20 +1370,15 @@ recursive nesting like this; the behavior is undefined. #### References to Possible Non-Schemas {#non-schemas} Subschema objects (or booleans) are recognized by their use with known -applicator keywords or with location-reserving keywords such as -[`$defs`](#defs) that take one or more subschemas as a value. These keywords may -be `$defs` and the standard applicators from this document or -implementation-specific custom keywords. - -Note that single-level custom keywords with identical syntax and semantics to -`$defs` do not allow for any intervening `$id` keywords, and therefore will -behave correctly under implementations that attempt to use any reference target -as a schema. However, this behavior is implementation-specific and MUST NOT be -relied upon for interoperability. - -A reference target under a keyword for which the value is known not to be a -schema results in undefined behavior in order to avoid burdening implementations -with the need to detect such targets.[^10] +applicator keywords or with location-reserving keywords, such as +[`$defs`](#defs), that take one or more subschemas as a value. These keywords +include the standard applicators from this document or implementation-specific +custom keywords. + +A reference target under a keyword for which the value is not explicitly known +to be a schema results in undefined behavior. Implementations MAY support +references to these locations, however such behavior is not considered +interoperable and should not be relied upon.[^10] [^10]: These scenarios are analogous to fetching a schema over HTTP but receiving a response with a Content-Type other than `application/schema+json`. From c4953f1bf7f590209db92d6085ec4f8813cef332 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 25 Oct 2024 20:47:24 +1300 Subject: [PATCH 669/780] removed mention of indices from items; fix type in contains --- jsonschema-core.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index eebb910d..e7fc6493 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -1654,10 +1654,11 @@ The presence of this keyword affects the behaviors of [`items`](#items) and The value of `items` MUST be a valid JSON Schema. -This keyword applies its subschema to all instance elements at indices greater -than the length of the `prefixItems` array in the same schema object. If -`prefixItems` does not exist within the same schema object, `items` applies its -subschema to all instance array elements. +This keyword ignores elements in the instance array equal to the number of +subschemas found in the `prefixItems` array in the same schema object, starting +from the beginning of the instance array. It then applies its subschema to +remaining instance elements. If `prefixItems` does not exist within the same +schema object, `items` applies its subschema to all instance array elements. If the `items` subschema is applied to any positions within the instance array, it produces an annotation result of boolean true, indicating that all remaining @@ -1766,10 +1767,10 @@ Validation MUST always succeed against this keyword. The value of this keyword is used as its annotation result. Per {{default-behaviors}}, omitted keywords MUST NOT produce annotation results. -However, as described in the section for `contains`, the absence of this -keyword's annotation causes `contains` to assume a minimum value of 1. +However, as described in {{contains}}, the absence of this keyword's annotation +causes `contains` to assume a minimum value of 1. -##### `contains` +##### `contains` {#contains} The value of this keyword MUST be a valid JSON Schema. @@ -1777,7 +1778,7 @@ This keyword applies to array instances by applying its subschema to the array's elements. An instance is valid against `contains` if the number of elements that are valid -against its subschema is with the inclusive range of the minimum and (if any) +against its subschema is within the inclusive range of the minimum and (if any) maximum number of occurrences. The maximum number of occurrences is provided by the `maxContains` keyword From a8032298c8a96e7a5636bdddac0dafe06a7668ff Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 26 Oct 2024 15:07:16 +1300 Subject: [PATCH 670/780] added section about array indexing --- jsonschema-core.md | 35 +++++++++++++++++++++-------------- 1 file changed, 21 insertions(+), 14 deletions(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index e7fc6493..3c10e241 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -1633,6 +1633,12 @@ results. #### Keywords for Applying Subschemas to Arrays +##### Indexing Arrays {#array-index} + +When working with arrays and indices, JSON Schema uses zero-based indexing. This +aligns with both JSON's JavaScript heritage and its usage of JSON Pointer for +references and annotations. + ##### `prefixItems` The value of `prefixItems` MUST be a non-empty array of valid JSON Schemas. @@ -1657,8 +1663,13 @@ The value of `items` MUST be a valid JSON Schema. This keyword ignores elements in the instance array equal to the number of subschemas found in the `prefixItems` array in the same schema object, starting from the beginning of the instance array. It then applies its subschema to -remaining instance elements. If `prefixItems` does not exist within the same -schema object, `items` applies its subschema to all instance array elements. +remaining elements. + +If `prefixItems` contains more subschemas than the number of elements in the +instance array, `items` applies its subschema to no elements. + +If `prefixItems` does not exist within the same schema object, `items` applies +its subschema to all elements. If the `items` subschema is applied to any positions within the instance array, it produces an annotation result of boolean true, indicating that all remaining @@ -1666,11 +1677,6 @@ array elements have been evaluated against this keyword's subschema. Omitting this keyword has the same assertion behavior as an empty schema. -Implementations MAY choose to implement or optimize this keyword in another way -that produces the same effect, such as by directly checking for the presence and -size of a `prefixItems` array. Implementations that do not support annotation -collection MUST do so. - The presence of this keyword affects the behavior of [`unevaluatedItems`](#unevaluateditems). @@ -1712,7 +1718,8 @@ The annotation result of this keyword is the set of instance property names matched by at least one property under this keyword. The presence of this keyword affects the behaviors of -[`additionalProperties`(#additionalproperties) and [`unevaluatedProperties`](#unevaluatedproperties). +[`additionalProperties`(#additionalproperties) and +[`unevaluatedProperties`](#unevaluatedproperties). ##### `additionalProperties` {#additionalproperties} @@ -1789,12 +1796,12 @@ The minimum number of occurrences is provided by the `minContains` keyword within the same schema object as `contains`. If `minContains` is absent, the minimum number of occurrences MUST be 1. -This keyword produces an annotation value which is an array of the indices for -which this keyword validates successfully when applying its subschema, in -ascending order. The value MAY be a boolean `true` if the subschema validates -successfully when applied to every index of the instance. The annotation MUST be -present if the instance array to which this keyword's schema applies -is empty. +This keyword produces an annotation value which is an array of the zero-based +indices for which this keyword validates successfully when applying its +subschema, in ascending order. The value MAY be a boolean `true` if the +subschema validates successfully when applied to every index of the instance. +The annotation MUST be present if the instance array to which this keyword's +schema applies is empty. The presence of this keyword affects the behavior of [`unevaluatedItems`](#unevaluateditems). From b64d297fb1fbd61bfbb29bec379dfcbe5a55b49d Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 29 Oct 2024 21:19:55 +1300 Subject: [PATCH 671/780] add reference to 3986 sec. 5.1.2 --- jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/jsonschema-core.md b/jsonschema-core.md index a5cfa268..d9b6c2ef 100644 --- a/jsonschema-core.md +++ b/jsonschema-core.md @@ -915,7 +915,7 @@ resulting absolute IRI then serves as the identifier for the schema resource and as a base IRI for relative IRI references in keywords within that schema resource and for embedded schema resources, in accordance with [RFC 3987 section 6.5](#rfc3987) and [RFC 3986 section 5.1.1](#rfc3986) regarding base IRIs -embedded in content. +embedded in content and RFC 3986 section 5.1.2 regarding encapsulating entities. Note that this IRI is an identifier and not necessarily a network locator. In the case of a network-addressable URL, a schema need not be downloadable from From f6fbd1936dd8a12c5f511bd77baf222e4515356e Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Sun, 27 Oct 2024 21:45:42 -0700 Subject: [PATCH 672/780] Refactor spec build system --- .remarkrc-lint.js | 20 + README.md | 14 +- build/build.js | 199 --- eslint.config.js | 3 +- package-lock.json | 1411 +++++++++++++---- package.json | 27 +- {build => remark}/remark-code-titles.js | 0 {build => remark}/remark-headings.js | 0 {build => remark}/remark-reference-links.js | 0 {build => remark}/remark-table-of-contents.js | 0 specs/.remarkrc-build.js | 29 + specs/.remarkrc-specs.js | 42 + specs/.remarkrc.js | 10 + .../jsonschema-core.md | 6 +- .../jsonschema-validation.md | 182 +-- {meta => specs/meta}/applicator.json | 0 {meta => specs/meta}/content.json | 0 {meta => specs/meta}/core.json | 0 {meta => specs/meta}/format-annotation.json | 0 {meta => specs/meta}/format-assertion.json | 0 {meta => specs/meta}/meta-data.json | 0 {meta => specs/meta}/unevaluated.json | 0 {meta => specs/meta}/validation.json | 0 .../jsonschema-validation-output-machines.md | 13 +- {output => specs/output}/schema.json | 0 .../proposals}/propertyDependencies-adr.md | 0 .../proposals}/propertyDependencies.md | 23 +- .../proposals}/proposal-template.md | 4 +- .../proposals}/vocabularies-adr.md | 0 .../proposals}/vocabularies.md | 4 +- schema.json => specs/schema.json | 0 specs/spec.css | 94 ++ web/.gitkeep | 0 33 files changed, 1449 insertions(+), 632 deletions(-) create mode 100644 .remarkrc-lint.js delete mode 100644 build/build.js rename {build => remark}/remark-code-titles.js (100%) rename {build => remark}/remark-headings.js (100%) rename {build => remark}/remark-reference-links.js (100%) rename {build => remark}/remark-table-of-contents.js (100%) create mode 100644 specs/.remarkrc-build.js create mode 100644 specs/.remarkrc-specs.js create mode 100644 specs/.remarkrc.js rename jsonschema-core.md => specs/jsonschema-core.md (99%) rename jsonschema-validation.md => specs/jsonschema-validation.md (88%) rename {meta => specs/meta}/applicator.json (100%) rename {meta => specs/meta}/content.json (100%) rename {meta => specs/meta}/core.json (100%) rename {meta => specs/meta}/format-annotation.json (100%) rename {meta => specs/meta}/format-assertion.json (100%) rename {meta => specs/meta}/meta-data.json (100%) rename {meta => specs/meta}/unevaluated.json (100%) rename {meta => specs/meta}/validation.json (100%) rename {output => specs/output}/jsonschema-validation-output-machines.md (98%) rename {output => specs/output}/schema.json (100%) rename {proposals => specs/proposals}/propertyDependencies-adr.md (100%) rename {proposals => specs/proposals}/propertyDependencies.md (86%) rename {proposals => specs/proposals}/proposal-template.md (94%) rename {proposals => specs/proposals}/vocabularies-adr.md (100%) rename {proposals => specs/proposals}/vocabularies.md (98%) rename schema.json => specs/schema.json (100%) create mode 100644 specs/spec.css create mode 100644 web/.gitkeep diff --git a/.remarkrc-lint.js b/.remarkrc-lint.js new file mode 100644 index 00000000..f628bc82 --- /dev/null +++ b/.remarkrc-lint.js @@ -0,0 +1,20 @@ +import remarkValidateLinks from "remark-validate-links"; +import remarkPresetLintConsistent from "remark-preset-lint-consistent"; +import remarkPresetLintRecommended from "remark-preset-lint-recommended"; +import remarkPresetLintMarkdownStyleGuide from "remark-preset-lint-markdown-style-guide"; +import remarkLintListItemIndent from "remark-lint-list-item-indent"; +import remarkLintListItemSpacing from "remark-lint-list-item-spacing"; +import remarkLintNoFileNameMixedCase from "remark-lint-no-file-name-mixed-case"; + + +export default { + plugins: [ + remarkValidateLinks, + remarkPresetLintConsistent, + remarkPresetLintRecommended, + remarkPresetLintMarkdownStyleGuide, + [remarkLintListItemIndent, "one"], + [remarkLintListItemSpacing, { checkBlanks: true }], + [remarkLintNoFileNameMixedCase, false] + ] +}; diff --git a/README.md b/README.md index 9b5bb701..9f3e4a42 100644 --- a/README.md +++ b/README.md @@ -26,14 +26,16 @@ Labels are assigned based on [Sensible Github Labels](https://github.com/Releque ### Specification To build the spec files to HTML from the Markdown sources, run `npm run -build-all`. -You can also build each individually with `npm run build -- filename.md` -(Example: `npm run build -- jsonschema-core.md`). You can also use wildcards to -build multiple specs at the same time: `npm run build -- jsonschema-*.md`. The -HTML files will be available in the `web` folder. +build-all`. You can also build each individually with `npm run build -- +specs/filename.md` (Example: `npm run build -- specs/jsonschema-core.md`). You +can also use wildcards to build multiple specs at the same time: `npm run build +-- specs/jsonschema-*.md`. The HTML files will be available in the `web` folder. The spec is built using [Remark](https://remark.js.org/), a markdown engine with -good support for plugins and lots of existing plugins we can use. +good support for plugins and lots of existing plugins we can use. Remark also +has a [language server](https://github.com/remarkjs/remark-language-server) and +a [VSCode extension](https://github.com/remarkjs/vscode-remark) we can use to +get linting an link checking while developing the spec. #### Plugins The following is a not-necessarily-complete list of configured plugins and the diff --git a/build/build.js b/build/build.js deleted file mode 100644 index 81afbfc8..00000000 --- a/build/build.js +++ /dev/null @@ -1,199 +0,0 @@ -/* eslint-disable no-console */ -import dotenv from "dotenv"; -import { mkdir, readFile, writeFile } from "node:fs/promises"; -import { dirname, resolve, relative } from "node:path"; -import { argv, cwd } from "node:process"; -import { reporter } from "vfile-reporter"; -import { remark } from "remark"; -import remarkCodeTitles from "./remark-code-titles.js"; -import remarkFlexibleContainers from "remark-flexible-containers"; -import remarkGfm from "remark-gfm"; -import remarkHeadingId from "remark-heading-id"; -import remarkHeadings from "./remark-headings.js"; -import remarkPresetLintMarkdownStyleGuide from "remark-preset-lint-markdown-style-guide"; -import remarkLintMaximumHeadingLength from "remark-lint-maximum-heading-length"; -import remarkRehype from "remark-rehype"; -import remarkReferenceLinks from "./remark-reference-links.js"; -import remarkTableOfContents from "./remark-table-of-contents.js"; -import remarkTorchLight from "remark-torchlight"; -import remarkValidateLinks from "remark-validate-links"; -import rehypeStringify from "rehype-stringify"; - - -dotenv.config(); - -const build = async (filePath) => { - const md = await readFile(filePath, "utf-8"); - const file = await remark() - .use(remarkPresetLintMarkdownStyleGuide) - .use(remarkLintMaximumHeadingLength, false) - .use(remarkGfm) - .use(remarkHeadingId) - .use(remarkHeadings, { - startDepth: 2, - skip: [ - "Abstract", - "Status", - "Note to Readers", - "Table of Contents", - "Authors' Addresses", - "Champions", - "\\[.*\\]", - "draft-.*" - ] - }) - .use(remarkReferenceLinks) - .use(remarkFlexibleContainers) - .use(remarkCodeTitles) - .use(remarkTorchLight) - .use(remarkTableOfContents, { - startDepth: 2, - skip: [ - "Abstract", - "Note to Readers", - "Authors' Addresses", - "Champions", - "\\[.*\\]", - "draft-.*" - ] - }) - .use(remarkValidateLinks) - .use(remarkRehype) - .use(rehypeStringify) - .process(md); - - const rootPath = resolve(import.meta.dirname, ".."); - const outPath = resolve(rootPath, "web"); - const sourceRelativePath = relative(rootPath, filePath); - const outfile = resolve(outPath, sourceRelativePath).replace(/\.md$/, ".html"); - await mkdir(dirname(outfile), { recursive: true }); - await writeFile(outfile, ` - - - - - - - - ${file.toString()} - -`); - - console.error(reporter(file)); - - return file.messages.length; -}; - -(async function () { - const files = argv.slice(2); - if (files.length === 0) { - console.error("WARNING: No files built. Usage: 'npm run build -- filename.md'"); - } - - let messageCount = 0; - for (const filename of files) { - console.log(`Building: ${filename} ...`); - const filePath = resolve(cwd(), filename); - messageCount += await build(filePath); - console.log(""); - } - - if (messageCount > 0) { - process.exit(1); - } -}()); diff --git a/eslint.config.js b/eslint.config.js index 7cc18992..4d6e6a80 100644 --- a/eslint.config.js +++ b/eslint.config.js @@ -3,6 +3,7 @@ import globals from "globals"; import stylistic from "@stylistic/eslint-plugin"; import importPlugin from "eslint-plugin-import"; + export default [ js.configs.recommended, importPlugin.flatConfigs.recommended, @@ -34,7 +35,7 @@ export default [ // Imports "import/extensions": ["error", "ignorePackages"], - "import/newline-after-import": ["error", { count: 2, exactCount: false, considerComments: true }], // Doesn't respect @import + "import/newline-after-import": ["error", { count: 2, exactCount: false, considerComments: true }], // Stylistic "@stylistic/yield-star-spacing": ["error", "after"], diff --git a/package-lock.json b/package-lock.json index 6840c445..fe249cf3 100644 --- a/package-lock.json +++ b/package-lock.json @@ -8,34 +8,34 @@ "name": "@json-schema-org/json-schema-spec", "version": "1.0.0", "license": "MIT", - "dependencies": { + "devDependencies": { "@stylistic/eslint-plugin": "^2.9.0", + "dotenv": "^16.4.5", + "eslint": "^9.13.0", + "eslint-import-resolver-node": "^0.3.9", + "eslint-plugin-import": "^2.31.0", "mdast-builder": "^1.1.1", "mdast-util-find-and-replace": "^3.0.1", "mdast-util-to-string": "^4.0.0", + "rehype-document": "^7.0.3", "rehype-stringify": "^10.0.1", - "remark": "^15.0.1", + "remark-cli": "^12.0.1", "remark-flexible-containers": "^1.2.1", "remark-gfm": "^4.0.0", "remark-heading-id": "^1.0.1", + "remark-preset-lint-consistent": "^6.0.0", "remark-preset-lint-markdown-style-guide": "^6.0.0", + "remark-preset-lint-recommended": "^7.0.0", "remark-rehype": "^11.1.1", "remark-torchlight": "^0.0.5", - "remark-validate-links": "^13.0.1", - "unist-builder": "^4.0.0", - "vfile-reporter": "^8.1.1" - }, - "devDependencies": { - "dotenv": "^16.4.5", - "eslint": "^9.12.0", - "eslint-import-resolver-node": "^0.3.9", - "eslint-plugin-import": "^2.31.0" + "remark-validate-links": "^13.0.1" } }, "node_modules/@babel/code-frame": { "version": "7.25.7", "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.25.7.tgz", "integrity": "sha512-0xZJFNE5XMpENsgfHYTw8FbX4kv53mFLn2i3XPoq69LyhYSCBJtitaHx9QnsVTrsogI4Z3+HtEfZ2/GFPOtf5g==", + "dev": true, "license": "MIT", "dependencies": { "@babel/highlight": "^7.25.7", @@ -49,6 +49,7 @@ "version": "7.25.7", "resolved": "https://registry.npmjs.org/@babel/helper-validator-identifier/-/helper-validator-identifier-7.25.7.tgz", "integrity": "sha512-AM6TzwYqGChO45oiuPqwL2t20/HdMC1rTPAesnBCgPCSF1x3oN9MVUwQV2iyz4xqWrctwK5RNC8LV22kaQCNYg==", + "dev": true, "license": "MIT", "engines": { "node": ">=6.9.0" @@ -58,6 +59,7 @@ "version": "7.25.7", "resolved": "https://registry.npmjs.org/@babel/highlight/-/highlight-7.25.7.tgz", "integrity": "sha512-iYyACpW3iW8Fw+ZybQK+drQre+ns/tKpXbNESfrhNnPLIklLbXr7MYJ6gPEd0iETGLOK+SxMjVvKb/ffmk+FEw==", + "dev": true, "license": "MIT", "dependencies": { "@babel/helper-validator-identifier": "^7.25.7", @@ -73,6 +75,7 @@ "version": "3.2.1", "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-3.2.1.tgz", "integrity": "sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA==", + "dev": true, "license": "MIT", "dependencies": { "color-convert": "^1.9.0" @@ -85,6 +88,7 @@ "version": "2.4.2", "resolved": "https://registry.npmjs.org/chalk/-/chalk-2.4.2.tgz", "integrity": "sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==", + "dev": true, "license": "MIT", "dependencies": { "ansi-styles": "^3.2.1", @@ -99,6 +103,7 @@ "version": "1.9.3", "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-1.9.3.tgz", "integrity": "sha512-QfAUtd+vFdAtFQcC8CCyYt1fYWxSqAiK2cSD6zDB8N3cpsEBAvRxp9zOGg6G/SHHJYAT88/az/IuDGALsNVbGg==", + "dev": true, "license": "MIT", "dependencies": { "color-name": "1.1.3" @@ -108,12 +113,14 @@ "version": "1.1.3", "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.3.tgz", "integrity": "sha512-72fSenhMw2HZMTVHeCA9KCmpEIbzWiQsjN+BHcBbS9vr1mtt+vJjPdksIBNUmKAW8TFUDPJK5SUU3QhE9NEXDw==", + "dev": true, "license": "MIT" }, "node_modules/@babel/highlight/node_modules/escape-string-regexp": { "version": "1.0.5", "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz", "integrity": "sha512-vbRorB5FUQWvla16U8R/qgaFIya2qGzwDrNmCZuYKrbdSUMG6I1ZCGQRefkRVhuOkIGVne7BQ35DSfo1qvJqFg==", + "dev": true, "license": "MIT", "engines": { "node": ">=0.8.0" @@ -123,6 +130,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-3.0.0.tgz", "integrity": "sha512-sKJf1+ceQBr4SMkvQnBDNDtf4TXpVhVGateu0t918bl30FnbE2m4vNLX+VWe/dpjlb+HugGYzW7uQXH98HPEYw==", + "dev": true, "license": "MIT", "engines": { "node": ">=4" @@ -132,6 +140,7 @@ "version": "5.5.0", "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-5.5.0.tgz", "integrity": "sha512-QjVjwdXIt408MIiAqCX4oUKsgU2EqAGzs2Ppkm4aQYbjm+ZEWEcW4SfFNTr4uMNZma0ey4f5lgLrkB0aX0QMow==", + "dev": true, "license": "MIT", "dependencies": { "has-flag": "^3.0.0" @@ -144,6 +153,7 @@ "version": "4.4.0", "resolved": "https://registry.npmjs.org/@eslint-community/eslint-utils/-/eslint-utils-4.4.0.tgz", "integrity": "sha512-1/sA4dwrzBAyeUoQ6oxahHKmrZvsnLCg4RfxW3ZFGGmQkSNQPFNLV9CUEFQP1x9EYXHTo5p6xdhZM1Ne9p/AfA==", + "dev": true, "license": "MIT", "dependencies": { "eslint-visitor-keys": "^3.3.0" @@ -159,6 +169,7 @@ "version": "3.4.3", "resolved": "https://registry.npmjs.org/eslint-visitor-keys/-/eslint-visitor-keys-3.4.3.tgz", "integrity": "sha512-wpc+LXeiyiisxPlEkUzU6svyS1frIO3Mgxj1fdy7Pm8Ygzguax2N3Fa/D/ag1WqbOprdI+uY6wMUl8/a2G+iag==", + "dev": true, "license": "Apache-2.0", "engines": { "node": "^12.22.0 || ^14.17.0 || >=16.0.0" @@ -171,6 +182,7 @@ "version": "4.11.1", "resolved": "https://registry.npmjs.org/@eslint-community/regexpp/-/regexpp-4.11.1.tgz", "integrity": "sha512-m4DVN9ZqskZoLU5GlWZadwDnYo3vAEydiUayB9widCl9ffWx2IvPnp6n3on5rJmziJSw9Bv+Z3ChDVdMwXCY8Q==", + "dev": true, "license": "MIT", "engines": { "node": "^12.0.0 || ^14.0.0 || >=16.0.0" @@ -180,6 +192,7 @@ "version": "0.18.0", "resolved": "https://registry.npmjs.org/@eslint/config-array/-/config-array-0.18.0.tgz", "integrity": "sha512-fTxvnS1sRMu3+JjXwJG0j/i4RT9u4qJ+lqS/yCGap4lH4zZGzQ7tu+xZqQmcMZq5OBZDL4QRxQzRjkWcGt8IVw==", + "dev": true, "license": "Apache-2.0", "dependencies": { "@eslint/object-schema": "^2.1.4", @@ -191,9 +204,10 @@ } }, "node_modules/@eslint/core": { - "version": "0.6.0", - "resolved": "https://registry.npmjs.org/@eslint/core/-/core-0.6.0.tgz", - "integrity": "sha512-8I2Q8ykA4J0x0o7cg67FPVnehcqWTBehu/lmY+bolPFHGjh49YzGBMXTvpqVgEbBdvNCSxj6iFgiIyHzf03lzg==", + "version": "0.7.0", + "resolved": "https://registry.npmjs.org/@eslint/core/-/core-0.7.0.tgz", + "integrity": "sha512-xp5Jirz5DyPYlPiKat8jaq0EmYvDXKKpzTbxXMpT9eqlRJkRKIz9AGMdlvYjih+im+QlhWrpvVjl8IPC/lHlUw==", + "dev": true, "license": "Apache-2.0", "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -203,6 +217,7 @@ "version": "3.1.0", "resolved": "https://registry.npmjs.org/@eslint/eslintrc/-/eslintrc-3.1.0.tgz", "integrity": "sha512-4Bfj15dVJdoy3RfZmmo86RK1Fwzn6SstsvK9JS+BaVKqC6QQQQyXekNaC+g+LKNgkQ+2VhGAzm6hO40AhMR3zQ==", + "dev": true, "license": "MIT", "dependencies": { "ajv": "^6.12.4", @@ -223,9 +238,10 @@ } }, "node_modules/@eslint/js": { - "version": "9.12.0", - "resolved": "https://registry.npmjs.org/@eslint/js/-/js-9.12.0.tgz", - "integrity": "sha512-eohesHH8WFRUprDNyEREgqP6beG6htMeUYeCpkEgBCieCMme5r9zFWjzAJp//9S+Kub4rqE+jXe9Cp1a7IYIIA==", + "version": "9.13.0", + "resolved": "https://registry.npmjs.org/@eslint/js/-/js-9.13.0.tgz", + "integrity": "sha512-IFLyoY4d72Z5y/6o/BazFBezupzI/taV8sGumxTAVw3lXG9A6md1Dc34T9s1FoD/an9pJH8RHbAxsaEbBed9lA==", + "dev": true, "license": "MIT", "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -235,6 +251,7 @@ "version": "2.1.4", "resolved": "https://registry.npmjs.org/@eslint/object-schema/-/object-schema-2.1.4.tgz", "integrity": "sha512-BsWiH1yFGjXXS2yvrf5LyuoSIIbPrGUWob917o+BTKuZ7qJdxX8aJLRxs1fS9n6r7vESrq1OUqb68dANcFXuQQ==", + "dev": true, "license": "Apache-2.0", "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -244,6 +261,7 @@ "version": "0.2.0", "resolved": "https://registry.npmjs.org/@eslint/plugin-kit/-/plugin-kit-0.2.0.tgz", "integrity": "sha512-vH9PiIMMwvhCx31Af3HiGzsVNULDbyVkHXwlemn/B0TFj/00ho3y55efXrUZTfQipxoHC5u4xq6zblww1zm1Ig==", + "dev": true, "license": "Apache-2.0", "dependencies": { "levn": "^0.4.1" @@ -256,6 +274,7 @@ "version": "0.19.0", "resolved": "https://registry.npmjs.org/@humanfs/core/-/core-0.19.0.tgz", "integrity": "sha512-2cbWIHbZVEweE853g8jymffCA+NCMiuqeECeBBLm8dg2oFdjuGJhgN4UAbI+6v0CKbbhvtXA4qV8YR5Ji86nmw==", + "dev": true, "license": "Apache-2.0", "engines": { "node": ">=18.18.0" @@ -265,6 +284,7 @@ "version": "0.16.5", "resolved": "https://registry.npmjs.org/@humanfs/node/-/node-0.16.5.tgz", "integrity": "sha512-KSPA4umqSG4LHYRodq31VDwKAvaTF4xmVlzM8Aeh4PlU1JQ3IG0wiA8C25d3RQ9nJyM3mBHyI53K06VVL/oFFg==", + "dev": true, "license": "Apache-2.0", "dependencies": { "@humanfs/core": "^0.19.0", @@ -278,6 +298,7 @@ "version": "1.0.1", "resolved": "https://registry.npmjs.org/@humanwhocodes/module-importer/-/module-importer-1.0.1.tgz", "integrity": "sha512-bxveV4V8v5Yb4ncFTT3rPSgZBOpCkjfK0y4oVVVJwIuDVBRMDXrPyXRL988i5ap9m9bnyEEjWfm5WkBmtffLfA==", + "dev": true, "license": "Apache-2.0", "engines": { "node": ">=12.22" @@ -291,6 +312,7 @@ "version": "0.3.1", "resolved": "https://registry.npmjs.org/@humanwhocodes/retry/-/retry-0.3.1.tgz", "integrity": "sha512-JBxkERygn7Bv/GbN5Rv8Ul6LVknS+5Bp6RgDC/O8gEBU/yeH5Ui5C/OlWrTb6qct7LjjfT6Re2NxB0ln0yYybA==", + "dev": true, "license": "Apache-2.0", "engines": { "node": ">=18.18" @@ -304,6 +326,7 @@ "version": "8.0.2", "resolved": "https://registry.npmjs.org/@isaacs/cliui/-/cliui-8.0.2.tgz", "integrity": "sha512-O8jcjabXaleOG9DQ0+ARXWZBTfnP4WNAqzuiJK7ll44AmxGKv/J2M4TPjxjY3znBCfvBXFzucm1twdyFybFqEA==", + "dev": true, "license": "ISC", "dependencies": { "string-width": "^5.1.2", @@ -321,6 +344,7 @@ "version": "6.1.0", "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.1.0.tgz", "integrity": "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA==", + "dev": true, "license": "MIT", "engines": { "node": ">=12" @@ -333,6 +357,7 @@ "version": "6.2.1", "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-6.2.1.tgz", "integrity": "sha512-bN798gFfQX+viw3R7yrGWRqnrN2oRkEkUjjl4JNn4E8GxxbjtG3FbrEIIY3l8/hrwUwIeCZvi4QuOTP4MErVug==", + "dev": true, "license": "MIT", "engines": { "node": ">=12" @@ -345,12 +370,14 @@ "version": "9.2.2", "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-9.2.2.tgz", "integrity": "sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg==", + "dev": true, "license": "MIT" }, "node_modules/@isaacs/cliui/node_modules/string-width": { "version": "5.1.2", "resolved": "https://registry.npmjs.org/string-width/-/string-width-5.1.2.tgz", "integrity": "sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==", + "dev": true, "license": "MIT", "dependencies": { "eastasianwidth": "^0.2.0", @@ -368,6 +395,7 @@ "version": "7.1.0", "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz", "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==", + "dev": true, "license": "MIT", "dependencies": { "ansi-regex": "^6.0.1" @@ -383,6 +411,7 @@ "version": "8.1.0", "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-8.1.0.tgz", "integrity": "sha512-si7QWI6zUMq56bESFvagtmzMdGOtoxfR+Sez11Mobfc7tm+VkUckk9bW2UeffTGVUbOksxmSw0AA2gs8g71NCQ==", + "dev": true, "license": "MIT", "dependencies": { "ansi-styles": "^6.1.0", @@ -400,6 +429,7 @@ "version": "2.1.5", "resolved": "https://registry.npmjs.org/@nodelib/fs.scandir/-/fs.scandir-2.1.5.tgz", "integrity": "sha512-vq24Bq3ym5HEQm2NKCr3yXDwjc7vTsEThRDnkp2DK9p1uqLR+DHurm/NOTo0KG7HYHU7eppKZj3MyqYuMBf62g==", + "dev": true, "license": "MIT", "dependencies": { "@nodelib/fs.stat": "2.0.5", @@ -413,6 +443,7 @@ "version": "2.0.5", "resolved": "https://registry.npmjs.org/@nodelib/fs.stat/-/fs.stat-2.0.5.tgz", "integrity": "sha512-RkhPPp2zrqDAQA/2jNhnztcPAlv64XdhIp7a7454A5ovI7Bukxgt7MX7udwAu3zg1DcpPU0rz3VV1SeaqvY4+A==", + "dev": true, "license": "MIT", "engines": { "node": ">= 8" @@ -422,6 +453,7 @@ "version": "1.2.8", "resolved": "https://registry.npmjs.org/@nodelib/fs.walk/-/fs.walk-1.2.8.tgz", "integrity": "sha512-oGB+UxlgWcgQkgwo8GcEGwemoTFt3FIO9ababBmaGwXIoBKZ+GTy0pP185beGg7Llih/NSHSV2XAs1lnznocSg==", + "dev": true, "license": "MIT", "dependencies": { "@nodelib/fs.scandir": "2.1.5", @@ -435,6 +467,7 @@ "version": "8.3.4", "resolved": "https://registry.npmjs.org/@npmcli/config/-/config-8.3.4.tgz", "integrity": "sha512-01rtHedemDNhUXdicU7s+QYz/3JyV5Naj84cvdXGH4mgCdL+agmSYaLF4LUG4vMCLzhBO8YtS0gPpH1FGvbgAw==", + "dev": true, "license": "ISC", "dependencies": { "@npmcli/map-workspaces": "^3.0.2", @@ -454,6 +487,7 @@ "version": "7.6.3", "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", + "dev": true, "license": "ISC", "bin": { "semver": "bin/semver.js" @@ -466,6 +500,7 @@ "version": "5.0.8", "resolved": "https://registry.npmjs.org/@npmcli/git/-/git-5.0.8.tgz", "integrity": "sha512-liASfw5cqhjNW9UFd+ruwwdEf/lbOAQjLL2XY2dFW/bkJheXDYZgOyul/4gVvEV4BWkTXjYGmDqMw9uegdbJNQ==", + "dev": true, "license": "ISC", "dependencies": { "@npmcli/promise-spawn": "^7.0.0", @@ -486,6 +521,7 @@ "version": "3.1.1", "resolved": "https://registry.npmjs.org/isexe/-/isexe-3.1.1.tgz", "integrity": "sha512-LpB/54B+/2J5hqQ7imZHfdU31OlgQqx7ZicVlkm9kzg9/w8GKLEcFfJl/t7DCEDueOyBAD6zCCwTO6Fzs0NoEQ==", + "dev": true, "license": "ISC", "engines": { "node": ">=16" @@ -495,6 +531,7 @@ "version": "7.6.3", "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", + "dev": true, "license": "ISC", "bin": { "semver": "bin/semver.js" @@ -507,6 +544,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/which/-/which-4.0.0.tgz", "integrity": "sha512-GlaYyEb07DPxYCKhKzplCWBJtvxZcZMrL+4UkrTSJHHPyZU4mYYTv3qaOe77H7EODLSSopAUFAc6W8U4yqvscg==", + "dev": true, "license": "ISC", "dependencies": { "isexe": "^3.1.1" @@ -522,6 +560,7 @@ "version": "3.0.6", "resolved": "https://registry.npmjs.org/@npmcli/map-workspaces/-/map-workspaces-3.0.6.tgz", "integrity": "sha512-tkYs0OYnzQm6iIRdfy+LcLBjcKuQCeE5YLb8KnrIlutJfheNaPvPpgoFEyEFgbjzl5PLZ3IA/BWAwRU0eHuQDA==", + "dev": true, "license": "ISC", "dependencies": { "@npmcli/name-from-folder": "^2.0.0", @@ -537,6 +576,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", + "dev": true, "license": "MIT", "dependencies": { "balanced-match": "^1.0.0" @@ -546,6 +586,7 @@ "version": "10.4.5", "resolved": "https://registry.npmjs.org/glob/-/glob-10.4.5.tgz", "integrity": "sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==", + "dev": true, "license": "ISC", "dependencies": { "foreground-child": "^3.1.0", @@ -566,6 +607,7 @@ "version": "9.0.5", "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.5.tgz", "integrity": "sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==", + "dev": true, "license": "ISC", "dependencies": { "brace-expansion": "^2.0.1" @@ -581,6 +623,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/@npmcli/name-from-folder/-/name-from-folder-2.0.0.tgz", "integrity": "sha512-pwK+BfEBZJbKdNYpHHRTNBwBoqrN/iIMO0AiGvYsp3Hoaq0WbgGSWQR6SCldZovoDpY3yje5lkFUe6gsDgJ2vg==", + "dev": true, "license": "ISC", "engines": { "node": "^14.17.0 || ^16.13.0 || >=18.0.0" @@ -590,6 +633,7 @@ "version": "5.2.1", "resolved": "https://registry.npmjs.org/@npmcli/package-json/-/package-json-5.2.1.tgz", "integrity": "sha512-f7zYC6kQautXHvNbLEWgD/uGu1+xCn9izgqBfgItWSx22U0ZDekxN08A1vM8cTxj/cRVe0Q94Ode+tdoYmIOOQ==", + "dev": true, "license": "ISC", "dependencies": { "@npmcli/git": "^5.0.0", @@ -608,6 +652,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", + "dev": true, "license": "MIT", "dependencies": { "balanced-match": "^1.0.0" @@ -617,6 +662,7 @@ "version": "10.4.5", "resolved": "https://registry.npmjs.org/glob/-/glob-10.4.5.tgz", "integrity": "sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==", + "dev": true, "license": "ISC", "dependencies": { "foreground-child": "^3.1.0", @@ -637,6 +683,7 @@ "version": "9.0.5", "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.5.tgz", "integrity": "sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==", + "dev": true, "license": "ISC", "dependencies": { "brace-expansion": "^2.0.1" @@ -652,6 +699,7 @@ "version": "7.6.3", "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", + "dev": true, "license": "ISC", "bin": { "semver": "bin/semver.js" @@ -664,6 +712,7 @@ "version": "7.0.2", "resolved": "https://registry.npmjs.org/@npmcli/promise-spawn/-/promise-spawn-7.0.2.tgz", "integrity": "sha512-xhfYPXoV5Dy4UkY0D+v2KkwvnDfiA/8Mt3sWCGI/hM03NsYIH8ZaG6QzS9x7pje5vHZBZJ2v6VRFVTWACnqcmQ==", + "dev": true, "license": "ISC", "dependencies": { "which": "^4.0.0" @@ -676,6 +725,7 @@ "version": "3.1.1", "resolved": "https://registry.npmjs.org/isexe/-/isexe-3.1.1.tgz", "integrity": "sha512-LpB/54B+/2J5hqQ7imZHfdU31OlgQqx7ZicVlkm9kzg9/w8GKLEcFfJl/t7DCEDueOyBAD6zCCwTO6Fzs0NoEQ==", + "dev": true, "license": "ISC", "engines": { "node": ">=16" @@ -685,6 +735,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/which/-/which-4.0.0.tgz", "integrity": "sha512-GlaYyEb07DPxYCKhKzplCWBJtvxZcZMrL+4UkrTSJHHPyZU4mYYTv3qaOe77H7EODLSSopAUFAc6W8U4yqvscg==", + "dev": true, "license": "ISC", "dependencies": { "isexe": "^3.1.1" @@ -700,6 +751,7 @@ "version": "0.11.0", "resolved": "https://registry.npmjs.org/@pkgjs/parseargs/-/parseargs-0.11.0.tgz", "integrity": "sha512-+1VkjdD0QBLPodGrJUeqarH8VAIvQODIbwh9XpP5Syisf7YoQgsJKPNFoqqLQlu+VQ/tVSshMR6loPMn8U+dPg==", + "dev": true, "license": "MIT", "optional": true, "engines": { @@ -717,6 +769,7 @@ "version": "2.9.0", "resolved": "https://registry.npmjs.org/@stylistic/eslint-plugin/-/eslint-plugin-2.9.0.tgz", "integrity": "sha512-OrDyFAYjBT61122MIY1a3SfEgy3YCMgt2vL4eoPmvTwDBwyQhAXurxNQznlRD/jESNfYWfID8Ej+31LljvF7Xg==", + "dev": true, "license": "MIT", "dependencies": { "@typescript-eslint/utils": "^8.8.0", @@ -736,6 +789,7 @@ "version": "4.0.2", "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-4.0.2.tgz", "integrity": "sha512-M7BAV6Rlcy5u+m6oPhAPFgJTzAioX/6B0DxyvDlo9l8+T3nLKbrczg2WLUyzd45L8RqfUMyGPzekbMvX2Ldkwg==", + "dev": true, "license": "MIT", "engines": { "node": ">=12" @@ -748,6 +802,7 @@ "version": "0.1.7", "resolved": "https://registry.npmjs.org/@torchlight-api/torchlight-cli/-/torchlight-cli-0.1.7.tgz", "integrity": "sha512-sHph49Nx/VfzwDsb43v6AQIDZQa/YQ1LtGKTmN/rEBJoW0ctMXUQUJ1c75rNQ/1n2rYLbQLf7s008/jgLvkEDg==", + "dev": true, "license": "MIT", "dependencies": { "axios": "^0.21.1", @@ -769,6 +824,7 @@ "version": "2.0.3", "resolved": "https://registry.npmjs.org/@types/concat-stream/-/concat-stream-2.0.3.tgz", "integrity": "sha512-3qe4oQAPNwVNwK4C9c8u+VJqv9kez+2MR4qJpoPFfXtgxxif1QbFusvXzK0/Wra2VX07smostI2VMmJNSpZjuQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/node": "*" @@ -778,6 +834,7 @@ "version": "4.1.12", "resolved": "https://registry.npmjs.org/@types/debug/-/debug-4.1.12.tgz", "integrity": "sha512-vIChWdVG3LG1SMxEvI/AK+FWJthlrqlTu7fbrlywTkkaONwk/UAGaULXRlf8vkzFBLVm0zkMdCquhL5aOjhXPQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/ms": "*" @@ -787,12 +844,14 @@ "version": "1.0.6", "resolved": "https://registry.npmjs.org/@types/estree/-/estree-1.0.6.tgz", "integrity": "sha512-AYnb1nQyY49te+VRAVgmzfcgjYS91mY5P0TKUDCLEM+gNnA+3T6rWITXRLYCpahpqSQbN5cE+gHpnPyXjHWxcw==", + "dev": true, "license": "MIT" }, "node_modules/@types/estree-jsx": { "version": "1.0.5", "resolved": "https://registry.npmjs.org/@types/estree-jsx/-/estree-jsx-1.0.5.tgz", "integrity": "sha512-52CcUVNFyfb1A2ALocQw/Dd1BQFNmSdkuC3BkZ6iqhdMfQz7JWOFRuJFloOzjk+6WijU56m9oKXFAXc7o3Towg==", + "dev": true, "license": "MIT", "dependencies": { "@types/estree": "*" @@ -802,6 +861,7 @@ "version": "3.0.4", "resolved": "https://registry.npmjs.org/@types/hast/-/hast-3.0.4.tgz", "integrity": "sha512-WPs+bbQw5aCj+x6laNGWLH3wviHtoCv/P3+otBhbOhJgG8qtpdAMlTCxLtsTWA7LH1Oh/bFCHsBn0TPS5m30EQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "*" @@ -811,18 +871,21 @@ "version": "3.0.5", "resolved": "https://registry.npmjs.org/@types/hosted-git-info/-/hosted-git-info-3.0.5.tgz", "integrity": "sha512-Dmngh7U003cOHPhKGyA7LWqrnvcTyILNgNPmNCxlx7j8MIi54iBliiT8XqVLIQ3GchoOjVAyBzNJVyuaJjqokg==", + "dev": true, "license": "MIT" }, "node_modules/@types/is-empty": { "version": "1.2.3", "resolved": "https://registry.npmjs.org/@types/is-empty/-/is-empty-1.2.3.tgz", "integrity": "sha512-4J1l5d79hoIvsrKh5VUKVRA1aIdsOb10Hu5j3J2VfP/msDnfTdGPmNp2E1Wg+vs97Bktzo+MZePFFXSGoykYJw==", + "dev": true, "license": "MIT" }, "node_modules/@types/json-schema": { "version": "7.0.15", "resolved": "https://registry.npmjs.org/@types/json-schema/-/json-schema-7.0.15.tgz", "integrity": "sha512-5+fP8P8MFNC+AyZCDxrB2pkZFPGzqQWUzpSeuuVLvm8VMcorNYavBqoFcxK8bQz4Qsbn4oUEEem4wDLfcysGHA==", + "dev": true, "license": "MIT" }, "node_modules/@types/json5": { @@ -836,6 +899,7 @@ "version": "4.0.4", "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-4.0.4.tgz", "integrity": "sha512-kGaNbPh1k7AFzgpud/gMdvIm5xuECykRR+JnWKQno9TAXVa6WIVCGTPvYGekIDL4uwCZQSYbUxNBSb1aUo79oA==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "*" @@ -845,12 +909,14 @@ "version": "0.7.34", "resolved": "https://registry.npmjs.org/@types/ms/-/ms-0.7.34.tgz", "integrity": "sha512-nG96G3Wp6acyAgJqGasjODb+acrI7KltPiRxzHPXnP3NgI28bpQDRv53olbqGXbfcgF5aiiHmO3xpwEpS5Ld9g==", + "dev": true, "license": "MIT" }, "node_modules/@types/node": { "version": "20.16.11", "resolved": "https://registry.npmjs.org/@types/node/-/node-20.16.11.tgz", "integrity": "sha512-y+cTCACu92FyA5fgQSAI8A1H429g7aSK2HsO7K4XYUWc4dY5IUz55JSDIYT6/VsOLfGy8vmvQYC2hfb0iF16Uw==", + "dev": true, "license": "MIT", "dependencies": { "undici-types": "~6.19.2" @@ -860,18 +926,28 @@ "version": "8.1.3", "resolved": "https://registry.npmjs.org/@types/supports-color/-/supports-color-8.1.3.tgz", "integrity": "sha512-Hy6UMpxhE3j1tLpl27exp1XqHD7n8chAiNPzWfz16LPZoMMoSc4dzLl6w9qijkEb/r5O1ozdu1CWGA2L83ZeZg==", + "dev": true, + "license": "MIT" + }, + "node_modules/@types/text-table": { + "version": "0.2.5", + "resolved": "https://registry.npmjs.org/@types/text-table/-/text-table-0.2.5.tgz", + "integrity": "sha512-hcZhlNvMkQG/k1vcZ6yHOl6WAYftQ2MLfTHcYRZ2xYZFD8tGVnE3qFV0lj1smQeDSR7/yY0PyuUalauf33bJeA==", + "dev": true, "license": "MIT" }, "node_modules/@types/unist": { "version": "2.0.11", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-2.0.11.tgz", "integrity": "sha512-CmBKiL6NNo/OqgmMn95Fk9Whlp2mtvIv+KNpQKN2F4SjvrEesubTRWGYSg+BnWZOnlCaSTU1sMpsBOzgbYhnsA==", + "dev": true, "license": "MIT" }, "node_modules/@typescript-eslint/scope-manager": { "version": "8.9.0", "resolved": "https://registry.npmjs.org/@typescript-eslint/scope-manager/-/scope-manager-8.9.0.tgz", "integrity": "sha512-bZu9bUud9ym1cabmOYH9S6TnbWRzpklVmwqICeOulTCZ9ue2/pczWzQvt/cGj2r2o1RdKoZbuEMalJJSYw3pHQ==", + "dev": true, "license": "MIT", "dependencies": { "@typescript-eslint/types": "8.9.0", @@ -889,6 +965,7 @@ "version": "8.9.0", "resolved": "https://registry.npmjs.org/@typescript-eslint/types/-/types-8.9.0.tgz", "integrity": "sha512-SjgkvdYyt1FAPhU9c6FiYCXrldwYYlIQLkuc+LfAhCna6ggp96ACncdtlbn8FmnG72tUkXclrDExOpEYf1nfJQ==", + "dev": true, "license": "MIT", "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -902,6 +979,7 @@ "version": "8.9.0", "resolved": "https://registry.npmjs.org/@typescript-eslint/typescript-estree/-/typescript-estree-8.9.0.tgz", "integrity": "sha512-9iJYTgKLDG6+iqegehc5+EqE6sqaee7kb8vWpmHZ86EqwDjmlqNNHeqDVqb9duh+BY6WCNHfIGvuVU3Tf9Db0g==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "@typescript-eslint/types": "8.9.0", @@ -930,6 +1008,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", + "dev": true, "license": "MIT", "dependencies": { "balanced-match": "^1.0.0" @@ -939,6 +1018,7 @@ "version": "9.0.5", "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.5.tgz", "integrity": "sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==", + "dev": true, "license": "ISC", "dependencies": { "brace-expansion": "^2.0.1" @@ -954,6 +1034,7 @@ "version": "7.6.3", "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", + "dev": true, "license": "ISC", "bin": { "semver": "bin/semver.js" @@ -966,6 +1047,7 @@ "version": "8.9.0", "resolved": "https://registry.npmjs.org/@typescript-eslint/utils/-/utils-8.9.0.tgz", "integrity": "sha512-PKgMmaSo/Yg/F7kIZvrgrWa1+Vwn036CdNUvYFEkYbPwOH4i8xvkaRlu148W3vtheWK9ckKRIz7PBP5oUlkrvQ==", + "dev": true, "license": "MIT", "dependencies": { "@eslint-community/eslint-utils": "^4.4.0", @@ -988,6 +1070,7 @@ "version": "8.9.0", "resolved": "https://registry.npmjs.org/@typescript-eslint/visitor-keys/-/visitor-keys-8.9.0.tgz", "integrity": "sha512-Ht4y38ubk4L5/U8xKUBfKNYGmvKvA1CANoxiTRMM+tOLk3lbF3DvzZCxJCRSE+2GdCMSh6zq9VZJc3asc1XuAA==", + "dev": true, "license": "MIT", "dependencies": { "@typescript-eslint/types": "8.9.0", @@ -1005,6 +1088,7 @@ "version": "3.4.3", "resolved": "https://registry.npmjs.org/eslint-visitor-keys/-/eslint-visitor-keys-3.4.3.tgz", "integrity": "sha512-wpc+LXeiyiisxPlEkUzU6svyS1frIO3Mgxj1fdy7Pm8Ygzguax2N3Fa/D/ag1WqbOprdI+uY6wMUl8/a2G+iag==", + "dev": true, "license": "Apache-2.0", "engines": { "node": "^12.22.0 || ^14.17.0 || >=16.0.0" @@ -1017,12 +1101,14 @@ "version": "1.2.0", "resolved": "https://registry.npmjs.org/@ungap/structured-clone/-/structured-clone-1.2.0.tgz", "integrity": "sha512-zuVdFrMJiuCDQUMCzQaD6KL28MjnqqN8XnAqiEq9PNm/hCPTSGfrXCOfwj1ow4LFb/tNymJPwsNbVePc1xFqrQ==", + "dev": true, "license": "ISC" }, "node_modules/abbrev": { "version": "2.0.0", "resolved": "https://registry.npmjs.org/abbrev/-/abbrev-2.0.0.tgz", "integrity": "sha512-6/mh1E2u2YgEsCHdY0Yx5oW+61gZU+1vXaoiHHrpKeuRNNgFvS+/jrwHiQhB5apAf5oB7UB7E19ol2R2LKH8hQ==", + "dev": true, "license": "ISC", "engines": { "node": "^14.17.0 || ^16.13.0 || >=18.0.0" @@ -1032,6 +1118,7 @@ "version": "8.13.0", "resolved": "https://registry.npmjs.org/acorn/-/acorn-8.13.0.tgz", "integrity": "sha512-8zSiw54Oxrdym50NlZ9sUusyO1Z1ZchgRLWRaK6c86XJFClyCgFKetdowBg5bKxyp/u+CDBJG4Mpp0m3HLZl9w==", + "dev": true, "license": "MIT", "bin": { "acorn": "bin/acorn" @@ -1044,6 +1131,7 @@ "version": "5.3.2", "resolved": "https://registry.npmjs.org/acorn-jsx/-/acorn-jsx-5.3.2.tgz", "integrity": "sha512-rq9s+JNhf0IChjtDXxllJ7g41oZk5SlXtp0LHwyA5cejwn7vKmKp4pPri6YEePv2PU65sAsegbXtIinmDFDXgQ==", + "dev": true, "license": "MIT", "peerDependencies": { "acorn": "^6.0.0 || ^7.0.0 || ^8.0.0" @@ -1053,6 +1141,7 @@ "version": "6.12.6", "resolved": "https://registry.npmjs.org/ajv/-/ajv-6.12.6.tgz", "integrity": "sha512-j3fVLgvTo527anyYyJOGTYJbG+vnnQYvE0m5mmkc1TK+nxAppkCLMIL0aZ4dblVCNoGShhm+kzE4ZUykBoMg4g==", + "dev": true, "license": "MIT", "dependencies": { "fast-deep-equal": "^3.1.1", @@ -1069,6 +1158,7 @@ "version": "4.3.2", "resolved": "https://registry.npmjs.org/ansi-escapes/-/ansi-escapes-4.3.2.tgz", "integrity": "sha512-gKXj5ALrKWQLsYG9jlTRmR/xKluxHV+Z9QEwNIgCfM1/uwPMCuzVVnh5mwTd+OuBZcwSIMbqssNWRm1lE51QaQ==", + "dev": true, "license": "MIT", "dependencies": { "type-fest": "^0.21.3" @@ -1084,6 +1174,7 @@ "version": "0.21.3", "resolved": "https://registry.npmjs.org/type-fest/-/type-fest-0.21.3.tgz", "integrity": "sha512-t0rzBq87m3fVcduHDUFhKmyyX+9eo6WQjZvf51Ea/M0Q7+T374Jp1aUiyUl0GKxp8M/OETVHSDvmkyPgvX+X2w==", + "dev": true, "license": "(MIT OR CC0-1.0)", "engines": { "node": ">=10" @@ -1096,6 +1187,7 @@ "version": "5.0.1", "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz", "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==", + "dev": true, "license": "MIT", "engines": { "node": ">=8" @@ -1105,6 +1197,7 @@ "version": "4.3.0", "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz", "integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==", + "dev": true, "license": "MIT", "dependencies": { "color-convert": "^2.0.1" @@ -1120,6 +1213,7 @@ "version": "3.1.3", "resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.3.tgz", "integrity": "sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==", + "dev": true, "license": "ISC", "dependencies": { "normalize-path": "^3.0.0", @@ -1133,6 +1227,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz", "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==", + "dev": true, "license": "Python-2.0" }, "node_modules/array-buffer-byte-length": { @@ -1275,6 +1370,7 @@ "version": "0.21.4", "resolved": "https://registry.npmjs.org/axios/-/axios-0.21.4.tgz", "integrity": "sha512-ut5vewkiu8jjGBdqpM44XxjuCjq9LAKeHVmoVfHVzy8eHgxxq8SbAVQNovDA8mVi05kP0Ea/n/UzcSHcTJQfNg==", + "dev": true, "license": "MIT", "dependencies": { "follow-redirects": "^1.14.0" @@ -1284,6 +1380,7 @@ "version": "2.0.2", "resolved": "https://registry.npmjs.org/bail/-/bail-2.0.2.tgz", "integrity": "sha512-0xO6mYd7JB2YesxDKplafRpsiOzPt9V02ddPCLbY1xYGPOX24NTyN50qnUxgCPcSoYMhKpAuBTjQoRZCAkUDRw==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -1294,12 +1391,14 @@ "version": "1.0.2", "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.2.tgz", "integrity": "sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==", + "dev": true, "license": "MIT" }, "node_modules/base64-js": { "version": "1.5.1", "resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.5.1.tgz", "integrity": "sha512-AKpaYlHn8t4SVbOHCy+b5+KKgvR4vrsD8vbvrbiQJps7fKDTkjkDry6ji0rUJjC0kzbNePLwzxq8iypo41qeWA==", + "dev": true, "funding": [ { "type": "github", @@ -1320,6 +1419,7 @@ "version": "2.3.0", "resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.3.0.tgz", "integrity": "sha512-Ceh+7ox5qe7LJuLHoY0feh3pHuUDHAcRUeyL2VYghZwfpkNIy/+8Ocg0a3UuSoYzavmylwuLWQOf3hl0jjMMIw==", + "dev": true, "license": "MIT", "engines": { "node": ">=8" @@ -1332,6 +1432,7 @@ "version": "4.1.0", "resolved": "https://registry.npmjs.org/bl/-/bl-4.1.0.tgz", "integrity": "sha512-1W07cM9gS6DcLperZfFSj+bWLtaPGSOHWhPiGzXmvVJbRLdG82sH/Kn8EtW1VqWVA54AKf2h5k5BbnIbwF3h6w==", + "dev": true, "license": "MIT", "dependencies": { "buffer": "^5.5.0", @@ -1343,12 +1444,14 @@ "version": "1.0.0", "resolved": "https://registry.npmjs.org/boolbase/-/boolbase-1.0.0.tgz", "integrity": "sha512-JZOSA7Mo9sNGB8+UjSgzdLtokWAky1zbztM3WRLCbZ70/3cTANmQmOdR7y2g+J0e2WXywy1yS468tY+IruqEww==", + "dev": true, "license": "ISC" }, "node_modules/brace-expansion": { "version": "1.1.11", "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz", "integrity": "sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==", + "dev": true, "license": "MIT", "dependencies": { "balanced-match": "^1.0.0", @@ -1359,6 +1462,7 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz", "integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==", + "dev": true, "license": "MIT", "dependencies": { "fill-range": "^7.1.1" @@ -1371,6 +1475,7 @@ "version": "5.7.1", "resolved": "https://registry.npmjs.org/buffer/-/buffer-5.7.1.tgz", "integrity": "sha512-EHcyIPBQ4BSGlvjB16k5KgAJ27CIsHY/2JBmCRReo48y9rQ3MaUzWX3KVlBa4U7MyX02HdVj0K7C3WaB3ju7FQ==", + "dev": true, "funding": [ { "type": "github", @@ -1395,6 +1500,7 @@ "version": "1.1.2", "resolved": "https://registry.npmjs.org/buffer-from/-/buffer-from-1.1.2.tgz", "integrity": "sha512-E+XQCRwSbaaiChtv6k6Dwgc+bx+Bs6vuKJHHl5kox/BaKbhiXzqQOwK4cO22yElGp2OCmjwVhT3HmxgyPGnJfQ==", + "dev": true, "license": "MIT" }, "node_modules/call-bind": { @@ -1421,6 +1527,7 @@ "version": "3.1.0", "resolved": "https://registry.npmjs.org/callsites/-/callsites-3.1.0.tgz", "integrity": "sha512-P8BjAsXvZS+VIDUI11hHCQEv74YT67YUi5JJFNWIqL235sBmjX4+qx9Muvls5ivyNENctx46xQLQ3aTuE7ssaQ==", + "dev": true, "license": "MIT", "engines": { "node": ">=6" @@ -1430,6 +1537,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/ccount/-/ccount-2.0.1.tgz", "integrity": "sha512-eyrF0jiFpY+3drT6383f1qhkbGsLSifNAjA61IUjZjmLCWjItY6LB9ft9YhoDgwfmclB2zhu51Lc7+95b8NRAg==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -1440,6 +1548,7 @@ "version": "4.1.2", "resolved": "https://registry.npmjs.org/chalk/-/chalk-4.1.2.tgz", "integrity": "sha512-oKnbhFyRIXpUuez8iBMmyEa4nbj4IOQyuhc/wy9kY7/WVPcwIO9VA668Pu8RkO7+0G76SLROeyw9CpQ061i4mA==", + "dev": true, "license": "MIT", "dependencies": { "ansi-styles": "^4.1.0", @@ -1456,6 +1565,7 @@ "version": "2.0.2", "resolved": "https://registry.npmjs.org/character-entities/-/character-entities-2.0.2.tgz", "integrity": "sha512-shx7oQ0Awen/BRIdkjkvz54PnEEI/EjwXDSIZp86/KKdbafHh1Df/RYGBhn4hbe2+uKC9FnT5UCEdyPz3ai9hQ==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -1466,6 +1576,7 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/character-entities-html4/-/character-entities-html4-2.1.0.tgz", "integrity": "sha512-1v7fgQRj6hnSwFpq1Eu0ynr/CDEw0rXo2B61qXrLNdHZmPKgb7fqS1a2JwF0rISo9q77jDI8VMEHoApn8qDoZA==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -1476,6 +1587,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/character-entities-legacy/-/character-entities-legacy-3.0.0.tgz", "integrity": "sha512-RpPp0asT/6ufRm//AJVwpViZbGM/MkjQFxJccQRHmISF/22NBtsHqAWmL+/pmkPWoIUJdWyeVleTl1wydHATVQ==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -1486,6 +1598,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/character-reference-invalid/-/character-reference-invalid-2.0.1.tgz", "integrity": "sha512-iBZ4F4wRbyORVsu0jPV7gXkOsGYjGHPmAyv+HiHG8gi5PtC9KI2j1+v8/tlibRvjoWX027ypmG/n0HtO5t7unw==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -1496,12 +1609,14 @@ "version": "0.7.0", "resolved": "https://registry.npmjs.org/chardet/-/chardet-0.7.0.tgz", "integrity": "sha512-mT8iDcrh03qDGRRmoA2hmBJnxpllMR+0/0qlzjqZES6NdiWDcZkCNAk4rPFZ9Q85r27unkiNNg8ZOiwZXBHwcA==", + "dev": true, "license": "MIT" }, "node_modules/charenc": { "version": "0.0.2", "resolved": "https://registry.npmjs.org/charenc/-/charenc-0.0.2.tgz", "integrity": "sha512-yrLQ/yVUFXkzg7EDQsPieE/53+0RlaWTs+wBrvW36cyilJ2SaDWfl4Yj7MtLTXleV9uEKefbAGUPv2/iWSooRA==", + "dev": true, "license": "BSD-3-Clause", "engines": { "node": "*" @@ -1511,6 +1626,7 @@ "version": "1.0.0", "resolved": "https://registry.npmjs.org/cheerio/-/cheerio-1.0.0.tgz", "integrity": "sha512-quS9HgjQpdaXOvsZz82Oz7uxtXiy6UIsIQcpBj7HRw2M63Skasm9qlDocAM7jNuaxdhpPU7c4kJN+gA5MCu4ww==", + "dev": true, "license": "MIT", "dependencies": { "cheerio-select": "^2.1.0", @@ -1536,6 +1652,7 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/cheerio-select/-/cheerio-select-2.1.0.tgz", "integrity": "sha512-9v9kG0LvzrlcungtnJtpGNxY+fzECQKhK4EGJX2vByejiMX84MFNQw4UxPJl3bFbTMw+Dfs37XaIkCwTZfLh4g==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "boolbase": "^1.0.0", @@ -1549,22 +1666,11 @@ "url": "https://github.com/sponsors/fb55" } }, - "node_modules/cheerio/node_modules/parse5": { - "version": "7.2.0", - "resolved": "https://registry.npmjs.org/parse5/-/parse5-7.2.0.tgz", - "integrity": "sha512-ZkDsAOcxsUMZ4Lz5fVciOehNcJ+Gb8gTzcA4yl3wnc273BAybYWrQ+Ks/OjCjSEpjvQkDSeZbybK9qj2VHHdGA==", - "license": "MIT", - "dependencies": { - "entities": "^4.5.0" - }, - "funding": { - "url": "https://github.com/inikulin/parse5?sponsor=1" - } - }, "node_modules/chokidar": { "version": "3.6.0", "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.6.0.tgz", "integrity": "sha512-7VT13fmjotKpGipCW9JEQAusEPE+Ei8nl6/g4FBAmIm0GOOLMua9NDDo/DWp0ZAxCr3cPq5ZpBqmPAQgDda2Pw==", + "dev": true, "license": "MIT", "dependencies": { "anymatch": "~3.1.2", @@ -1589,6 +1695,7 @@ "version": "5.1.2", "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz", "integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==", + "dev": true, "license": "ISC", "dependencies": { "is-glob": "^4.0.1" @@ -1601,6 +1708,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/ci-info/-/ci-info-4.0.0.tgz", "integrity": "sha512-TdHqgGf9odd8SXNuxtUBVx8Nv+qZOejE6qyqiy5NtbYYQOeFa6zmHkxlPzmaLxWWHsU6nJmB7AETdVPi+2NBUg==", + "dev": true, "funding": [ { "type": "github", @@ -1616,6 +1724,7 @@ "version": "3.1.0", "resolved": "https://registry.npmjs.org/cli-cursor/-/cli-cursor-3.1.0.tgz", "integrity": "sha512-I/zHAwsKf9FqGoXM4WWRACob9+SNukZTd94DWF57E4toouRulbCxcUh6RKUEOQlYTHJnzkPMySvPNaaSLNfLZw==", + "dev": true, "license": "MIT", "dependencies": { "restore-cursor": "^3.1.0" @@ -1628,6 +1737,7 @@ "version": "2.9.2", "resolved": "https://registry.npmjs.org/cli-spinners/-/cli-spinners-2.9.2.tgz", "integrity": "sha512-ywqV+5MmyL4E7ybXgKys4DugZbX0FC6LnwrhjuykIjnK9k8OQacQ7axGKnjDXWNhns0xot3bZI5h55H8yo9cJg==", + "dev": true, "license": "MIT", "engines": { "node": ">=6" @@ -1640,6 +1750,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/cli-width/-/cli-width-3.0.0.tgz", "integrity": "sha512-FxqpkPPwu1HjuN93Omfm4h8uIanXofW0RxVEW3k5RKx+mJJYSthzNhp32Kzxxy3YAEZ/Dc/EWN1vZRY0+kOhbw==", + "dev": true, "license": "ISC", "engines": { "node": ">= 10" @@ -1649,6 +1760,7 @@ "version": "1.0.4", "resolved": "https://registry.npmjs.org/clone/-/clone-1.0.4.tgz", "integrity": "sha512-JQHZ2QMW6l3aH/j6xCqQThY/9OH4D/9ls34cgkUBiEeocRTU04tHfKPBsUK1PqZCUQM7GiA0IIXJSuXHI64Kbg==", + "dev": true, "license": "MIT", "engines": { "node": ">=0.8" @@ -1658,6 +1770,7 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/collapse-white-space/-/collapse-white-space-2.1.0.tgz", "integrity": "sha512-loKTxY1zCOuG4j9f6EPnuyyYkf58RnhhWTvRoZEokgB+WbdXehfjFviyOVYkqzEWz1Q5kRiZdBYS5SwxbQYwzw==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -1668,6 +1781,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz", "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==", + "dev": true, "license": "MIT", "dependencies": { "color-name": "~1.1.4" @@ -1680,12 +1794,14 @@ "version": "1.1.4", "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz", "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==", + "dev": true, "license": "MIT" }, "node_modules/comma-separated-tokens": { "version": "2.0.3", "resolved": "https://registry.npmjs.org/comma-separated-tokens/-/comma-separated-tokens-2.0.3.tgz", "integrity": "sha512-Fu4hJdvzeylCfQPp9SGWidpzrMs7tTrlu6Vb8XGaRGck8QSNZJJp538Wrb60Lax4fPwR64ViY468OIUTbRlGZg==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -1696,6 +1812,7 @@ "version": "8.3.0", "resolved": "https://registry.npmjs.org/commander/-/commander-8.3.0.tgz", "integrity": "sha512-OkTL9umf+He2DZkUq8f8J9of7yL6RJKI24dVITBmNfZBmri9zYZQrKkuXiKhyfPSu8tUhnVBB1iKXevvnlR4Ww==", + "dev": true, "license": "MIT", "engines": { "node": ">= 12" @@ -1705,12 +1822,14 @@ "version": "0.0.1", "resolved": "https://registry.npmjs.org/concat-map/-/concat-map-0.0.1.tgz", "integrity": "sha512-/Srv4dswyQNBfohGpz9o6Yb3Gz3SrUDqBH5rTuhGR7ahtlbYKnVxw2bCFMRljaA7EXHaXZ8wsHdodFvbkhKmqg==", + "dev": true, "license": "MIT" }, "node_modules/concat-stream": { "version": "2.0.0", "resolved": "https://registry.npmjs.org/concat-stream/-/concat-stream-2.0.0.tgz", "integrity": "sha512-MWufYdFw53ccGjCA+Ol7XJYpAlW6/prSMzuPOTRnJGcGzuhLn4Scrz7qf6o8bROZ514ltazcIFJZevcfbo0x7A==", + "dev": true, "engines": [ "node >= 6.0" ], @@ -1726,6 +1845,7 @@ "version": "7.0.3", "resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.3.tgz", "integrity": "sha512-iRDPJKUPVEND7dHPO8rkbOnPpyDygcDFtWjpeWNCgy8WP2rXcxXL8TskReQl6OrB2G7+UJrags1q15Fudc7G6w==", + "dev": true, "license": "MIT", "dependencies": { "path-key": "^3.1.0", @@ -1740,6 +1860,7 @@ "version": "0.0.2", "resolved": "https://registry.npmjs.org/crypt/-/crypt-0.0.2.tgz", "integrity": "sha512-mCxBlsHFYh9C+HVpiEacem8FEBnMXgU9gy4zmNC+SXAZNB/1idgp/aulFJ4FgCi7GPEVbfyng092GqL2k2rmow==", + "dev": true, "license": "BSD-3-Clause", "engines": { "node": "*" @@ -1749,6 +1870,7 @@ "version": "5.1.0", "resolved": "https://registry.npmjs.org/css-select/-/css-select-5.1.0.tgz", "integrity": "sha512-nwoRF1rvRRnnCqqY7updORDsuqKzqYJ28+oSMaJMMgOauh3fvwHqMS7EZpIPqK8GL+g9mKxF1vP/ZjSeNjEVHg==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "boolbase": "^1.0.0", @@ -1765,6 +1887,7 @@ "version": "6.1.0", "resolved": "https://registry.npmjs.org/css-what/-/css-what-6.1.0.tgz", "integrity": "sha512-HTUrgRJ7r4dsZKU6GjmpfRK1O76h97Z8MfS1G0FozR+oF2kG6Vfe8JE6zwrkbxigziPHinCJ+gCPjA9EaBDtRw==", + "dev": true, "license": "BSD-2-Clause", "engines": { "node": ">= 6" @@ -1831,6 +1954,7 @@ "version": "4.3.5", "resolved": "https://registry.npmjs.org/debug/-/debug-4.3.5.tgz", "integrity": "sha512-pt0bNEmneDIvdL1Xsd9oDQ/wrQRkXDT4AUWlNZNPKvW5x/jyO9VFXkJUP07vQ2upmw5PlaITaPKc31jK13V+jg==", + "dev": true, "license": "MIT", "dependencies": { "ms": "2.1.2" @@ -1848,6 +1972,7 @@ "version": "1.0.2", "resolved": "https://registry.npmjs.org/decode-named-character-reference/-/decode-named-character-reference-1.0.2.tgz", "integrity": "sha512-O8x12RzrUF8xyVcY0KJowWsmaJxQbmy0/EtnNtHRpsOcT7dFk5W598coHqBVpmWo1oQQfsCqfCmkZN5DJrZVdg==", + "dev": true, "license": "MIT", "dependencies": { "character-entities": "^2.0.0" @@ -1861,12 +1986,14 @@ "version": "0.1.4", "resolved": "https://registry.npmjs.org/deep-is/-/deep-is-0.1.4.tgz", "integrity": "sha512-oIPzksmTg4/MriiaYGO+okXDT7ztn/w3Eptv/+gSIdMdKsJo0u4CfYNFJPy+4SKMuCqGw2wxnA+URMg3t8a/bQ==", + "dev": true, "license": "MIT" }, "node_modules/defaults": { "version": "1.0.4", "resolved": "https://registry.npmjs.org/defaults/-/defaults-1.0.4.tgz", "integrity": "sha512-eFuaLoy/Rxalv2kr+lqMlUnrDWV+3j4pljOIJgLIhI058IQfWJ7vXhyEIHu+HtC738klGALYxOKDO0bQP3tg8A==", + "dev": true, "license": "MIT", "dependencies": { "clone": "^1.0.2" @@ -1915,6 +2042,7 @@ "version": "2.0.3", "resolved": "https://registry.npmjs.org/dequal/-/dequal-2.0.3.tgz", "integrity": "sha512-0je+qPKHEMohvfRTCEo3CrPG6cAzAYgmzKyxRiYSSDkS6eGJdyVJm7WaYA5ECaAD9wLB2T4EEeymA5aFVcYXCA==", + "dev": true, "license": "MIT", "engines": { "node": ">=6" @@ -1924,6 +2052,7 @@ "version": "1.1.0", "resolved": "https://registry.npmjs.org/devlop/-/devlop-1.1.0.tgz", "integrity": "sha512-RWmIqhcFf1lRYBvNmr7qTNuyCt/7/ns2jbpp1+PalgE/rDQcBT0fioSMUpJ93irlUhC5hrg4cYqe6U+0ImW0rA==", + "dev": true, "license": "MIT", "dependencies": { "dequal": "^2.0.0" @@ -1950,6 +2079,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/dom-serializer/-/dom-serializer-2.0.0.tgz", "integrity": "sha512-wIkAryiqt/nV5EQKqQpo3SToSOV9J0DnbJqwK7Wv/Trc92zIAYZ4FlMu+JPFW1DfGFt81ZTCGgDEabffXeLyJg==", + "dev": true, "license": "MIT", "dependencies": { "domelementtype": "^2.3.0", @@ -1964,6 +2094,7 @@ "version": "2.3.0", "resolved": "https://registry.npmjs.org/domelementtype/-/domelementtype-2.3.0.tgz", "integrity": "sha512-OLETBj6w0OsagBwdXnPdN0cnMfF9opN69co+7ZrbfPGrdpPVNBUj02spi6B1N7wChLQiPn4CSH/zJvXw56gmHw==", + "dev": true, "funding": [ { "type": "github", @@ -1976,6 +2107,7 @@ "version": "5.0.3", "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-5.0.3.tgz", "integrity": "sha512-cgwlv/1iFQiFnU96XXgROh8xTeetsnJiDsTc7TYCLFd9+/WNkIqPTxiM/8pSd8VIrhXGTf1Ny1q1hquVqDJB5w==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "domelementtype": "^2.3.0" @@ -1991,6 +2123,7 @@ "version": "3.1.0", "resolved": "https://registry.npmjs.org/domutils/-/domutils-3.1.0.tgz", "integrity": "sha512-H78uMmQtI2AhgDJjWeQmHwJJ2bLPD3GMmO7Zja/ZZh84wkm+4ut+IUnUdRa8uCGX88DiVx1j6FRe1XfxEgjEZA==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "dom-serializer": "^2.0.0", @@ -2018,18 +2151,21 @@ "version": "0.2.0", "resolved": "https://registry.npmjs.org/eastasianwidth/-/eastasianwidth-0.2.0.tgz", "integrity": "sha512-I88TYZWc9XiYHRQ4/3c5rjjfgkjhLyW2luGIheGERbNQ6OY7yTybanSpDXZa8y7VUP9YmDcYa+eyq4ca7iLqWA==", + "dev": true, "license": "MIT" }, "node_modules/emoji-regex": { "version": "8.0.0", "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz", "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==", + "dev": true, "license": "MIT" }, "node_modules/encoding-sniffer": { "version": "0.2.0", "resolved": "https://registry.npmjs.org/encoding-sniffer/-/encoding-sniffer-0.2.0.tgz", "integrity": "sha512-ju7Wq1kg04I3HtiYIOrUrdfdDvkyO9s5XM8QAj/bN61Yo/Vb4vgJxy5vi4Yxk01gWHbrofpPtpxM8bKger9jhg==", + "dev": true, "license": "MIT", "dependencies": { "iconv-lite": "^0.6.3", @@ -2043,6 +2179,7 @@ "version": "4.5.0", "resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz", "integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==", + "dev": true, "license": "BSD-2-Clause", "engines": { "node": ">=0.12" @@ -2055,12 +2192,14 @@ "version": "2.0.3", "resolved": "https://registry.npmjs.org/err-code/-/err-code-2.0.3.tgz", "integrity": "sha512-2bmlRpNKBxT/CRmPOlyISQpNj+qSeYvcym/uT0Jx2bMOlKLtSy1ZmLuVxSEKKyor/N5yhvp/ZiG1oE3DEYMSFA==", + "dev": true, "license": "MIT" }, "node_modules/error-ex": { "version": "1.3.2", "resolved": "https://registry.npmjs.org/error-ex/-/error-ex-1.3.2.tgz", "integrity": "sha512-7dFHNmqeFSEt2ZBsCriorKnn3Z2pj+fd9kmI6QoWw4//DL+icEBfc0U7qJCisqrTsKTjw4fNFy2pW9OqStD84g==", + "dev": true, "license": "MIT", "dependencies": { "is-arrayish": "^0.2.1" @@ -2210,6 +2349,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-4.0.0.tgz", "integrity": "sha512-TtpcNJ3XAzx3Gq8sWRzJaVajRs0uVxA2YAkdb1jm2YkPz4G6egUFAyA3n5vtEIZefPk5Wa4UXbKuS5fKkJWdgA==", + "dev": true, "license": "MIT", "engines": { "node": ">=10" @@ -2219,17 +2359,18 @@ } }, "node_modules/eslint": { - "version": "9.12.0", - "resolved": "https://registry.npmjs.org/eslint/-/eslint-9.12.0.tgz", - "integrity": "sha512-UVIOlTEWxwIopRL1wgSQYdnVDcEvs2wyaO6DGo5mXqe3r16IoCNWkR29iHhyaP4cICWjbgbmFUGAhh0GJRuGZw==", + "version": "9.13.0", + "resolved": "https://registry.npmjs.org/eslint/-/eslint-9.13.0.tgz", + "integrity": "sha512-EYZK6SX6zjFHST/HRytOdA/zE72Cq/bfw45LSyuwrdvcclb/gqV8RRQxywOBEWO2+WDpva6UZa4CcDeJKzUCFA==", + "dev": true, "license": "MIT", "dependencies": { "@eslint-community/eslint-utils": "^4.2.0", "@eslint-community/regexpp": "^4.11.0", "@eslint/config-array": "^0.18.0", - "@eslint/core": "^0.6.0", + "@eslint/core": "^0.7.0", "@eslint/eslintrc": "^3.1.0", - "@eslint/js": "9.12.0", + "@eslint/js": "9.13.0", "@eslint/plugin-kit": "^0.2.0", "@humanfs/node": "^0.16.5", "@humanwhocodes/module-importer": "^1.0.1", @@ -2376,6 +2517,7 @@ "version": "8.1.0", "resolved": "https://registry.npmjs.org/eslint-scope/-/eslint-scope-8.1.0.tgz", "integrity": "sha512-14dSvlhaVhKKsa9Fx1l8A17s7ah7Ef7wCakJ10LYk6+GYmP9yDti2oq2SEwcyndt6knfcZyhyxwY3i9yL78EQw==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "esrecurse": "^4.3.0", @@ -2392,6 +2534,7 @@ "version": "4.1.0", "resolved": "https://registry.npmjs.org/eslint-visitor-keys/-/eslint-visitor-keys-4.1.0.tgz", "integrity": "sha512-Q7lok0mqMUSf5a/AdAZkA5a/gHcO6snwQClVNNvFKCAVlxXucdU8pKydU5ZVZjBx5xr37vGbFFWtLQYreLzrZg==", + "dev": true, "license": "Apache-2.0", "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -2404,6 +2547,7 @@ "version": "10.2.0", "resolved": "https://registry.npmjs.org/espree/-/espree-10.2.0.tgz", "integrity": "sha512-upbkBJbckcCNBDBDXEbuhjbP68n+scUd3k/U2EkyM9nw+I/jPiL4cLF/Al06CF96wRltFda16sxDFrxsI1v0/g==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "acorn": "^8.12.0", @@ -2421,6 +2565,7 @@ "version": "1.6.0", "resolved": "https://registry.npmjs.org/esquery/-/esquery-1.6.0.tgz", "integrity": "sha512-ca9pw9fomFcKPvFLXhBKUK90ZvGibiGOvRJNbjljY7s7uq/5YO4BOzcYtJqExdx99rF6aAcnRxHmcUHcz6sQsg==", + "dev": true, "license": "BSD-3-Clause", "dependencies": { "estraverse": "^5.1.0" @@ -2433,6 +2578,7 @@ "version": "4.3.0", "resolved": "https://registry.npmjs.org/esrecurse/-/esrecurse-4.3.0.tgz", "integrity": "sha512-KmfKL3b6G+RXvP8N1vr3Tq1kL/oCFgn2NYXEtqP8/L3pKapUA4G8cFVaoF3SU323CD4XypR/ffioHmkti6/Tag==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "estraverse": "^5.2.0" @@ -2445,6 +2591,7 @@ "version": "5.3.0", "resolved": "https://registry.npmjs.org/estraverse/-/estraverse-5.3.0.tgz", "integrity": "sha512-MMdARuVEQziNTeJD8DgMqmhwR11BRQ/cBP+pLtYdSTnf3MIO8fFeiINEbX36ZdNlfU/7A9f3gUw49B3oQsvwBA==", + "dev": true, "license": "BSD-2-Clause", "engines": { "node": ">=4.0" @@ -2454,6 +2601,7 @@ "version": "2.0.3", "resolved": "https://registry.npmjs.org/esutils/-/esutils-2.0.3.tgz", "integrity": "sha512-kVscqXk4OCp68SZ0dkgEKVi6/8ij300KBWTJq32P/dYeWTSwK41WyTxalN1eRmA5Z9UU/LX9D7FWSmV9SAYx6g==", + "dev": true, "license": "BSD-2-Clause", "engines": { "node": ">=0.10.0" @@ -2463,12 +2611,14 @@ "version": "3.0.2", "resolved": "https://registry.npmjs.org/extend/-/extend-3.0.2.tgz", "integrity": "sha512-fjquC59cD7CyW6urNXK0FBufkZcoiGG80wTuPujX590cB5Ttln20E2UB4S/WARVqhXffZl2LNgS+gQdPIIim/g==", + "dev": true, "license": "MIT" }, "node_modules/external-editor": { "version": "3.1.0", "resolved": "https://registry.npmjs.org/external-editor/-/external-editor-3.1.0.tgz", "integrity": "sha512-hMQ4CX1p1izmuLYyZqLMO/qGNw10wSv9QDCPfzXfyFrOaCSSoRfqE1Kf1s5an66J5JZC62NewG+mK49jOCtQew==", + "dev": true, "license": "MIT", "dependencies": { "chardet": "^0.7.0", @@ -2483,6 +2633,7 @@ "version": "0.4.24", "resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.4.24.tgz", "integrity": "sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA==", + "dev": true, "license": "MIT", "dependencies": { "safer-buffer": ">= 2.1.2 < 3" @@ -2495,12 +2646,14 @@ "version": "3.1.3", "resolved": "https://registry.npmjs.org/fast-deep-equal/-/fast-deep-equal-3.1.3.tgz", "integrity": "sha512-f3qQ9oQy9j2AhBe/H9VC91wLmKBCCU/gDOnKNAYG5hswO7BLKj09Hc5HYNz9cGI++xlpDCIgDaitVs03ATR84Q==", + "dev": true, "license": "MIT" }, "node_modules/fast-glob": { "version": "3.3.2", "resolved": "https://registry.npmjs.org/fast-glob/-/fast-glob-3.3.2.tgz", "integrity": "sha512-oX2ruAFQwf/Orj8m737Y5adxDQO0LAB7/S5MnxCdTNDd4p6BsyIVsv9JQsATbTSq8KHRpLwIHbVlUNatxd+1Ow==", + "dev": true, "license": "MIT", "dependencies": { "@nodelib/fs.stat": "^2.0.2", @@ -2517,6 +2670,7 @@ "version": "5.1.2", "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz", "integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==", + "dev": true, "license": "ISC", "dependencies": { "is-glob": "^4.0.1" @@ -2529,18 +2683,21 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/fast-json-stable-stringify/-/fast-json-stable-stringify-2.1.0.tgz", "integrity": "sha512-lhd/wF+Lk98HZoTCtlVraHtfh5XYijIjalXck7saUtuanSDyLMxnHhSXEDJqHxD7msR8D0uCmqlkwjCV8xvwHw==", + "dev": true, "license": "MIT" }, "node_modules/fast-levenshtein": { "version": "2.0.6", "resolved": "https://registry.npmjs.org/fast-levenshtein/-/fast-levenshtein-2.0.6.tgz", "integrity": "sha512-DCXu6Ifhqcks7TZKY3Hxp3y6qphY5SJZmrWMDrKcERSOXWQdMhU9Ig/PYrzyw/ul9jOIyh0N4M0tbC5hodg8dw==", + "dev": true, "license": "MIT" }, "node_modules/fastq": { "version": "1.17.1", "resolved": "https://registry.npmjs.org/fastq/-/fastq-1.17.1.tgz", "integrity": "sha512-sRVD3lWVIXWg6By68ZN7vho9a1pQcN/WBFaAAsDDFzlJjvoGx0P8z7V1t72grFJfJhu3YPZBuu25f7Kaw2jN1w==", + "dev": true, "license": "ISC", "dependencies": { "reusify": "^1.0.4" @@ -2550,6 +2707,7 @@ "version": "3.2.0", "resolved": "https://registry.npmjs.org/figures/-/figures-3.2.0.tgz", "integrity": "sha512-yaduQFRKLXYOGgEn6AZau90j3ggSOyiqXU0F9JZfeXYhNa+Jk4X+s45A2zg5jns87GAFa34BBm2kXw4XpNcbdg==", + "dev": true, "license": "MIT", "dependencies": { "escape-string-regexp": "^1.0.5" @@ -2565,6 +2723,7 @@ "version": "1.0.5", "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz", "integrity": "sha512-vbRorB5FUQWvla16U8R/qgaFIya2qGzwDrNmCZuYKrbdSUMG6I1ZCGQRefkRVhuOkIGVne7BQ35DSfo1qvJqFg==", + "dev": true, "license": "MIT", "engines": { "node": ">=0.8.0" @@ -2574,6 +2733,7 @@ "version": "8.0.0", "resolved": "https://registry.npmjs.org/file-entry-cache/-/file-entry-cache-8.0.0.tgz", "integrity": "sha512-XXTUwCvisa5oacNGRP9SfNtYBNAMi+RPwBFmblZEF7N7swHYQS6/Zfk7SRwx4D5j3CH211YNRco1DEMNVfZCnQ==", + "dev": true, "license": "MIT", "dependencies": { "flat-cache": "^4.0.0" @@ -2586,6 +2746,7 @@ "version": "7.1.1", "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz", "integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==", + "dev": true, "license": "MIT", "dependencies": { "to-regex-range": "^5.0.1" @@ -2598,6 +2759,7 @@ "version": "5.0.0", "resolved": "https://registry.npmjs.org/find-up/-/find-up-5.0.0.tgz", "integrity": "sha512-78/PXT1wlLLDgTzDs7sjq9hzz0vXD+zn+7wypEe4fXQxCmdmqfGsEPQxmiCSQI3ajFV91bVSsvNtrJRiW6nGng==", + "dev": true, "license": "MIT", "dependencies": { "locate-path": "^6.0.0", @@ -2614,6 +2776,7 @@ "version": "4.0.1", "resolved": "https://registry.npmjs.org/flat-cache/-/flat-cache-4.0.1.tgz", "integrity": "sha512-f7ccFPK3SXFHpx15UIGyRJ/FJQctuKZ0zVuN3frBo4HnK3cay9VEW0R6yPYFHC0AgqhukPzKjq22t5DmAyqGyw==", + "dev": true, "license": "MIT", "dependencies": { "flatted": "^3.2.9", @@ -2627,12 +2790,14 @@ "version": "3.3.1", "resolved": "https://registry.npmjs.org/flatted/-/flatted-3.3.1.tgz", "integrity": "sha512-X8cqMLLie7KsNUDSdzeN8FYK9rEt4Dt67OsG/DNGnYTSDBG4uFAJFBnUeiV+zCVAvwFy56IjM9sH51jVaEhNxw==", + "dev": true, "license": "ISC" }, "node_modules/follow-redirects": { "version": "1.15.9", "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.15.9.tgz", "integrity": "sha512-gew4GsXizNgdoRyqmyfMHyAmXsZDk6mHkSxZFCzW9gwlbtOW44CDtYavM+y+72qD/Vq2l550kMF52DT8fOLJqQ==", + "dev": true, "funding": [ { "type": "individual", @@ -2663,6 +2828,7 @@ "version": "3.3.0", "resolved": "https://registry.npmjs.org/foreground-child/-/foreground-child-3.3.0.tgz", "integrity": "sha512-Ld2g8rrAyMYFXBhEqMz8ZAHBi4J4uS1i/CxGMDnjyFWddMXLVcDp051DZfu+t7+ab7Wv6SMqpWmyFIj5UbfFvg==", + "dev": true, "license": "ISC", "dependencies": { "cross-spawn": "^7.0.0", @@ -2679,6 +2845,7 @@ "version": "4.1.0", "resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-4.1.0.tgz", "integrity": "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw==", + "dev": true, "license": "ISC", "engines": { "node": ">=14" @@ -2691,6 +2858,7 @@ "version": "10.1.0", "resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-10.1.0.tgz", "integrity": "sha512-oRXApq54ETRj4eMiFzGnHWGy+zo5raudjuxN0b8H7s/RU2oW0Wvsx9O0ACRN/kRq9E8Vu/ReskGB5o3ji+FzHQ==", + "dev": true, "license": "MIT", "dependencies": { "graceful-fs": "^4.2.0", @@ -2705,6 +2873,7 @@ "version": "2.3.3", "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz", "integrity": "sha512-5xoDfX+fL7faATnagmWPpbFtwh/R77WmMMqqHGS65C3vvB0YHrgF+B1YmZ3441tMj5n63k0212XNoJwzlhffQw==", + "dev": true, "hasInstallScript": true, "license": "MIT", "optional": true, @@ -2796,12 +2965,14 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/github-slugger/-/github-slugger-2.0.0.tgz", "integrity": "sha512-IaOQ9puYtjrkq7Y0Ygl9KDZnrf/aiUJYUpVf89y8kyaxbRG7Y1SrX/jaumrv81vc61+kiMempujsM3Yw7w5qcw==", + "dev": true, "license": "ISC" }, "node_modules/glob-parent": { "version": "6.0.2", "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-6.0.2.tgz", "integrity": "sha512-XxwI8EOhVQgWp6iDL+3b0r86f4d6AX6zSU55HfB4ydCEuXLXc5FcYeOu+nnGftS4TEju/11rt4KJPTMgbfmv4A==", + "dev": true, "license": "ISC", "dependencies": { "is-glob": "^4.0.3" @@ -2814,6 +2985,7 @@ "version": "14.0.0", "resolved": "https://registry.npmjs.org/globals/-/globals-14.0.0.tgz", "integrity": "sha512-oahGvuMGQlPw/ivIYBjVSrWAfWLBeku5tpPE2fOPLi+WHffIWbuh2tCjhyQhTBPMf5E9jDEH4FOmTYgYwbKwtQ==", + "dev": true, "license": "MIT", "engines": { "node": ">=18" @@ -2856,6 +3028,7 @@ "version": "4.2.11", "resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.11.tgz", "integrity": "sha512-RbJ5/jmFcNNCcDV5o9eTnBLJ/HszWV0P73bc+Ff4nS/rJj+YaS6IGyiOL0VoBYX+l1Wrl3k63h/KrH+nhJ0XvQ==", + "dev": true, "license": "ISC" }, "node_modules/has-bigints": { @@ -2872,6 +3045,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz", "integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==", + "dev": true, "license": "MIT", "engines": { "node": ">=8" @@ -2945,169 +3119,56 @@ "node": ">= 0.4" } }, - "node_modules/hast-util-from-parse5": { - "version": "7.1.2", - "resolved": "https://registry.npmjs.org/hast-util-from-parse5/-/hast-util-from-parse5-7.1.2.tgz", - "integrity": "sha512-Nz7FfPBuljzsN3tCQ4kCBKqdNhQE2l0Tn+X1ubgKBPRoiDIu1mL08Cfw4k7q71+Duyaw7DXDN+VTAp4Vh3oCOw==", + "node_modules/hast-util-parse-selector": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/hast-util-parse-selector/-/hast-util-parse-selector-4.0.0.tgz", + "integrity": "sha512-wkQCkSYoOGCRKERFWcxMVMOcYE2K1AaNLU8DXS9arxnLOUEWbOXKXiJUNzEpqZ3JOKpnha3jkFrumEjVliDe7A==", + "dev": true, "license": "MIT", "dependencies": { - "@types/hast": "^2.0.0", - "@types/unist": "^2.0.0", - "hastscript": "^7.0.0", - "property-information": "^6.0.0", - "vfile": "^5.0.0", - "vfile-location": "^4.0.0", - "web-namespaces": "^2.0.0" + "@types/hast": "^3.0.0" }, "funding": { "type": "opencollective", "url": "https://opencollective.com/unified" } }, - "node_modules/hast-util-from-parse5/node_modules/@types/hast": { - "version": "2.3.10", - "resolved": "https://registry.npmjs.org/@types/hast/-/hast-2.3.10.tgz", - "integrity": "sha512-McWspRw8xx8J9HurkVBfYj0xKoE25tOFlHGdx4MJ5xORQrMGZNqJhVQWaIbm6Oyla5kYOXtDiopzKRJzEOkwJw==", + "node_modules/hast-util-to-html": { + "version": "9.0.3", + "resolved": "https://registry.npmjs.org/hast-util-to-html/-/hast-util-to-html-9.0.3.tgz", + "integrity": "sha512-M17uBDzMJ9RPCqLMO92gNNUDuBSq10a25SDBI08iCCxmorf4Yy6sYHK57n9WAbRAAaU+DuR4W6GN9K4DFZesYg==", + "dev": true, "license": "MIT", "dependencies": { - "@types/unist": "^2" - } - }, - "node_modules/hast-util-from-parse5/node_modules/is-buffer": { - "version": "2.0.5", - "resolved": "https://registry.npmjs.org/is-buffer/-/is-buffer-2.0.5.tgz", - "integrity": "sha512-i2R6zNFDwgEHJyQUtJEk0XFi1i0dPFn/oqjK3/vPCcDeJvW5NQ83V8QbicfF1SupOaB0h8ntgBC2YiE7dfyctQ==", - "funding": [ - { - "type": "github", - "url": "https://github.com/sponsors/feross" - }, - { - "type": "patreon", - "url": "https://www.patreon.com/feross" - }, - { - "type": "consulting", - "url": "https://feross.org/support" - } - ], - "license": "MIT", - "engines": { - "node": ">=4" - } - }, - "node_modules/hast-util-from-parse5/node_modules/unist-util-stringify-position": { - "version": "3.0.3", - "resolved": "https://registry.npmjs.org/unist-util-stringify-position/-/unist-util-stringify-position-3.0.3.tgz", - "integrity": "sha512-k5GzIBZ/QatR8N5X2y+drfpWG8IDBzdnVj6OInRNWm1oXrzydiaAT2OQiA8DPRRZyAKb9b6I2a6PxYklZD0gKg==", - "license": "MIT", - "dependencies": { - "@types/unist": "^2.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/hast-util-from-parse5/node_modules/vfile": { - "version": "5.3.7", - "resolved": "https://registry.npmjs.org/vfile/-/vfile-5.3.7.tgz", - "integrity": "sha512-r7qlzkgErKjobAmyNIkkSpizsFPYiUPuJb5pNW1RB4JcYVZhs4lIbVqk8XPk033CV/1z8ss5pkax8SuhGpcG8g==", - "license": "MIT", - "dependencies": { - "@types/unist": "^2.0.0", - "is-buffer": "^2.0.0", - "unist-util-stringify-position": "^3.0.0", - "vfile-message": "^3.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/hast-util-from-parse5/node_modules/vfile-location": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/vfile-location/-/vfile-location-4.1.0.tgz", - "integrity": "sha512-YF23YMyASIIJXpktBa4vIGLJ5Gs88UB/XePgqPmTa7cDA+JeO3yclbpheQYCHjVHBn/yePzrXuygIL+xbvRYHw==", - "license": "MIT", - "dependencies": { - "@types/unist": "^2.0.0", - "vfile": "^5.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/hast-util-from-parse5/node_modules/vfile-message": { - "version": "3.1.4", - "resolved": "https://registry.npmjs.org/vfile-message/-/vfile-message-3.1.4.tgz", - "integrity": "sha512-fa0Z6P8HUrQN4BZaX05SIVXic+7kE3b05PWAtPuYP9QLHsLKYR7/AlLW3NtOrpXRLeawpDLMsVkmk5DG0NXgWw==", - "license": "MIT", - "dependencies": { - "@types/unist": "^2.0.0", - "unist-util-stringify-position": "^3.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/hast-util-parse-selector": { - "version": "3.1.1", - "resolved": "https://registry.npmjs.org/hast-util-parse-selector/-/hast-util-parse-selector-3.1.1.tgz", - "integrity": "sha512-jdlwBjEexy1oGz0aJ2f4GKMaVKkA9jwjr4MjAAI22E5fM/TXVZHuS5OpONtdeIkRKqAaryQ2E9xNQxijoThSZA==", - "license": "MIT", - "dependencies": { - "@types/hast": "^2.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/hast-util-parse-selector/node_modules/@types/hast": { - "version": "2.3.10", - "resolved": "https://registry.npmjs.org/@types/hast/-/hast-2.3.10.tgz", - "integrity": "sha512-McWspRw8xx8J9HurkVBfYj0xKoE25tOFlHGdx4MJ5xORQrMGZNqJhVQWaIbm6Oyla5kYOXtDiopzKRJzEOkwJw==", - "license": "MIT", - "dependencies": { - "@types/unist": "^2" - } - }, - "node_modules/hast-util-to-html": { - "version": "9.0.3", - "resolved": "https://registry.npmjs.org/hast-util-to-html/-/hast-util-to-html-9.0.3.tgz", - "integrity": "sha512-M17uBDzMJ9RPCqLMO92gNNUDuBSq10a25SDBI08iCCxmorf4Yy6sYHK57n9WAbRAAaU+DuR4W6GN9K4DFZesYg==", - "license": "MIT", - "dependencies": { - "@types/hast": "^3.0.0", - "@types/unist": "^3.0.0", - "ccount": "^2.0.0", - "comma-separated-tokens": "^2.0.0", - "hast-util-whitespace": "^3.0.0", - "html-void-elements": "^3.0.0", - "mdast-util-to-hast": "^13.0.0", - "property-information": "^6.0.0", - "space-separated-tokens": "^2.0.0", - "stringify-entities": "^4.0.0", - "zwitch": "^2.0.4" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" + "@types/hast": "^3.0.0", + "@types/unist": "^3.0.0", + "ccount": "^2.0.0", + "comma-separated-tokens": "^2.0.0", + "hast-util-whitespace": "^3.0.0", + "html-void-elements": "^3.0.0", + "mdast-util-to-hast": "^13.0.0", + "property-information": "^6.0.0", + "space-separated-tokens": "^2.0.0", + "stringify-entities": "^4.0.0", + "zwitch": "^2.0.4" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" } }, "node_modules/hast-util-to-html/node_modules/@types/unist": { "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/hast-util-whitespace": { "version": "3.0.0", "resolved": "https://registry.npmjs.org/hast-util-whitespace/-/hast-util-whitespace-3.0.0.tgz", "integrity": "sha512-88JUN06ipLwsnv+dVn+OIYOvAuvBMy/Qoi6O7mQHxdPXpjy+Cd6xRkWwux7DKO+4sYILtLBRIKgsdpS2gQc7qw==", + "dev": true, "license": "MIT", "dependencies": { "@types/hast": "^3.0.0" @@ -3118,14 +3179,15 @@ } }, "node_modules/hastscript": { - "version": "7.2.0", - "resolved": "https://registry.npmjs.org/hastscript/-/hastscript-7.2.0.tgz", - "integrity": "sha512-TtYPq24IldU8iKoJQqvZOuhi5CyCQRAbvDOX0x1eW6rsHSxa/1i2CCiptNTotGHJ3VoHRGmqiv6/D3q113ikkw==", + "version": "8.0.0", + "resolved": "https://registry.npmjs.org/hastscript/-/hastscript-8.0.0.tgz", + "integrity": "sha512-dMOtzCEd3ABUeSIISmrETiKuyydk1w0pa+gE/uormcTpSYuaNJPbX1NU3JLyscSLjwAQM8bWMhhIlnCqnRvDTw==", + "dev": true, "license": "MIT", "dependencies": { - "@types/hast": "^2.0.0", + "@types/hast": "^3.0.0", "comma-separated-tokens": "^2.0.0", - "hast-util-parse-selector": "^3.0.0", + "hast-util-parse-selector": "^4.0.0", "property-information": "^6.0.0", "space-separated-tokens": "^2.0.0" }, @@ -3134,19 +3196,11 @@ "url": "https://opencollective.com/unified" } }, - "node_modules/hastscript/node_modules/@types/hast": { - "version": "2.3.10", - "resolved": "https://registry.npmjs.org/@types/hast/-/hast-2.3.10.tgz", - "integrity": "sha512-McWspRw8xx8J9HurkVBfYj0xKoE25tOFlHGdx4MJ5xORQrMGZNqJhVQWaIbm6Oyla5kYOXtDiopzKRJzEOkwJw==", - "license": "MIT", - "dependencies": { - "@types/unist": "^2" - } - }, "node_modules/hosted-git-info": { "version": "7.0.2", "resolved": "https://registry.npmjs.org/hosted-git-info/-/hosted-git-info-7.0.2.tgz", "integrity": "sha512-puUZAUKT5m8Zzvs72XWy3HtvVbTWljRE66cP60bxJzAqf2DgICo7lYTY2IHUmLnNpjYvw5bvmoHvPc0QO2a62w==", + "dev": true, "license": "ISC", "dependencies": { "lru-cache": "^10.0.1" @@ -3159,6 +3213,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/html-void-elements/-/html-void-elements-3.0.0.tgz", "integrity": "sha512-bEqo66MRXsUGxWHV5IP0PUiAWwoEjba4VCzg0LjFJBpchPaTfyfCKTG6bc5F8ucKec3q5y6qOdGyYTSBEvhCrg==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -3169,6 +3224,7 @@ "version": "9.1.0", "resolved": "https://registry.npmjs.org/htmlparser2/-/htmlparser2-9.1.0.tgz", "integrity": "sha512-5zfg6mHUoaer/97TxnGpxmbR7zJtPwIYFMZ/H5ucTlPZhKvtum05yiPK3Mgai3a0DyVxv7qYqoweaEd2nrYQzQ==", + "dev": true, "funding": [ "https://github.com/fb55/htmlparser2?sponsor=1", { @@ -3188,6 +3244,7 @@ "version": "0.6.3", "resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.6.3.tgz", "integrity": "sha512-4fCk79wshMdzMp2rH06qWrJE4iolqLhCUH+OiuIgU++RB0+94NlDL81atO7GX55uUKueo0txHNtvEyI6D7WdMw==", + "dev": true, "license": "MIT", "dependencies": { "safer-buffer": ">= 2.1.2 < 3.0.0" @@ -3200,6 +3257,7 @@ "version": "1.2.1", "resolved": "https://registry.npmjs.org/ieee754/-/ieee754-1.2.1.tgz", "integrity": "sha512-dcyqhDvX1C46lXZcVqCpK+FtMRQVdIMN6/Df5js2zouUsqG7I6sFxitIC+7KYK29KdXOLHdu9zL4sFnoVQnqaA==", + "dev": true, "funding": [ { "type": "github", @@ -3220,6 +3278,7 @@ "version": "5.3.1", "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.3.1.tgz", "integrity": "sha512-5Fytz/IraMjqpwfd34ke28PTVMjZjJG2MPn5t7OE4eUCUNf8BAa7b5WUS9/Qvr6mwOQS7Mk6vdsMno5he+T8Xw==", + "dev": true, "license": "MIT", "engines": { "node": ">= 4" @@ -3229,6 +3288,7 @@ "version": "3.3.0", "resolved": "https://registry.npmjs.org/import-fresh/-/import-fresh-3.3.0.tgz", "integrity": "sha512-veYYhQa+D1QBKznvhUHxb8faxlrwUnxseDAbAp457E0wLNio2bOSKnjYDhMj+YiAq61xrMGhQk9iXVk5FzgQMw==", + "dev": true, "license": "MIT", "dependencies": { "parent-module": "^1.0.0", @@ -3245,6 +3305,7 @@ "version": "4.1.0", "resolved": "https://registry.npmjs.org/import-meta-resolve/-/import-meta-resolve-4.1.0.tgz", "integrity": "sha512-I6fiaX09Xivtk+THaMfAwnA3MVA5Big1WHF1Dfx9hFuvNIWpXnorlkzhcQf6ehrqQiiZECRt1poOAkPmer3ruw==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -3255,6 +3316,7 @@ "version": "0.1.4", "resolved": "https://registry.npmjs.org/imurmurhash/-/imurmurhash-0.1.4.tgz", "integrity": "sha512-JmXMZ6wuvDmLiHEml9ykzqO6lwFbof0GG4IkcGaENdCRDDmMVnny7s5HsIgHCbaq0w2MyPhDqkhTUgS2LU2PHA==", + "dev": true, "license": "MIT", "engines": { "node": ">=0.8.19" @@ -3264,12 +3326,14 @@ "version": "2.0.4", "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz", "integrity": "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==", + "dev": true, "license": "ISC" }, "node_modules/ini": { "version": "4.1.3", "resolved": "https://registry.npmjs.org/ini/-/ini-4.1.3.tgz", "integrity": "sha512-X7rqawQBvfdjS10YU1y1YVreA3SsLrW9dX2CewP2EbBJM4ypVNLDkO5y04gejPwKIY9lR+7r9gn3rFPt/kmWFg==", + "dev": true, "license": "ISC", "engines": { "node": "^14.17.0 || ^16.13.0 || >=18.0.0" @@ -3279,6 +3343,7 @@ "version": "8.2.6", "resolved": "https://registry.npmjs.org/inquirer/-/inquirer-8.2.6.tgz", "integrity": "sha512-M1WuAmb7pn9zdFRtQYk26ZBoY043Sse0wVDdk4Bppr+JOXyQYybdtvK+l9wUibhtjdjvtoiNy8tk+EgsYIUqKg==", + "dev": true, "license": "MIT", "dependencies": { "ansi-escapes": "^4.2.1", @@ -3320,6 +3385,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/is-alphabetical/-/is-alphabetical-2.0.1.tgz", "integrity": "sha512-FWyyY60MeTNyeSRpkM2Iry0G9hpr7/9kD40mD/cGQEuilcZYS4okz8SN2Q6rLCJ8gbCt6fN+rC+6tMGS99LaxQ==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -3330,6 +3396,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/is-alphanumerical/-/is-alphanumerical-2.0.1.tgz", "integrity": "sha512-hmbYhX/9MUMF5uh7tOXyK/n0ZvWpad5caBA17GsC6vyuCqaWliRG5K1qS9inmUhEMaOBIW7/whAnSwveW/LtZw==", + "dev": true, "license": "MIT", "dependencies": { "is-alphabetical": "^2.0.0", @@ -3361,6 +3428,7 @@ "version": "0.2.1", "resolved": "https://registry.npmjs.org/is-arrayish/-/is-arrayish-0.2.1.tgz", "integrity": "sha512-zz06S8t0ozoDXMG+ube26zeCTNXcKIPJZJi8hBrF4idCLms4CG9QtK7qBl1boi5ODzFpjswb5JPmHCbMpjaYzg==", + "dev": true, "license": "MIT" }, "node_modules/is-bigint": { @@ -3380,6 +3448,7 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz", "integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==", + "dev": true, "license": "MIT", "dependencies": { "binary-extensions": "^2.0.0" @@ -3409,6 +3478,7 @@ "version": "1.1.6", "resolved": "https://registry.npmjs.org/is-buffer/-/is-buffer-1.1.6.tgz", "integrity": "sha512-NcdALwpXkTm5Zvvbk7owOUSvVvBKDgKP5/ewfXEznmQFfs4ZRmanOeKBTjRVjka3QFoN6XJ+9F3USqfHqTaU5w==", + "dev": true, "license": "MIT" }, "node_modules/is-callable": { @@ -3476,6 +3546,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/is-decimal/-/is-decimal-2.0.1.tgz", "integrity": "sha512-AAB9hiomQs5DXWcRB1rqsxGUstbRroFOPPVAomNk/3XHR5JyEZChOyTWe2oayKnsSsr/kcGqF+z6yuH6HHpN0A==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -3486,12 +3557,14 @@ "version": "1.2.0", "resolved": "https://registry.npmjs.org/is-empty/-/is-empty-1.2.0.tgz", "integrity": "sha512-F2FnH/otLNJv0J6wc73A5Xo7oHLNnqplYqZhUu01tD54DIPvxIRSTSLkrUB/M0nHO4vo1O9PDfN4KoTxCzLh/w==", + "dev": true, "license": "MIT" }, "node_modules/is-extglob": { "version": "2.1.1", "resolved": "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz", "integrity": "sha512-SbKbANkN603Vi4jEZv49LeVJMn4yGwsbzZworEoyEiutsN3nJYdbO36zfhGJ6QEDpOZIFkDtnq5JRxmvl3jsoQ==", + "dev": true, "license": "MIT", "engines": { "node": ">=0.10.0" @@ -3501,6 +3574,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz", "integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==", + "dev": true, "license": "MIT", "engines": { "node": ">=8" @@ -3510,6 +3584,7 @@ "version": "4.0.3", "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz", "integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==", + "dev": true, "license": "MIT", "dependencies": { "is-extglob": "^2.1.1" @@ -3522,6 +3597,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/is-hexadecimal/-/is-hexadecimal-2.0.1.tgz", "integrity": "sha512-DgZQp241c8oO6cA1SbTEWiXeoxV42vlcJxgH+B3hi1AiqqKruZR3ZGF8In3fj4+/y/7rHvlOZLZtgJ/4ttYGZg==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -3532,6 +3608,7 @@ "version": "1.0.0", "resolved": "https://registry.npmjs.org/is-interactive/-/is-interactive-1.0.0.tgz", "integrity": "sha512-2HvIEKRoqS62guEC+qBjpvRubdX910WCMuJTZ+I9yvqKU2/12eSL549HMwtabb4oupdj2sMP50k+XJfB/8JE6w==", + "dev": true, "license": "MIT", "engines": { "node": ">=8" @@ -3554,6 +3631,7 @@ "version": "7.0.0", "resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz", "integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==", + "dev": true, "license": "MIT", "engines": { "node": ">=0.12.0" @@ -3579,6 +3657,7 @@ "version": "4.1.0", "resolved": "https://registry.npmjs.org/is-plain-obj/-/is-plain-obj-4.1.0.tgz", "integrity": "sha512-+Pgi+vMuUNkJyExiMBt5IlFoMyKnr5zhJ4Uspz58WOhBF5QoIZkFyNHIbBAtHwzVAgk5RtndVNsDRN61/mmDqg==", + "dev": true, "license": "MIT", "engines": { "node": ">=12" @@ -3672,6 +3751,7 @@ "version": "0.1.0", "resolved": "https://registry.npmjs.org/is-unicode-supported/-/is-unicode-supported-0.1.0.tgz", "integrity": "sha512-knxG2q4UC3u8stRGyAVJCOdxFmv5DZiRcdlIaAQXAbSfJya+OhopNotLQrstBhququ4ZpuKbDc/8S6mgXgPFPw==", + "dev": true, "license": "MIT", "engines": { "node": ">=10" @@ -3704,12 +3784,14 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/isexe/-/isexe-2.0.0.tgz", "integrity": "sha512-RHxMLp9lnKHGHRng9QFhRCMbYAcVpn69smSGcq3f36xjgVVWThj4qqLbTLlq7Ssj8B+fIQ1EuCEGI2lKsyQeIw==", + "dev": true, "license": "ISC" }, "node_modules/jackspeak": { "version": "3.4.3", "resolved": "https://registry.npmjs.org/jackspeak/-/jackspeak-3.4.3.tgz", "integrity": "sha512-OGlZQpz2yfahA/Rd1Y8Cd9SIEsqvXkLVoSw/cgwhnhFMDbsQFeZYoJJ7bIZBS9BcamUW96asq/npPWugM+RQBw==", + "dev": true, "license": "BlueOak-1.0.0", "dependencies": { "@isaacs/cliui": "^8.0.2" @@ -3725,12 +3807,14 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/js-tokens/-/js-tokens-4.0.0.tgz", "integrity": "sha512-RdJUflcE3cUzKiMqQgsCu06FPu9UdIJO0beYbPhHN4k6apgJtifcoCtT9bcxOpYBtpD2kCM6Sbzg4CausW/PKQ==", + "dev": true, "license": "MIT" }, "node_modules/js-yaml": { "version": "4.1.0", "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz", "integrity": "sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==", + "dev": true, "license": "MIT", "dependencies": { "argparse": "^2.0.1" @@ -3743,12 +3827,14 @@ "version": "3.0.1", "resolved": "https://registry.npmjs.org/json-buffer/-/json-buffer-3.0.1.tgz", "integrity": "sha512-4bV5BfR2mqfQTJm+V5tPPdf+ZpuhiIvTuAB5g8kcrXOZpTT/QwwVRWBywX1ozr6lEuPdbHxwaJlm9G6mI2sfSQ==", + "dev": true, "license": "MIT" }, "node_modules/json-parse-even-better-errors": { "version": "3.0.2", "resolved": "https://registry.npmjs.org/json-parse-even-better-errors/-/json-parse-even-better-errors-3.0.2.tgz", "integrity": "sha512-fi0NG4bPjCHunUJffmLd0gxssIgkNmArMvis4iNah6Owg1MCJjWhEcDLmsK6iGkJq3tHwbDkTlce70/tmXN4cQ==", + "dev": true, "license": "MIT", "engines": { "node": "^14.17.0 || ^16.13.0 || >=18.0.0" @@ -3758,12 +3844,14 @@ "version": "0.4.1", "resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-0.4.1.tgz", "integrity": "sha512-xbbCH5dCYU5T8LcEhhuh7HJ88HXuW3qsI3Y0zOZFKfZEHcpWiHU/Jxzk629Brsab/mMiHQti9wMP+845RPe3Vg==", + "dev": true, "license": "MIT" }, "node_modules/json-stable-stringify-without-jsonify": { "version": "1.0.1", "resolved": "https://registry.npmjs.org/json-stable-stringify-without-jsonify/-/json-stable-stringify-without-jsonify-1.0.1.tgz", "integrity": "sha512-Bdboy+l7tA3OGW6FjyFHWkP5LuByj1Tk33Ljyq0axyzdk9//JSi2u3fP1QSmd1KNwq6VOKYGlAu87CisVir6Pw==", + "dev": true, "license": "MIT" }, "node_modules/json5": { @@ -3783,6 +3871,7 @@ "version": "6.1.0", "resolved": "https://registry.npmjs.org/jsonfile/-/jsonfile-6.1.0.tgz", "integrity": "sha512-5dgndWOriYSm5cnYaJNhalLNDKOqFwyDB/rr1E9ZsGciGvKPs8R2xYGCacuf3z6K1YKDz182fd+fY3cn3pMqXQ==", + "dev": true, "license": "MIT", "dependencies": { "universalify": "^2.0.0" @@ -3795,6 +3884,7 @@ "version": "4.5.4", "resolved": "https://registry.npmjs.org/keyv/-/keyv-4.5.4.tgz", "integrity": "sha512-oxVHkHR/EJf2CNXnWxRLW6mg7JyCCUcG0DtEGmL2ctUo1PNTin1PUil+r/+4r5MpVgC/fn1kjsx7mjSujKqIpw==", + "dev": true, "license": "MIT", "dependencies": { "json-buffer": "3.0.1" @@ -3804,6 +3894,7 @@ "version": "1.0.0", "resolved": "https://registry.npmjs.org/levenshtein-edit-distance/-/levenshtein-edit-distance-1.0.0.tgz", "integrity": "sha512-gpgBvPn7IFIAL32f0o6Nsh2g+5uOvkt4eK9epTfgE4YVxBxwVhJ/p1888lMm/u8mXdu1ETLSi6zeEmkBI+0F3w==", + "dev": true, "license": "MIT", "bin": { "levenshtein-edit-distance": "cli.js" @@ -3813,6 +3904,7 @@ "version": "0.4.1", "resolved": "https://registry.npmjs.org/levn/-/levn-0.4.1.tgz", "integrity": "sha512-+bT2uH4E5LGE7h/n3evcS/sQlJXCpIp6ym8OWJ5eV6+67Dsql/LaaT7qJBAt2rzfoa/5QBGBhxDix1dMt2kQKQ==", + "dev": true, "license": "MIT", "dependencies": { "prelude-ls": "^1.2.1", @@ -3826,6 +3918,7 @@ "version": "2.0.4", "resolved": "https://registry.npmjs.org/lines-and-columns/-/lines-and-columns-2.0.4.tgz", "integrity": "sha512-wM1+Z03eypVAVUCE7QdSqpVIvelbOakn1M0bPDoA4SGWPx3sNDVUiMo3L6To6WWGClB7VyXnhQ4Sn7gxiJbE6A==", + "dev": true, "license": "MIT", "engines": { "node": "^12.20.0 || ^14.13.1 || >=16.0.0" @@ -3835,6 +3928,7 @@ "version": "6.0.3", "resolved": "https://registry.npmjs.org/load-plugin/-/load-plugin-6.0.3.tgz", "integrity": "sha512-kc0X2FEUZr145odl68frm+lMJuQ23+rTXYmR6TImqPtbpmXC4vVXbWKDQ9IzndA0HfyQamWfKLhzsqGSTxE63w==", + "dev": true, "license": "MIT", "dependencies": { "@npmcli/config": "^8.0.0", @@ -3849,6 +3943,7 @@ "version": "6.0.0", "resolved": "https://registry.npmjs.org/locate-path/-/locate-path-6.0.0.tgz", "integrity": "sha512-iPZK6eYjbxRu3uB4/WZ3EsEIMJFMqAoopl3R+zuq0UjcAm/MO6KCweDgPfP3elTztoKP3KtnVHxTn2NHBSDVUw==", + "dev": true, "license": "MIT", "dependencies": { "p-locate": "^5.0.0" @@ -3864,30 +3959,35 @@ "version": "4.17.21", "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz", "integrity": "sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg==", + "dev": true, "license": "MIT" }, "node_modules/lodash.chunk": { "version": "4.2.0", "resolved": "https://registry.npmjs.org/lodash.chunk/-/lodash.chunk-4.2.0.tgz", "integrity": "sha512-ZzydJKfUHJwHa+hF5X66zLFCBrWn5GeF28OHEr4WVWtNDXlQ/IjWKPBiikqKo2ne0+v6JgCgJ0GzJp8k8bHC7w==", + "dev": true, "license": "MIT" }, "node_modules/lodash.get": { "version": "4.4.2", "resolved": "https://registry.npmjs.org/lodash.get/-/lodash.get-4.4.2.tgz", "integrity": "sha512-z+Uw/vLuy6gQe8cfaFWD7p0wVv8fJl3mbzXh33RS+0oW2wvUqiRXiQ69gLWSLpgB5/6sU+r6BlQR0MBILadqTQ==", + "dev": true, "license": "MIT" }, "node_modules/lodash.merge": { "version": "4.6.2", "resolved": "https://registry.npmjs.org/lodash.merge/-/lodash.merge-4.6.2.tgz", "integrity": "sha512-0KpjqXRVvrYyCsX1swR/XTK0va6VQkQM6MNo7PqW77ByjAhoARA8EfrP1N4+KlKj8YS0ZUCtRT/YUuhyYDujIQ==", + "dev": true, "license": "MIT" }, "node_modules/log-symbols": { "version": "4.1.0", "resolved": "https://registry.npmjs.org/log-symbols/-/log-symbols-4.1.0.tgz", "integrity": "sha512-8XPvpAA8uyhfteu8pIvQxpJZ7SYYdpUivZpGy6sFsBuKRY/7rQGavedeB8aK+Zkyq6upMFVL/9AW6vOYzfRyLg==", + "dev": true, "license": "MIT", "dependencies": { "chalk": "^4.1.0", @@ -3904,6 +4004,7 @@ "version": "3.1.0", "resolved": "https://registry.npmjs.org/longest-streak/-/longest-streak-3.1.0.tgz", "integrity": "sha512-9Ri+o0JYgehTaVBBDoMqIl8GXtbWg711O3srftcHhZ0dqnETqLaoIK0x17fUw9rFSlK/0NlsKe0Ahhyl5pXE2g==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -3914,12 +4015,27 @@ "version": "10.4.3", "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-10.4.3.tgz", "integrity": "sha512-JNAzZcXrCt42VGLuYz0zfAzDfAvJWW6AfYlDBQyDV5DClI2m5sAmK+OIO7s59XfsRsWHp02jAJrRadPRGTt6SQ==", + "dev": true, "license": "ISC" }, + "node_modules/markdown-extensions": { + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/markdown-extensions/-/markdown-extensions-2.0.0.tgz", + "integrity": "sha512-o5vL7aDWatOTX8LzaS1WMoaoxIiLRQJuIKKe2wAw6IeULDHaqbiqiggmx+pKvZDb1Sj+pE46Sn1T7lCqfFtg1Q==", + "dev": true, + "license": "MIT", + "engines": { + "node": ">=16" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, "node_modules/markdown-table": { "version": "3.0.3", "resolved": "https://registry.npmjs.org/markdown-table/-/markdown-table-3.0.3.tgz", "integrity": "sha512-Z1NL3Tb1M9wH4XESsCDEksWoKTdlUafKc4pt0GRwjUyXaCFZ+dc3g2erqB6zm3szA2IUSi7VnPI+o/9jnxh9hw==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -3930,6 +4046,7 @@ "version": "2.3.0", "resolved": "https://registry.npmjs.org/md5/-/md5-2.3.0.tgz", "integrity": "sha512-T1GITYmFaKuO91vxyoQMFETst+O71VUPEU3ze5GNzDm0OWdP8v1ziTaAEPUr/3kLsY3Sftgz242A1SetQiDL7g==", + "dev": true, "license": "BSD-3-Clause", "dependencies": { "charenc": "0.0.2", @@ -3941,6 +4058,7 @@ "version": "1.1.1", "resolved": "https://registry.npmjs.org/mdast-builder/-/mdast-builder-1.1.1.tgz", "integrity": "sha512-a3KBk/LmYD6wKsWi8WJrGU/rXR4yuF4Men0JO0z6dSZCm5FrXXWTRDjqK0vGSqa+1M6p9edeuypZAZAzSehTUw==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "@types/unist": "^2.0.3" @@ -3950,6 +4068,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/mdast-comment-marker/-/mdast-comment-marker-3.0.0.tgz", "integrity": "sha512-bt08sLmTNg00/UtVDiqZKocxqvQqqyQZAg1uaRuO/4ysXV5motg7RolF5o5yy/sY1rG0v2XgZEqFWho1+2UquA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -3964,6 +4083,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/mdast-util-directive/-/mdast-util-directive-3.0.0.tgz", "integrity": "sha512-JUpYOqKI4mM3sZcNxmF/ox04XYFFkNwr0CFlrQIkCwbvH0xzMCqkMqAde9wRd80VAhaUrwFwKm2nxretdT1h7Q==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -3984,12 +4104,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/mdast-util-find-and-replace": { "version": "3.0.1", "resolved": "https://registry.npmjs.org/mdast-util-find-and-replace/-/mdast-util-find-and-replace-3.0.1.tgz", "integrity": "sha512-SG21kZHGC3XRTSUhtofZkBzZTJNM5ecCi0SK2IMKmSXR8vO3peL+kb1O0z7Zl83jKtutG4k5Wv/W7V3/YHvzPA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -4006,6 +4128,7 @@ "version": "5.0.0", "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-5.0.0.tgz", "integrity": "sha512-/veY75JbMK4j1yjvuUxuVsiS/hr/4iHs9FTT6cgTexxdE0Ly/glccBAkloH/DofkjRbZU3bnoj38mOmhkZ0lHw==", + "dev": true, "license": "MIT", "engines": { "node": ">=12" @@ -4018,6 +4141,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/mdast-util-from-markdown/-/mdast-util-from-markdown-2.0.1.tgz", "integrity": "sha512-aJEUyzZ6TzlsX2s5B4Of7lN7EQtAxvtradMMglCQDyaTFgse6CmtmdJ15ElnVRlCg1vpNyVtbem0PWzlNieZsA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -4042,12 +4166,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/mdast-util-gfm": { "version": "3.0.0", "resolved": "https://registry.npmjs.org/mdast-util-gfm/-/mdast-util-gfm-3.0.0.tgz", "integrity": "sha512-dgQEX5Amaq+DuUqf26jJqSK9qgixgd6rYDHAv4aTBuA92cTknZlKpPfa86Z/s8Dj8xsAQpFfBmPUHWJBWqS4Bw==", + "dev": true, "license": "MIT", "dependencies": { "mdast-util-from-markdown": "^2.0.0", @@ -4067,6 +4193,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/mdast-util-gfm-autolink-literal/-/mdast-util-gfm-autolink-literal-2.0.1.tgz", "integrity": "sha512-5HVP2MKaP6L+G6YaxPNjuL0BPrq9orG3TsrZ9YXbA3vDw/ACI4MEsnoDpn6ZNm7GnZgtAcONJyPhOP8tNJQavQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -4084,6 +4211,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/mdast-util-gfm-footnote/-/mdast-util-gfm-footnote-2.0.0.tgz", "integrity": "sha512-5jOT2boTSVkMnQ7LTrd6n/18kqwjmuYqo7JUPe+tRCY6O7dAuTFMtTPauYYrMPpox9hlN0uOx/FL8XvEfG9/mQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -4101,6 +4229,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/mdast-util-gfm-strikethrough/-/mdast-util-gfm-strikethrough-2.0.0.tgz", "integrity": "sha512-mKKb915TF+OC5ptj5bJ7WFRPdYtuHv0yTRxK2tJvi+BDqbkiG7h7u/9SI89nRAYcmap2xHQL9D+QG/6wSrTtXg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -4116,6 +4245,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/mdast-util-gfm-table/-/mdast-util-gfm-table-2.0.0.tgz", "integrity": "sha512-78UEvebzz/rJIxLvE7ZtDd/vIQ0RHv+3Mh5DR96p7cS7HsBhYIICDBCu8csTNWNO6tBWfqXPWekRuj2FNOGOZg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -4133,6 +4263,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/mdast-util-gfm-task-list-item/-/mdast-util-gfm-task-list-item-2.0.0.tgz", "integrity": "sha512-IrtvNvjxC1o06taBAVJznEnkiHxLFTzgonUdy8hzFVeDun0uTjxxrRGVaNFqkU1wJR3RBPEfsxmU6jDWPofrTQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -4149,6 +4280,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/mdast-util-heading-style/-/mdast-util-heading-style-3.0.0.tgz", "integrity": "sha512-tsUfM9Kj9msjlemA/38Z3pvraQay880E3zP2NgIthMoGcpU9bcPX9oSM6QC/+eFXGGB4ba+VCB1dKAPHB7Veug==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0" @@ -4162,6 +4294,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/mdast-util-mdx/-/mdast-util-mdx-3.0.0.tgz", "integrity": "sha512-JfbYLAW7XnYTTbUsmpu0kdBUVe+yKVJZBItEjwyYJiDJuZ9w4eeaqks4HQO+R7objWgS2ymV60GYpI14Ug554w==", + "dev": true, "license": "MIT", "dependencies": { "mdast-util-from-markdown": "^2.0.0", @@ -4179,6 +4312,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/mdast-util-mdx-expression/-/mdast-util-mdx-expression-2.0.1.tgz", "integrity": "sha512-J6f+9hUp+ldTZqKRSg7Vw5V6MqjATc+3E4gf3CFNcuZNWD8XdyI6zQ8GqH7f8169MM6P7hMBRDVGnn7oHB9kXQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/estree-jsx": "^1.0.0", @@ -4197,6 +4331,7 @@ "version": "3.1.3", "resolved": "https://registry.npmjs.org/mdast-util-mdx-jsx/-/mdast-util-mdx-jsx-3.1.3.tgz", "integrity": "sha512-bfOjvNt+1AcbPLTFMFWY149nJz0OjmewJs3LQQ5pIyVGxP4CdOqNVJL6kTaM5c68p8q82Xv3nCyFfUnuEcH3UQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/estree-jsx": "^1.0.0", @@ -4221,12 +4356,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/mdast-util-mdxjs-esm": { "version": "2.0.1", "resolved": "https://registry.npmjs.org/mdast-util-mdxjs-esm/-/mdast-util-mdxjs-esm-2.0.1.tgz", "integrity": "sha512-EcmOpxsZ96CvlP03NghtH1EsLtr0n9Tm4lPUJUBccV9RwUOneqSycg19n5HGzCf+10LozMRSObtVr3ee1WoHtg==", + "dev": true, "license": "MIT", "dependencies": { "@types/estree-jsx": "^1.0.0", @@ -4245,6 +4382,7 @@ "version": "4.1.0", "resolved": "https://registry.npmjs.org/mdast-util-phrasing/-/mdast-util-phrasing-4.1.0.tgz", "integrity": "sha512-TqICwyvJJpBwvGAMZjj4J2n0X8QWp21b9l0o7eXyVJ25YNWYbJDVIyD1bZXE6WtV6RmKJVYmQAKWa0zWOABz2w==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -4259,6 +4397,7 @@ "version": "13.2.0", "resolved": "https://registry.npmjs.org/mdast-util-to-hast/-/mdast-util-to-hast-13.2.0.tgz", "integrity": "sha512-QGYKEuUsYT9ykKBCMOEDLsU5JRObWQusAolFMeko/tYPufNkRffBAQjIE+99jbA87xv6FgmjLtwjh9wBWajwAA==", + "dev": true, "license": "MIT", "dependencies": { "@types/hast": "^3.0.0", @@ -4280,6 +4419,7 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/mdast-util-to-markdown/-/mdast-util-to-markdown-2.1.0.tgz", "integrity": "sha512-SR2VnIEdVNCJbP6y7kVTJgPLifdr8WEU440fQec7qHoHOUz/oJ2jmNRqdDQ3rbiStOXb2mCDGTuwsK5OPUgYlQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -4300,12 +4440,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/mdast-util-to-string": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/mdast-util-to-string/-/mdast-util-to-string-4.0.0.tgz", "integrity": "sha512-0H44vDimn51F0YwvxSJSm0eCDOJTRlmN0R1yBh4HLj9wiV1Dn0QoXGbvFAWj2hSItVTlCmBF1hqKlIyUBVFLPg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0" @@ -4319,6 +4461,7 @@ "version": "1.4.1", "resolved": "https://registry.npmjs.org/merge2/-/merge2-1.4.1.tgz", "integrity": "sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==", + "dev": true, "license": "MIT", "engines": { "node": ">= 8" @@ -4328,6 +4471,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/micromark/-/micromark-4.0.0.tgz", "integrity": "sha512-o/sd0nMof8kYff+TqcDx3VSrgBTcZpSvYcAHIfHhv5VAuNmisCxjhx6YmxS8PFEpb9z5WKWKPdzf0jM23ro3RQ==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4363,6 +4507,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/micromark-core-commonmark/-/micromark-core-commonmark-2.0.1.tgz", "integrity": "sha512-CUQyKr1e///ZODyD1U3xit6zXwy1a8q2a1S1HKtIlmgvurrEpaw/Y9y6KSIbF8P59cn/NjzHyO+Q2fAyYLQrAA==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4397,6 +4542,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/micromark-extension-gfm/-/micromark-extension-gfm-3.0.0.tgz", "integrity": "sha512-vsKArQsicm7t0z2GugkCKtZehqUm31oeGBV/KVSorWSy8ZlNAv7ytjFhvaryUiCUJYqs+NoE6AFhpQvBTM6Q4w==", + "dev": true, "license": "MIT", "dependencies": { "micromark-extension-gfm-autolink-literal": "^2.0.0", @@ -4417,6 +4563,7 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/micromark-extension-gfm-autolink-literal/-/micromark-extension-gfm-autolink-literal-2.1.0.tgz", "integrity": "sha512-oOg7knzhicgQ3t4QCjCWgTmfNhvQbDDnJeVu9v81r7NltNCVmhPy1fJRX27pISafdjL+SVc4d3l48Gb6pbRypw==", + "dev": true, "license": "MIT", "dependencies": { "micromark-util-character": "^2.0.0", @@ -4433,6 +4580,7 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/micromark-extension-gfm-footnote/-/micromark-extension-gfm-footnote-2.1.0.tgz", "integrity": "sha512-/yPhxI1ntnDNsiHtzLKYnE3vf9JZ6cAisqVDauhp4CEHxlb4uoOTxOCJ+9s51bIB8U1N1FJ1RXOKTIlD5B/gqw==", + "dev": true, "license": "MIT", "dependencies": { "devlop": "^1.0.0", @@ -4453,6 +4601,7 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/micromark-extension-gfm-strikethrough/-/micromark-extension-gfm-strikethrough-2.1.0.tgz", "integrity": "sha512-ADVjpOOkjz1hhkZLlBiYA9cR2Anf8F4HqZUO6e5eDcPQd0Txw5fxLzzxnEkSkfnD0wziSGiv7sYhk/ktvbf1uw==", + "dev": true, "license": "MIT", "dependencies": { "devlop": "^1.0.0", @@ -4471,6 +4620,7 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/micromark-extension-gfm-table/-/micromark-extension-gfm-table-2.1.0.tgz", "integrity": "sha512-Ub2ncQv+fwD70/l4ou27b4YzfNaCJOvyX4HxXU15m7mpYY+rjuWzsLIPZHJL253Z643RpbcP1oeIJlQ/SKW67g==", + "dev": true, "license": "MIT", "dependencies": { "devlop": "^1.0.0", @@ -4488,6 +4638,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-extension-gfm-tagfilter/-/micromark-extension-gfm-tagfilter-2.0.0.tgz", "integrity": "sha512-xHlTOmuCSotIA8TW1mDIM6X2O1SiX5P9IuDtqGonFhEK0qgRI4yeC6vMxEV2dgyr2TiD+2PQ10o+cOhdVAcwfg==", + "dev": true, "license": "MIT", "dependencies": { "micromark-util-types": "^2.0.0" @@ -4501,6 +4652,7 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/micromark-extension-gfm-task-list-item/-/micromark-extension-gfm-task-list-item-2.1.0.tgz", "integrity": "sha512-qIBZhqxqI6fjLDYFTBIa4eivDMnP+OZqsNwmQ3xNLE4Cxwc+zfQEfbs6tzAo2Hjq+bh6q5F+Z8/cksrLFYWQQw==", + "dev": true, "license": "MIT", "dependencies": { "devlop": "^1.0.0", @@ -4518,6 +4670,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-factory-destination/-/micromark-factory-destination-2.0.0.tgz", "integrity": "sha512-j9DGrQLm/Uhl2tCzcbLhy5kXsgkHUrjJHg4fFAeoMRwJmJerT9aw4FEhIbZStWN8A3qMwOp1uzHr4UL8AInxtA==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4539,6 +4692,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-factory-label/-/micromark-factory-label-2.0.0.tgz", "integrity": "sha512-RR3i96ohZGde//4WSe/dJsxOX6vxIg9TimLAS3i4EhBAFx8Sm5SmqVfR8E87DPSR31nEAjZfbt91OMZWcNgdZw==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4561,6 +4715,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-factory-space/-/micromark-factory-space-2.0.0.tgz", "integrity": "sha512-TKr+LIDX2pkBJXFLzpyPyljzYK3MtmllMUMODTQJIUfDGncESaqB90db9IAUcz4AZAJFdd8U9zOp9ty1458rxg==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4581,6 +4736,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-factory-title/-/micromark-factory-title-2.0.0.tgz", "integrity": "sha512-jY8CSxmpWLOxS+t8W+FG3Xigc0RDQA9bKMY/EwILvsesiRniiVMejYTE4wumNc2f4UbAa4WsHqe3J1QS1sli+A==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4603,6 +4759,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-factory-whitespace/-/micromark-factory-whitespace-2.0.0.tgz", "integrity": "sha512-28kbwaBjc5yAI1XadbdPYHX/eDnqaUFVikLwrO7FDnKG7lpgxnvk/XGRhX/PN0mOZ+dBSZ+LgunHS+6tYQAzhA==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4625,6 +4782,7 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/micromark-util-character/-/micromark-util-character-2.1.0.tgz", "integrity": "sha512-KvOVV+X1yLBfs9dCBSopq/+G1PcgT3lAK07mC4BzXi5E7ahzMAF8oIupDDJ6mievI6F+lAATkbQQlQixJfT3aQ==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4645,6 +4803,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-util-chunked/-/micromark-util-chunked-2.0.0.tgz", "integrity": "sha512-anK8SWmNphkXdaKgz5hJvGa7l00qmcaUQoMYsBwDlSKFKjc6gjGXPDw3FNL3Nbwq5L8gE+RCbGqTw49FK5Qyvg==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4664,6 +4823,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-util-classify-character/-/micromark-util-classify-character-2.0.0.tgz", "integrity": "sha512-S0ze2R9GH+fu41FA7pbSqNWObo/kzwf8rN/+IGlW/4tC6oACOs8B++bh+i9bVyNnwCcuksbFwsBme5OCKXCwIw==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4685,6 +4845,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-util-combine-extensions/-/micromark-util-combine-extensions-2.0.0.tgz", "integrity": "sha512-vZZio48k7ON0fVS3CUgFatWHoKbbLTK/rT7pzpJ4Bjp5JjkZeasRfrS9wsBdDJK2cJLHMckXZdzPSSr1B8a4oQ==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4705,6 +4866,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/micromark-util-decode-numeric-character-reference/-/micromark-util-decode-numeric-character-reference-2.0.1.tgz", "integrity": "sha512-bmkNc7z8Wn6kgjZmVHOX3SowGmVdhYS7yBpMnuMnPzDq/6xwVA604DuOXMZTO1lvq01g+Adfa0pE2UKGlxL1XQ==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4724,6 +4886,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-util-decode-string/-/micromark-util-decode-string-2.0.0.tgz", "integrity": "sha512-r4Sc6leeUTn3P6gk20aFMj2ntPwn6qpDZqWvYmAG6NgvFTIlj4WtrAudLi65qYoaGdXYViXYw2pkmn7QnIFasA==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4746,6 +4909,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-util-encode/-/micromark-util-encode-2.0.0.tgz", "integrity": "sha512-pS+ROfCXAGLWCOc8egcBvT0kf27GoWMqtdarNfDcjb6YLuV5cM3ioG45Ys2qOVqeqSbjaKg72vU+Wby3eddPsA==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4762,6 +4926,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-util-html-tag-name/-/micromark-util-html-tag-name-2.0.0.tgz", "integrity": "sha512-xNn4Pqkj2puRhKdKTm8t1YHC/BAjx6CEwRFXntTaRf/x16aqka6ouVoutm+QdkISTlT7e2zU7U4ZdlDLJd2Mcw==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4778,6 +4943,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-util-normalize-identifier/-/micromark-util-normalize-identifier-2.0.0.tgz", "integrity": "sha512-2xhYT0sfo85FMrUPtHcPo2rrp1lwbDEEzpx7jiH2xXJLqBuy4H0GgXk5ToU8IEwoROtXuL8ND0ttVa4rNqYK3w==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4797,6 +4963,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-util-resolve-all/-/micromark-util-resolve-all-2.0.0.tgz", "integrity": "sha512-6KU6qO7DZ7GJkaCgwBNtplXCvGkJToU86ybBAUdavvgsCiG8lSSvYxr9MhwmQ+udpzywHsl4RpGJsYWG1pDOcA==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4816,6 +4983,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-util-sanitize-uri/-/micromark-util-sanitize-uri-2.0.0.tgz", "integrity": "sha512-WhYv5UEcZrbAtlsnPuChHUAsu/iBPOVaEVsntLBIdpibO0ddy8OzavZz3iL2xVvBZOpolujSliP65Kq0/7KIYw==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4837,6 +5005,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/micromark-util-subtokenize/-/micromark-util-subtokenize-2.0.1.tgz", "integrity": "sha512-jZNtiFl/1aY73yS3UGQkutD0UbhTt68qnRpw2Pifmz5wV9h8gOVsN70v+Lq/f1rKaU/W8pxRe8y8Q9FX1AOe1Q==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4859,6 +5028,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-util-symbol/-/micromark-util-symbol-2.0.0.tgz", "integrity": "sha512-8JZt9ElZ5kyTnO94muPxIGS8oyElRJaiJO8EzV6ZSyGQ1Is8xwl4Q45qU5UOg+bGH4AikWziz0iN4sFLWs8PGw==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4875,6 +5045,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/micromark-util-types/-/micromark-util-types-2.0.0.tgz", "integrity": "sha512-oNh6S2WMHWRZrmutsRmDDfkzKtxF+bc2VxLC9dvtrDIRFln627VsFP6fLMgTryGDljgLPjkrzQSDcPrjPyDJ5w==", + "dev": true, "funding": [ { "type": "GitHub Sponsors", @@ -4891,6 +5062,7 @@ "version": "4.0.8", "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.8.tgz", "integrity": "sha512-PXwfBhYu0hBCPw8Dn0E+WDYb7af3dSLVWKi3HGv84IdF4TyFoC0ysxFd0Goxw7nSv4T/PzEJQxsYsEiFCKo2BA==", + "dev": true, "license": "MIT", "dependencies": { "braces": "^3.0.3", @@ -4904,6 +5076,7 @@ "version": "2.1.0", "resolved": "https://registry.npmjs.org/mimic-fn/-/mimic-fn-2.1.0.tgz", "integrity": "sha512-OqbOk5oEQeAZ8WXWydlu9HJjz9WVdEIvamMCcXmuqUYjTknH/sqsWvhQ3vgwKFRR1HpjvNBKQ37nbJgYzGqGcg==", + "dev": true, "license": "MIT", "engines": { "node": ">=6" @@ -4913,6 +5086,7 @@ "version": "3.1.2", "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz", "integrity": "sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==", + "dev": true, "license": "ISC", "dependencies": { "brace-expansion": "^1.1.7" @@ -4935,6 +5109,7 @@ "version": "7.1.2", "resolved": "https://registry.npmjs.org/minipass/-/minipass-7.1.2.tgz", "integrity": "sha512-qOOzS1cBTWYF4BH8fVePDBOO9iptMnGUEZwNc/cMWnTV2nVLZ7VoNWEPHkYczZA0pdoA7dl6e7FL659nX9S2aw==", + "dev": true, "license": "ISC", "engines": { "node": ">=16 || 14 >=14.17" @@ -4944,24 +5119,28 @@ "version": "2.1.2", "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz", "integrity": "sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==", + "dev": true, "license": "MIT" }, "node_modules/mute-stream": { "version": "0.0.8", "resolved": "https://registry.npmjs.org/mute-stream/-/mute-stream-0.0.8.tgz", "integrity": "sha512-nnbWWOkoWyUsTjKrhgD0dcz22mdkSnpYqbEjIm2nhwhuxlSkpywJmBo8h0ZqJdkp73mb90SssHkN4rsRaBAfAA==", + "dev": true, "license": "ISC" }, "node_modules/natural-compare": { "version": "1.4.0", "resolved": "https://registry.npmjs.org/natural-compare/-/natural-compare-1.4.0.tgz", "integrity": "sha512-OWND8ei3VtNC9h7V60qff3SVobHr996CTwgxubgyQYEpg290h9J0buyECNNJexkFm5sOajh5G116RYA1c8ZMSw==", + "dev": true, "license": "MIT" }, "node_modules/nopt": { "version": "7.2.1", "resolved": "https://registry.npmjs.org/nopt/-/nopt-7.2.1.tgz", "integrity": "sha512-taM24ViiimT/XntxbPyJQzCG+p4EKOpgD3mxFwW38mGjVUrfERQOeY4EDHjdnptttfHuHQXFx+lTP08Q+mLa/w==", + "dev": true, "license": "ISC", "dependencies": { "abbrev": "^2.0.0" @@ -4977,6 +5156,7 @@ "version": "6.0.2", "resolved": "https://registry.npmjs.org/normalize-package-data/-/normalize-package-data-6.0.2.tgz", "integrity": "sha512-V6gygoYb/5EmNI+MEGrWkC+e6+Rr7mTmfHrxDbLzxQogBkgzo76rkok0Am6thgSF7Mv2nLOajAJj5vDJZEFn7g==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "hosted-git-info": "^7.0.0", @@ -4991,6 +5171,7 @@ "version": "7.6.3", "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", + "dev": true, "license": "ISC", "bin": { "semver": "bin/semver.js" @@ -5003,6 +5184,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz", "integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==", + "dev": true, "license": "MIT", "engines": { "node": ">=0.10.0" @@ -5012,6 +5194,7 @@ "version": "6.3.0", "resolved": "https://registry.npmjs.org/npm-install-checks/-/npm-install-checks-6.3.0.tgz", "integrity": "sha512-W29RiK/xtpCGqn6f3ixfRYGk+zRyr+Ew9F2E20BfXxT5/euLdA/Nm7fO7OeTGuAmTs30cpgInyJ0cYe708YTZw==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "semver": "^7.1.1" @@ -5024,6 +5207,7 @@ "version": "7.6.3", "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", + "dev": true, "license": "ISC", "bin": { "semver": "bin/semver.js" @@ -5036,6 +5220,7 @@ "version": "3.0.1", "resolved": "https://registry.npmjs.org/npm-normalize-package-bin/-/npm-normalize-package-bin-3.0.1.tgz", "integrity": "sha512-dMxCf+zZ+3zeQZXKxmyuCKlIDPGuv8EF940xbkC4kQVDTtqoh6rJFO+JTKSA6/Rwi0getWmtuy4Itup0AMcaDQ==", + "dev": true, "license": "ISC", "engines": { "node": "^14.17.0 || ^16.13.0 || >=18.0.0" @@ -5045,6 +5230,7 @@ "version": "11.0.3", "resolved": "https://registry.npmjs.org/npm-package-arg/-/npm-package-arg-11.0.3.tgz", "integrity": "sha512-sHGJy8sOC1YraBywpzQlIKBE4pBbGbiF95U6Auspzyem956E0+FtDtsx1ZxlOJkQCZ1AFXAY/yuvtFYrOxF+Bw==", + "dev": true, "license": "ISC", "dependencies": { "hosted-git-info": "^7.0.0", @@ -5060,6 +5246,7 @@ "version": "7.6.3", "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", + "dev": true, "license": "ISC", "bin": { "semver": "bin/semver.js" @@ -5072,6 +5259,7 @@ "version": "9.1.0", "resolved": "https://registry.npmjs.org/npm-pick-manifest/-/npm-pick-manifest-9.1.0.tgz", "integrity": "sha512-nkc+3pIIhqHVQr085X9d2JzPzLyjzQS96zbruppqC9aZRm/x8xx6xhI98gHtsfELP2bE+loHq8ZaHFHhe+NauA==", + "dev": true, "license": "ISC", "dependencies": { "npm-install-checks": "^6.0.0", @@ -5087,6 +5275,7 @@ "version": "7.6.3", "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", + "dev": true, "license": "ISC", "bin": { "semver": "bin/semver.js" @@ -5099,6 +5288,7 @@ "version": "2.1.1", "resolved": "https://registry.npmjs.org/nth-check/-/nth-check-2.1.1.tgz", "integrity": "sha512-lqjrjmaOoAnWfMmBPL+XNnynZh2+swxiX3WUE0s4yEHI6m+AwrK2UZOimIRl3X/4QctVqS8AiZjFqyOGrMXb/w==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "boolbase": "^1.0.0" @@ -5205,6 +5395,7 @@ "version": "5.1.2", "resolved": "https://registry.npmjs.org/onetime/-/onetime-5.1.2.tgz", "integrity": "sha512-kbpaSSGJTWdAY5KPVeMOKXSrPtr8C8C7wodJbcsd51jRnmD+GZu8Y0VoU6Dm5Z4vWr0Ig/1NKuWRKf7j5aaYSg==", + "dev": true, "license": "MIT", "dependencies": { "mimic-fn": "^2.1.0" @@ -5220,6 +5411,7 @@ "version": "0.9.4", "resolved": "https://registry.npmjs.org/optionator/-/optionator-0.9.4.tgz", "integrity": "sha512-6IpQ7mKUxRcZNLIObR0hz7lxsapSSIYNZJwXPGeF0mTVqGKFIXj1DQcMoT22S3ROcLyY/rz0PWaWZ9ayWmad9g==", + "dev": true, "license": "MIT", "dependencies": { "deep-is": "^0.1.3", @@ -5237,6 +5429,7 @@ "version": "5.4.1", "resolved": "https://registry.npmjs.org/ora/-/ora-5.4.1.tgz", "integrity": "sha512-5b6Y85tPxZZ7QytO+BQzysW31HJku27cRIlkbAXaNx+BdcVi+LlRFmVXzeF6a7JCwJpyw5c4b+YSVImQIrBpuQ==", + "dev": true, "license": "MIT", "dependencies": { "bl": "^4.1.0", @@ -5260,6 +5453,7 @@ "version": "1.0.2", "resolved": "https://registry.npmjs.org/os-tmpdir/-/os-tmpdir-1.0.2.tgz", "integrity": "sha512-D2FR03Vir7FIu45XBY20mTb+/ZSWB00sjU9jdQXt83gDrI4Ztz5Fs7/yy74g2N5SVQY4xY1qDr4rNddwYRVX0g==", + "dev": true, "license": "MIT", "engines": { "node": ">=0.10.0" @@ -5269,6 +5463,7 @@ "version": "3.1.0", "resolved": "https://registry.npmjs.org/p-limit/-/p-limit-3.1.0.tgz", "integrity": "sha512-TYOanM3wGwNGsZN2cVTYPArw454xnXj5qmWF1bEoAc4+cU/ol7GVh7odevjp1FNHduHc3KZMcFduxU5Xc6uJRQ==", + "dev": true, "license": "MIT", "dependencies": { "yocto-queue": "^0.1.0" @@ -5284,6 +5479,7 @@ "version": "5.0.0", "resolved": "https://registry.npmjs.org/p-locate/-/p-locate-5.0.0.tgz", "integrity": "sha512-LaNjtRWUBY++zB5nE/NwcaoMylSPk+S+ZHNB1TzdbMJMny6dynpAGt7X/tl/QYq3TIeE6nxHppbo2LGymrG5Pw==", + "dev": true, "license": "MIT", "dependencies": { "p-limit": "^3.0.2" @@ -5299,12 +5495,14 @@ "version": "1.0.1", "resolved": "https://registry.npmjs.org/package-json-from-dist/-/package-json-from-dist-1.0.1.tgz", "integrity": "sha512-UEZIS3/by4OC8vL3P2dTXRETpebLI2NiI5vIrjaD/5UtrkFX/tNbwjTSRAGC/+7CAo2pIcBaRgWmcBBHcsaCIw==", + "dev": true, "license": "BlueOak-1.0.0" }, "node_modules/parent-module": { "version": "1.0.1", "resolved": "https://registry.npmjs.org/parent-module/-/parent-module-1.0.1.tgz", "integrity": "sha512-GQ2EWRpQV8/o+Aw8YqtfZZPfNRWZYkbidE9k5rpl/hC3vtHHBfGm2Ifi6qWV+coDGkrUKZAxE3Lot5kcsRlh+g==", + "dev": true, "license": "MIT", "dependencies": { "callsites": "^3.0.0" @@ -5317,6 +5515,7 @@ "version": "4.0.1", "resolved": "https://registry.npmjs.org/parse-entities/-/parse-entities-4.0.1.tgz", "integrity": "sha512-SWzvYcSJh4d/SGLIOQfZ/CoNv6BTlI6YEQ7Nj82oDVnRpwe/Z/F1EMx42x3JAOwGBlCjeCH0BRJQbQ/opHL17w==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^2.0.0", @@ -5337,6 +5536,7 @@ "version": "7.1.1", "resolved": "https://registry.npmjs.org/parse-json/-/parse-json-7.1.1.tgz", "integrity": "sha512-SgOTCX/EZXtZxBE5eJ97P4yGM5n37BwRU+YMsH4vNzFqJV/oWFXXCmwFlgWUM4PrakybVOueJJ6pwHqSVhTFDw==", + "dev": true, "license": "MIT", "dependencies": { "@babel/code-frame": "^7.21.4", @@ -5356,6 +5556,7 @@ "version": "3.13.1", "resolved": "https://registry.npmjs.org/type-fest/-/type-fest-3.13.1.tgz", "integrity": "sha512-tLq3bSNx+xSpwvAJnzrK0Ep5CLNWjvFTOp71URMaAEWBfRb9nnJiBoUe0tF8bI4ZFO3omgBR6NvnbzVUT3Ly4g==", + "dev": true, "license": "(MIT OR CC0-1.0)", "engines": { "node": ">=14.16" @@ -5365,28 +5566,10 @@ } }, "node_modules/parse5": { - "version": "6.0.1", - "resolved": "https://registry.npmjs.org/parse5/-/parse5-6.0.1.tgz", - "integrity": "sha512-Ofn/CTFzRGTTxwpNEs9PP93gXShHcTq255nzRYSKe8AkVpZY7e1fpmTfOyoIvjP5HG7Z2ZM7VS9PPhQGW2pOpw==", - "license": "MIT" - }, - "node_modules/parse5-htmlparser2-tree-adapter": { - "version": "7.1.0", - "resolved": "https://registry.npmjs.org/parse5-htmlparser2-tree-adapter/-/parse5-htmlparser2-tree-adapter-7.1.0.tgz", - "integrity": "sha512-ruw5xyKs6lrpo9x9rCZqZZnIUntICjQAd0Wsmp396Ul9lN/h+ifgVV1x1gZHi8euej6wTfpqX8j+BFQxF0NS/g==", - "license": "MIT", - "dependencies": { - "domhandler": "^5.0.3", - "parse5": "^7.0.0" - }, - "funding": { - "url": "https://github.com/inikulin/parse5?sponsor=1" - } - }, - "node_modules/parse5-htmlparser2-tree-adapter/node_modules/parse5": { "version": "7.2.0", "resolved": "https://registry.npmjs.org/parse5/-/parse5-7.2.0.tgz", "integrity": "sha512-ZkDsAOcxsUMZ4Lz5fVciOehNcJ+Gb8gTzcA4yl3wnc273BAybYWrQ+Ks/OjCjSEpjvQkDSeZbybK9qj2VHHdGA==", + "dev": true, "license": "MIT", "dependencies": { "entities": "^4.5.0" @@ -5395,25 +5578,28 @@ "url": "https://github.com/inikulin/parse5?sponsor=1" } }, - "node_modules/parse5-parser-stream": { - "version": "7.1.2", - "resolved": "https://registry.npmjs.org/parse5-parser-stream/-/parse5-parser-stream-7.1.2.tgz", - "integrity": "sha512-JyeQc9iwFLn5TbvvqACIF/VXG6abODeB3Fwmv/TGdLk2LfbWkaySGY72at4+Ty7EkPZj854u4CrICqNk2qIbow==", + "node_modules/parse5-htmlparser2-tree-adapter": { + "version": "7.1.0", + "resolved": "https://registry.npmjs.org/parse5-htmlparser2-tree-adapter/-/parse5-htmlparser2-tree-adapter-7.1.0.tgz", + "integrity": "sha512-ruw5xyKs6lrpo9x9rCZqZZnIUntICjQAd0Wsmp396Ul9lN/h+ifgVV1x1gZHi8euej6wTfpqX8j+BFQxF0NS/g==", + "dev": true, "license": "MIT", "dependencies": { + "domhandler": "^5.0.3", "parse5": "^7.0.0" }, "funding": { "url": "https://github.com/inikulin/parse5?sponsor=1" } }, - "node_modules/parse5-parser-stream/node_modules/parse5": { - "version": "7.2.0", - "resolved": "https://registry.npmjs.org/parse5/-/parse5-7.2.0.tgz", - "integrity": "sha512-ZkDsAOcxsUMZ4Lz5fVciOehNcJ+Gb8gTzcA4yl3wnc273BAybYWrQ+Ks/OjCjSEpjvQkDSeZbybK9qj2VHHdGA==", + "node_modules/parse5-parser-stream": { + "version": "7.1.2", + "resolved": "https://registry.npmjs.org/parse5-parser-stream/-/parse5-parser-stream-7.1.2.tgz", + "integrity": "sha512-JyeQc9iwFLn5TbvvqACIF/VXG6abODeB3Fwmv/TGdLk2LfbWkaySGY72at4+Ty7EkPZj854u4CrICqNk2qIbow==", + "dev": true, "license": "MIT", "dependencies": { - "entities": "^4.5.0" + "parse5": "^7.0.0" }, "funding": { "url": "https://github.com/inikulin/parse5?sponsor=1" @@ -5423,6 +5609,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/path-exists/-/path-exists-4.0.0.tgz", "integrity": "sha512-ak9Qy5Q7jYb2Wwcey5Fpvg2KoAc/ZIhLSLOSBmRmygPsGwkVVt0fZa0qrtMz+m6tJTAHfZQ8FnmB4MG4LWy7/w==", + "dev": true, "license": "MIT", "engines": { "node": ">=8" @@ -5432,6 +5619,7 @@ "version": "3.1.1", "resolved": "https://registry.npmjs.org/path-key/-/path-key-3.1.1.tgz", "integrity": "sha512-ojmeN0qd+y0jszEtoY48r0Peq5dwMEkIlCOu6Q5f41lfkswXuKtYrhgoTpLnyIcHm24Uhqx+5Tqm2InSwLhE6Q==", + "dev": true, "license": "MIT", "engines": { "node": ">=8" @@ -5448,6 +5636,7 @@ "version": "1.11.1", "resolved": "https://registry.npmjs.org/path-scurry/-/path-scurry-1.11.1.tgz", "integrity": "sha512-Xa4Nw17FS9ApQFJ9umLiJS4orGjm7ZzwUrwamcGQuHSzDyth9boKDaycYdDcZDuqYATXw4HFXgaqWTctW/v1HA==", + "dev": true, "license": "BlueOak-1.0.0", "dependencies": { "lru-cache": "^10.2.0", @@ -5464,12 +5653,14 @@ "version": "1.1.1", "resolved": "https://registry.npmjs.org/picocolors/-/picocolors-1.1.1.tgz", "integrity": "sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA==", + "dev": true, "license": "ISC" }, "node_modules/picomatch": { "version": "2.3.1", "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz", "integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==", + "dev": true, "license": "MIT", "engines": { "node": ">=8.6" @@ -5482,6 +5673,7 @@ "version": "8.0.0", "resolved": "https://registry.npmjs.org/pluralize/-/pluralize-8.0.0.tgz", "integrity": "sha512-Nc3IT5yHzflTfbjgqWcCPpo7DaKy4FnpB0l/zCAW0Tc7jxAiuqSxHasntB3D7887LSrA93kDJ9IXovxJYxyLCA==", + "dev": true, "license": "MIT", "engines": { "node": ">=4" @@ -5501,6 +5693,7 @@ "version": "1.2.1", "resolved": "https://registry.npmjs.org/prelude-ls/-/prelude-ls-1.2.1.tgz", "integrity": "sha512-vkcDPrRZo1QZLbn5RLGPpg/WmIQ65qoWWhcGKf/b5eplkkarX0m9z8ppCat4mlOqUsWpyNuYgO3VRyrYHSzX5g==", + "dev": true, "license": "MIT", "engines": { "node": ">= 0.8.0" @@ -5510,6 +5703,7 @@ "version": "4.2.0", "resolved": "https://registry.npmjs.org/proc-log/-/proc-log-4.2.0.tgz", "integrity": "sha512-g8+OnU/L2v+wyiVK+D5fA34J7EH8jZ8DDlvwhRCMxmMj7UCBvxiO1mGeN+36JXIKF4zevU4kRBd8lVgG9vLelA==", + "dev": true, "license": "ISC", "engines": { "node": "^14.17.0 || ^16.13.0 || >=18.0.0" @@ -5519,12 +5713,14 @@ "version": "1.0.1", "resolved": "https://registry.npmjs.org/promise-inflight/-/promise-inflight-1.0.1.tgz", "integrity": "sha512-6zWPyEOFaQBJYcGMHBKTKJ3u6TBsnMFOIZSa6ce1e/ZrrsOlnHRHbabMjLiBYKp+n44X9eUI6VUPaukCXHuG4g==", + "dev": true, "license": "ISC" }, "node_modules/promise-retry": { "version": "2.0.1", "resolved": "https://registry.npmjs.org/promise-retry/-/promise-retry-2.0.1.tgz", "integrity": "sha512-y+WKFlBR8BGXnsNlIHFGPZmyDf3DFMoLhaflAnyZgV6rG6xu+JwesTo2Q9R6XwYmtmwAFCkAk3e35jEdoeh/3g==", + "dev": true, "license": "MIT", "dependencies": { "err-code": "^2.0.2", @@ -5538,6 +5734,7 @@ "version": "6.5.0", "resolved": "https://registry.npmjs.org/property-information/-/property-information-6.5.0.tgz", "integrity": "sha512-PgTgs/BlvHxOu8QuEN7wi5A0OmXaBcHpmCSTehcs6Uuu9IkDIEo13Hy7n898RHfrQ49vKCoGeWZSaAK01nwVig==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -5548,6 +5745,7 @@ "version": "0.0.5", "resolved": "https://registry.npmjs.org/propose/-/propose-0.0.5.tgz", "integrity": "sha512-Jary1vb+ap2DIwOGfyiadcK4x1Iu3pzpkDBy8tljFPmQvnc9ES3m1PMZOMiWOG50cfoAyYNtGeBzrp+Rlh4G9A==", + "dev": true, "license": "MIT", "dependencies": { "levenshtein-edit-distance": "^1.0.0" @@ -5557,6 +5755,7 @@ "version": "2.3.1", "resolved": "https://registry.npmjs.org/punycode/-/punycode-2.3.1.tgz", "integrity": "sha512-vYt7UD1U9Wg6138shLtLOvdAu+8DsC/ilFtEVHcH+wydcSpNE20AfSOduf6MkRFahL5FY7X1oU7nKVZFtfq8Fg==", + "dev": true, "license": "MIT", "engines": { "node": ">=6" @@ -5566,6 +5765,7 @@ "version": "1.2.3", "resolved": "https://registry.npmjs.org/queue-microtask/-/queue-microtask-1.2.3.tgz", "integrity": "sha512-NuaNSa6flKT5JaSYQzJok04JzTL1CA6aGhv5rfLW3PgqA+M2ChpZQnAC8h8i4ZFkBS8X5RqkDBHA7r4hej3K9A==", + "dev": true, "funding": [ { "type": "github", @@ -5586,6 +5786,7 @@ "version": "2.0.3", "resolved": "https://registry.npmjs.org/quotation/-/quotation-2.0.3.tgz", "integrity": "sha512-yEc24TEgCFLXx7D4JHJJkK4JFVtatO8fziwUxY4nB/Jbea9o9CVS3gt22mA0W7rPYAGW2fWzYDSOtD94PwOyqA==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -5596,6 +5797,7 @@ "version": "3.0.2", "resolved": "https://registry.npmjs.org/read-package-json-fast/-/read-package-json-fast-3.0.2.tgz", "integrity": "sha512-0J+Msgym3vrLOUB3hzQCuZHII0xkNGCtz/HJH9xZshwv9DbDwkw1KaE3gx/e2J5rpEY5rtOy6cyhKOPrkP7FZw==", + "dev": true, "license": "ISC", "dependencies": { "json-parse-even-better-errors": "^3.0.0", @@ -5609,6 +5811,7 @@ "version": "3.6.2", "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.2.tgz", "integrity": "sha512-9u/sniCrY3D5WdsERHzHE4G2YCXqoG5FTHUiCC4SIbr6XcLZBY05ya9EKjYek9O5xOAwjGq+1JdGBAS7Q9ScoA==", + "dev": true, "license": "MIT", "dependencies": { "inherits": "^2.0.3", @@ -5623,6 +5826,7 @@ "version": "3.6.0", "resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.6.0.tgz", "integrity": "sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==", + "dev": true, "license": "MIT", "dependencies": { "picomatch": "^2.2.1" @@ -5650,10 +5854,28 @@ "url": "https://github.com/sponsors/ljharb" } }, + "node_modules/rehype-document": { + "version": "7.0.3", + "resolved": "https://registry.npmjs.org/rehype-document/-/rehype-document-7.0.3.tgz", + "integrity": "sha512-g5zq6i2FwWVBVdyVi0Jw/5MRvsHj3wuJCn+QeyOjm29QBpTG4r1iUElyH9GhfWx5fB27ZEApA53RdAiYGBb4zQ==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/hast": "^3.0.0", + "hastscript": "^8.0.0", + "unified": "^11.0.0", + "vfile": "^6.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, "node_modules/rehype-stringify": { "version": "10.0.1", "resolved": "https://registry.npmjs.org/rehype-stringify/-/rehype-stringify-10.0.1.tgz", "integrity": "sha512-k9ecfXHmIPuFVI61B9DeLPN0qFHfawM6RsuX48hoqlaKSF61RskNjSm1lI8PhBEM0MRdLxVVm4WmTqJQccH9mA==", + "dev": true, "license": "MIT", "dependencies": { "@types/hast": "^3.0.0", @@ -5669,6 +5891,7 @@ "version": "15.0.1", "resolved": "https://registry.npmjs.org/remark/-/remark-15.0.1.tgz", "integrity": "sha512-Eht5w30ruCXgFmxVUSlNWQ9iiimq07URKeFS3hNc8cUWy1llX4KDWfyEDZRycMc+znsN9Ux5/tJ/BFdgdOwA3A==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5681,10 +5904,31 @@ "url": "https://opencollective.com/unified" } }, + "node_modules/remark-cli": { + "version": "12.0.1", + "resolved": "https://registry.npmjs.org/remark-cli/-/remark-cli-12.0.1.tgz", + "integrity": "sha512-2NAEOACoTgo+e+YAaCTODqbrWyhMVmlUyjxNCkTrDRHHQvH6+NbrnqVvQaLH/Q8Ket3v90A43dgAJmXv8y5Tkw==", + "dev": true, + "license": "MIT", + "dependencies": { + "import-meta-resolve": "^4.0.0", + "markdown-extensions": "^2.0.0", + "remark": "^15.0.0", + "unified-args": "^11.0.0" + }, + "bin": { + "remark": "cli.js" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, "node_modules/remark-flexible-containers": { "version": "1.2.1", "resolved": "https://registry.npmjs.org/remark-flexible-containers/-/remark-flexible-containers-1.2.1.tgz", "integrity": "sha512-6qsWW2A3577AyYWDKtiKb79+KISiReB7Tos/aJg8uu9dwGPt14KRZrrJB32zY9/VYIetW15SZiqN3v7W2UP8rA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.3", @@ -5698,6 +5942,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-gfm/-/remark-gfm-4.0.0.tgz", "integrity": "sha512-U92vJgBPkbw4Zfu/IiW2oTZLSL3Zpv+uI7My2eq8JxKgqraFdU8YUGicEJCEgSbeaG+QDFqIcwwfMTOEelPxuA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5716,6 +5961,7 @@ "version": "1.0.1", "resolved": "https://registry.npmjs.org/remark-heading-id/-/remark-heading-id-1.0.1.tgz", "integrity": "sha512-GmJjuCeEkYvwFlvn/Skjc/1Qafj71412gbQnrwUmP/tKskmAf1cMRlZRNoovV+aIvsSRkTb2rCmGv2b9RdoJbQ==", + "dev": true, "license": "MIT", "dependencies": { "lodash": "^4.17.21", @@ -5729,12 +5975,14 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-3.0.0.tgz", "integrity": "sha512-sVZZX3+kspVNmLWBPAB6r+7D9ZgAFPNWm66f7YNb420RlQSbn+n8rG8dGZSkrER7ZIXGQYNm5pqC3v3HopH24A==", + "dev": true, "license": "MIT" }, "node_modules/remark-heading-id/node_modules/unist-util-visit": { "version": "1.4.1", "resolved": "https://registry.npmjs.org/unist-util-visit/-/unist-util-visit-1.4.1.tgz", "integrity": "sha512-AvGNk7Bb//EmJZyhtRUnNMEpId/AZ5Ph/KUpTI09WHQuDZHKovQ1oEv3mfmKpWKtoMzyMC4GLBm1Zy5k12fjIw==", + "dev": true, "license": "MIT", "dependencies": { "unist-util-visit-parents": "^2.0.0" @@ -5744,6 +5992,7 @@ "version": "2.1.2", "resolved": "https://registry.npmjs.org/unist-util-visit-parents/-/unist-util-visit-parents-2.1.2.tgz", "integrity": "sha512-DyN5vD4NE3aSeB+PXYNKxzGsfocxp6asDc2XXE3b0ekO2BaRUpBicbbUygfSvYfUz1IkmjFR1YF7dPklraMZ2g==", + "dev": true, "license": "MIT", "dependencies": { "unist-util-is": "^3.0.0" @@ -5753,6 +6002,7 @@ "version": "10.0.0", "resolved": "https://registry.npmjs.org/remark-lint/-/remark-lint-10.0.0.tgz", "integrity": "sha512-E8yHHDOJ8b+qI0G49BRu24pe8t0fNNBWv8ENQJpCGNrVeTeyBIGEbaUe1yuF7OG8faA6PVpcN/pqWjzW9fcBWQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5768,6 +6018,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-blockquote-indentation/-/remark-lint-blockquote-indentation-4.0.0.tgz", "integrity": "sha512-hdUvn+KsJbBKpY9jLY01PmfpJ/WGhLu9GJMXQGU8ADXJc+F5DWSgKAr6GQ1IUKqvGYdEML/KZ61WomWFUuecVA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5782,10 +6033,30 @@ "url": "https://opencollective.com/unified" } }, + "node_modules/remark-lint-checkbox-character-style": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/remark-lint-checkbox-character-style/-/remark-lint-checkbox-character-style-5.0.0.tgz", + "integrity": "sha512-K0G/Nok59fb2q5KUxcemBVt+ymnhTkDVLJAatZ4PAh9At8y0DGctHdU27jWsuvO0Fs7Zy62Usk7IJE2VO89p1w==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/mdast": "^4.0.0", + "mdast-util-phrasing": "^4.0.0", + "unified-lint-rule": "^3.0.0", + "unist-util-position": "^5.0.0", + "unist-util-visit-parents": "^6.0.0", + "vfile-message": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, "node_modules/remark-lint-code-block-style": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-code-block-style/-/remark-lint-code-block-style-4.0.0.tgz", "integrity": "sha512-LKBKMVruEO0tzDnnnqi1TfUcnwY6Mo7cVtZM4E4pKt3KMhtvgU2wD68/MxDOEJd0pmnLrEgIadv74bY0gWhZpg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5804,6 +6075,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-definition-case/-/remark-lint-definition-case-4.0.0.tgz", "integrity": "sha512-XBmMmj8ii0KZUuJf7ZaVXDGp2+DWE02re9qn/6mV23rBpsDmpz7U1lQWRlwFQIE5q5bxIxP5pX7hDeTH0Egy9Q==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5820,6 +6092,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-definition-spacing/-/remark-lint-definition-spacing-4.0.0.tgz", "integrity": "sha512-t6nP8unz6z/DLBTWeOmDFHPFbX3E2PbNgt2fTazRbVnMC6z3o25hBzg5hI6DL0MPt2ZTRX++rJsGRjb+vgh/tQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5838,6 +6111,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-emphasis-marker/-/remark-lint-emphasis-marker-4.0.0.tgz", "integrity": "sha512-xIRiB4PFWUOyIslN/UOPL6Lh+J0VD4R11+jo+W4hpGMNsg58l+2SgtdbinlXzDeoBxmaaka9n/sYpJ7cJWEIPQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5855,6 +6129,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-fenced-code-flag/-/remark-lint-fenced-code-flag-4.0.0.tgz", "integrity": "sha512-Zs0wJd4nRvBo/9NWQVfWg5Ykapbo0Zzw/SyZc3f0h73S1gTZZcfeU+bA5oDivlBdcUgLBsyHRE0QaoaVvN3/Wg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5873,6 +6148,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-fenced-code-marker/-/remark-lint-fenced-code-marker-4.0.0.tgz", "integrity": "sha512-WFN88Rx78m4/HSbW3Kx2XAYbVfzYns4bJd9qpwDD90DA3nc59zciYd01xi6Bk3n9vSs5gIlmG7xkwxVHHJ8KCA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5891,6 +6167,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/remark-lint-file-extension/-/remark-lint-file-extension-3.0.0.tgz", "integrity": "sha512-wrOKiGvcl/ftB7FkeX2/l13ALvhKXV77HGR8AXo86cVY2pD+K0WdOC52DV3ldgpUXpWzE9kcgF8bbkxwzKpFFg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5906,6 +6183,7 @@ "version": "4.0.1", "resolved": "https://registry.npmjs.org/remark-lint-final-definition/-/remark-lint-final-definition-4.0.1.tgz", "integrity": "sha512-51T9oSdA7wuhjSdgGo0snO1BY39Igt9cJQi7XpgtgFsbfQk8zSSAUAc/rLabY6+YCTpcPs6qmwvLXZ4mPX6Qlg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5922,10 +6200,28 @@ "url": "https://opencollective.com/unified" } }, + "node_modules/remark-lint-final-newline": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/remark-lint-final-newline/-/remark-lint-final-newline-3.0.0.tgz", + "integrity": "sha512-NaPyn6FiOn3IV/6gIcwWfJmgraPT2IaVLjhakfPglZkKVfn/FrOfETyY8Bp+HLoSRI9967OH0yRDnK7/pPIWeQ==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/mdast": "^4.0.0", + "devlop": "^1.0.0", + "unified-lint-rule": "^3.0.0", + "vfile-location": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, "node_modules/remark-lint-hard-break-spaces": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-hard-break-spaces/-/remark-lint-hard-break-spaces-4.0.0.tgz", "integrity": "sha512-zCTq7/xfM0ZL3bMopXse9DH2nk38wE1LrxmYwnTrqASBLnEAJWE2U2//tRGVMEBfSAnNvmIo96twz6zkLWjbGA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5942,6 +6238,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-heading-increment/-/remark-lint-heading-increment-4.0.0.tgz", "integrity": "sha512-TARnsjXWzY/yLwxh/y4+KnDSXO3Koue8Crp55T8G9pjj3vw+XgTAG35zSpIIY9HmGiQ2a3R0SOj2pAxATpnckg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5960,6 +6257,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-heading-style/-/remark-lint-heading-style-4.0.0.tgz", "integrity": "sha512-dQ6Jul5K0+aNUvrq4W7H0+osSoC9hsmwHZqBFq000+eMP/hWJqI8tuudw1rap8HHYuOsKLRbB5q+Fr7G+3Vw+Q==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5979,6 +6277,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-link-title-style/-/remark-lint-link-title-style-4.0.0.tgz", "integrity": "sha512-cihTO5dkhjMj/evYIDAvRdQHD82OQeF4fNAq8FLb81HmFKo77VlSF6CK55H1bvlZogfJG58uN/5d1tSsOdcEbg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -5992,10 +6291,28 @@ "url": "https://opencollective.com/unified" } }, + "node_modules/remark-lint-list-item-bullet-indent": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/remark-lint-list-item-bullet-indent/-/remark-lint-list-item-bullet-indent-5.0.0.tgz", + "integrity": "sha512-qq22QaxsDjfsL7aWGIPmP3P0N99CJBQQW1+iSrhYAMCDzqVlw6I3wPNAeR6s8mcoeHT8YlT6eQH3V8xJ0SlW6w==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/mdast": "^4.0.0", + "pluralize": "^8.0.0", + "unified-lint-rule": "^3.0.0", + "unist-util-position": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, "node_modules/remark-lint-list-item-content-indent": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-list-item-content-indent/-/remark-lint-list-item-content-indent-4.0.0.tgz", "integrity": "sha512-L4GZgWQQ54qWKbnDle3dbEOtnq+qdmZJ70lpM3yMFEMHs4xejqPKsIoiYeUtIV0rYHHCWS7IlLzcgYUK9vENQw==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6015,6 +6332,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-list-item-indent/-/remark-lint-list-item-indent-4.0.0.tgz", "integrity": "sha512-Yd6/g8CH9e4vlPAPNgl7F575uKhP+pTo/qwGkE61GOcgEVNJ/529hjumUhyQ4sOAX0YAPAjxvq6fJvb4AhVOOA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6033,6 +6351,7 @@ "version": "5.0.0", "resolved": "https://registry.npmjs.org/remark-lint-list-item-spacing/-/remark-lint-list-item-spacing-5.0.0.tgz", "integrity": "sha512-d6p+1tcwNE+Pp6Tu2DwiKlyC1zYY3f1igL6AlcBIH0RmROVEfZR4IDFH/LcVyTkzqh1lPMFAJXWK4bpScpcO3g==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6052,6 +6371,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-maximum-heading-length/-/remark-lint-maximum-heading-length-4.0.0.tgz", "integrity": "sha512-UCQxUd0zZyi6RUbpoK5KsxC50ppVqVk0hSgrSPot4wB6PHRgYMALU2fDkEcAjLDc/Y2TayG3IaZEKdqe+84Cwg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6070,6 +6390,7 @@ "version": "4.0.1", "resolved": "https://registry.npmjs.org/remark-lint-maximum-line-length/-/remark-lint-maximum-line-length-4.0.1.tgz", "integrity": "sha512-hQlh8UrRfhkO4FU7z7t1Bu5ethj1y2iBncO5AOWF38RAmlHaZdB2lQxNA8IvUZITGJYpT1aThdFTEf+58lv08Q==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6088,6 +6409,7 @@ "version": "6.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-blockquote-without-marker/-/remark-lint-no-blockquote-without-marker-6.0.0.tgz", "integrity": "sha512-fBhoTpkWcl5tG4FdwPdJIyb8XLrdr6MdLk1+K2BQ6Rom3rRsIYvuox4ohxOunNrXuth8xyw8kC6wDmODR44oFw==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6109,6 +6431,7 @@ "version": "5.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-consecutive-blank-lines/-/remark-lint-no-consecutive-blank-lines-5.0.0.tgz", "integrity": "sha512-HsDZbFlelBVO3mEJDXd9v4z0HLB8pqxWnsV+I4ILYFp5lKYf6NxJaLBWFtP1gAg1+95WxityGLkGtYqmicDjpg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6125,10 +6448,30 @@ "url": "https://opencollective.com/unified" } }, + "node_modules/remark-lint-no-duplicate-definitions": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/remark-lint-no-duplicate-definitions/-/remark-lint-no-duplicate-definitions-4.0.0.tgz", + "integrity": "sha512-21fcOACkCyhNsHkedKlpvqIywYx+5zGR507bW8e59gzdGhTbnBwQ9du4ACmN9jxPTfIBhUVMz0bWezkGrHE7Bg==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/mdast": "^4.0.0", + "devlop": "^1.0.0", + "mdast-util-phrasing": "^4.0.0", + "unified-lint-rule": "^3.0.0", + "unist-util-visit-parents": "^6.0.0", + "vfile-message": "^4.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, "node_modules/remark-lint-no-duplicate-headings": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-duplicate-headings/-/remark-lint-no-duplicate-headings-4.0.0.tgz", "integrity": "sha512-FgBU/JCdR5MitHM+hnOcgBGO5ZCNV8epzuHIglFlJeb8ow23YhhNgmGvyk7RGrZrYuU5R9uQq23N4dF0g9atCA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6148,6 +6491,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-emphasis-as-heading/-/remark-lint-no-emphasis-as-heading-4.0.0.tgz", "integrity": "sha512-JViGYbuO/xzZThK+qVTNjtLM0v1xMTWFTWt2OJzAkDaGS6T9ZB5ZtRVSBFEMG0SF3dvpJwxe+3ABTsuPBdlYsA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6164,6 +6508,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-articles/-/remark-lint-no-file-name-articles-3.0.0.tgz", "integrity": "sha512-il4IseupahbV2TVfFjfDVL/EQw7jBWVlMVsv4K2cgl5uPIjiCjFGQypqKnWl6pZDN0oNOs/DE8gBdyuDjldJaA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6178,6 +6523,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-consecutive-dashes/-/remark-lint-no-file-name-consecutive-dashes-3.0.0.tgz", "integrity": "sha512-3vSI1LOQlu8NSCpWLsKELa8dS9HU+YVZE0U43/DNkdEcnZmlJLpTHQjBTMZUHQipRgoOO+TOSyXFyN/H+2lbuQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6192,6 +6538,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-irregular-characters/-/remark-lint-no-file-name-irregular-characters-3.0.0.tgz", "integrity": "sha512-DhGreliHNU7lLTARQujsaLAn8fUPY0V+H0LSmOUuowBZPtIRWeNdQhunSp96RvsuYdqAdERXe0WuH58i3pRqrg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6206,6 +6553,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-mixed-case/-/remark-lint-no-file-name-mixed-case-3.0.0.tgz", "integrity": "sha512-MXXNHdGB6P46itkf8gRP0kxQL85KfAj9YOOBqNtGsgI/8J5rsyM/rz1Ac20Xe+5C5oGi71+7EO/TExKu/+7dfw==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6220,6 +6568,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-outer-dashes/-/remark-lint-no-file-name-outer-dashes-3.0.0.tgz", "integrity": "sha512-3kgamCp39mdlCtqF/+JLwwS4VpSj5wvVwRythUfrpW7993I9kF67dBsaU545aEzWSK+UJZqjb40i0m2VfnBRfQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6230,10 +6579,30 @@ "url": "https://opencollective.com/unified" } }, + "node_modules/remark-lint-no-heading-content-indent": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/remark-lint-no-heading-content-indent/-/remark-lint-no-heading-content-indent-5.0.0.tgz", + "integrity": "sha512-psYSlD2BjcVkgpeXOLwPcYFBrbtJWp8E8JX1J4vSfoHPeY6aIxgYxXkf57cjGTApfRL8xawBmMDiF1FgQvpZYg==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/mdast": "^4.0.0", + "mdast-util-phrasing": "^4.0.0", + "pluralize": "^8.0.0", + "unified-lint-rule": "^3.0.0", + "unist-util-position": "^5.0.0", + "unist-util-visit-parents": "^6.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, "node_modules/remark-lint-no-heading-punctuation": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-heading-punctuation/-/remark-lint-no-heading-punctuation-4.0.0.tgz", "integrity": "sha512-7V23C3Q4yX9zEOLZdbv6o8wVxxeWB/F+h9by55zPyk2AwbqF2t2xevnAmN3XFmKZABDTqLwjQxtK6bCVv/S1PQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6251,6 +6620,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-literal-urls/-/remark-lint-no-literal-urls-4.0.0.tgz", "integrity": "sha512-rl/3Ai4Ax9IH/fRpOJZuXk1HgYX6oFTauhmBOilpqbq/YT2kN3FuXaneXdRfKv1bgMdHaLKxHWxGj/mDyA2n8w==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6269,6 +6639,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-multiple-toplevel-headings/-/remark-lint-no-multiple-toplevel-headings-4.0.0.tgz", "integrity": "sha512-JW11iYxza7asDdhQuKfr8SH1u4NBOCQ4U7Ru0HrKCPcT4y/AB1C1il5uMQzbcervgYPBq69xzyQ24+AJeL0t3A==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6287,6 +6658,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-shell-dollars/-/remark-lint-no-shell-dollars-4.0.0.tgz", "integrity": "sha512-ye2h8FzjsgqqQV0HHN2g9N4FqI3eD9Gpgu7tU5ADIJyQ3mUJdwBoFn7IlGnpmumR1fb/l6u/AhRavIZxXYqG+Q==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6304,6 +6676,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-shortcut-reference-image/-/remark-lint-no-shortcut-reference-image-4.0.0.tgz", "integrity": "sha512-YEiCpW5F/8/LZyxlOuVK2L/n0NJ1AB0AJK7oP39OVyEk3Xl7w+JQi6nZ3KiH6REh+PWGqKn6M0KEPL9cT/iAOw==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6319,6 +6692,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-shortcut-reference-link/-/remark-lint-no-shortcut-reference-link-4.0.0.tgz", "integrity": "sha512-6jka2Zz3I6G2MvDcKrwADYhTOxHMFMK854u1cfBEIH5/XnCCXROtoqiiDtbZw+NJqbmwsBKvGL4t2gnmEJUmgg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6334,6 +6708,7 @@ "version": "5.0.0", "resolved": "https://registry.npmjs.org/remark-lint-no-table-indentation/-/remark-lint-no-table-indentation-5.0.0.tgz", "integrity": "sha512-MaLmnzgirpnRiRjWwrsyOX0RmP2eG4YAv169MtsxTVa6O3CpUDwTuTzivudE9L0kVvTlyF9DXEmdyjm85LDyVA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6350,10 +6725,49 @@ "url": "https://opencollective.com/unified" } }, + "node_modules/remark-lint-no-undefined-references": { + "version": "5.0.0", + "resolved": "https://registry.npmjs.org/remark-lint-no-undefined-references/-/remark-lint-no-undefined-references-5.0.0.tgz", + "integrity": "sha512-O0q8bHpRHK1T85oqO+uep4BkvQnZZp3y+wahDeeLLq9dCJfF56sq6Tt5OOTt1BAOZlpobS3OPQHUiJWYP6hX1w==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/mdast": "^4.0.0", + "collapse-white-space": "^2.0.0", + "devlop": "^1.0.0", + "micromark-util-normalize-identifier": "^2.0.0", + "unified-lint-rule": "^3.0.0", + "unist-util-position": "^5.0.0", + "unist-util-visit-parents": "^6.0.0", + "vfile-location": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-lint-no-unused-definitions": { + "version": "4.0.0", + "resolved": "https://registry.npmjs.org/remark-lint-no-unused-definitions/-/remark-lint-no-unused-definitions-4.0.0.tgz", + "integrity": "sha512-YCZ6k575NCTx7mnN+9ls0G6YgMsZHi0LYQqfLW8MNVHBtbpTBvfmk8I39bmsvuKWeBD98weZoXSDqIiIGg+Q/g==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/mdast": "^4.0.0", + "devlop": "^1.0.0", + "unified-lint-rule": "^3.0.0", + "unist-util-visit": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, "node_modules/remark-lint-ordered-list-marker-style": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-ordered-list-marker-style/-/remark-lint-ordered-list-marker-style-4.0.0.tgz", "integrity": "sha512-xZ7Xppy5fzACH4b9h1b4lTzVtNY2AlUkNTfl1Oe6cIKN8tk3juFxN0wL2RpktPtSZ7iRIabzFmg6l8WPhlASJA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6373,6 +6787,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-ordered-list-marker-value/-/remark-lint-ordered-list-marker-value-4.0.0.tgz", "integrity": "sha512-7UjNU2Nv9LGEONTU9GPmTVoNoGKD5aL1X2xHzMbSJiTc50bfcazYqZawO+qj1pQ04WPhto1qHnl0HRB5wwSVwA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6393,6 +6808,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-rule-style/-/remark-lint-rule-style-4.0.0.tgz", "integrity": "sha512-Kt7IHMB5IbLgRFKaFUmB895sV3PTD0MBgN9CvXKxr1wHFF43S6tabjFIBSoQqyJRlhH0S3rK6Lvopofa009gLg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6411,6 +6827,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-strong-marker/-/remark-lint-strong-marker-4.0.0.tgz", "integrity": "sha512-YcvuzakYhQWdCH+1E30sUY+wyvq+PNa77NZAMAYO/cS/pZczFB+q4Ccttw4Q+No/chX8oMfe0GYtm8dDWLei/g==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6428,6 +6845,7 @@ "version": "5.0.0", "resolved": "https://registry.npmjs.org/remark-lint-table-cell-padding/-/remark-lint-table-cell-padding-5.0.0.tgz", "integrity": "sha512-LNyiHDQZBIOqcQGG1tYsZHW7g0v8OyRmRgDrD5WEsMaAYfM6EiECUokN/Q4py9h4oM/2KUSrdZbtfuZmy87/kA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6449,12 +6867,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/remark-lint-table-pipe-alignment": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-table-pipe-alignment/-/remark-lint-table-pipe-alignment-4.0.0.tgz", "integrity": "sha512-nx+xpEIWQRLOcq9hIbUIvhSE1NYRmDJmCY3cMoHJ1sIW7dRXMHyWfpWTgu7mpREKwSQdE0q4qnzk8McQQSkIcg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6475,12 +6895,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/remark-lint-table-pipes": { "version": "5.0.0", "resolved": "https://registry.npmjs.org/remark-lint-table-pipes/-/remark-lint-table-pipes-5.0.0.tgz", "integrity": "sha512-e7jzAScDrt5+eMomh099TZJBN2K9ldDxBu9iYhNu5C0YsdAvnckJkgilsuClxFpmx4LCVYaX0EGbt/hQ3LB3xg==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6499,12 +6921,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/remark-lint-unordered-list-marker-style": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/remark-lint-unordered-list-marker-style/-/remark-lint-unordered-list-marker-style-4.0.0.tgz", "integrity": "sha512-XlP4Wr4KJNovyWVv0H5axfUlF23iE9Kt2SxaVq4+ieum5YcMmKE6KsL+aqt3kiJb60SH1u6a0bxKFvdM/9riOA==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6523,6 +6947,7 @@ "version": "8.0.0", "resolved": "https://registry.npmjs.org/remark-message-control/-/remark-message-control-8.0.0.tgz", "integrity": "sha512-brpzOO+jdyE/mLqvqqvbogmhGxKygjpCUCG/PwSCU43+JZQ+RM+sSzkCWBcYvgF3KIAVNIoPsvXjBkzO7EdsYQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", @@ -6539,122 +6964,338 @@ "version": "11.0.0", "resolved": "https://registry.npmjs.org/remark-parse/-/remark-parse-11.0.0.tgz", "integrity": "sha512-FCxlKLNGknS5ba/1lmpYijMUzX2esxW5xQqjWxw2eHFfS2MSdaHVINFmhjo+qN1WhZhNimq0dZATN9pH0IDrpA==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/mdast": "^4.0.0", + "mdast-util-from-markdown": "^2.0.0", + "micromark-util-types": "^2.0.0", + "unified": "^11.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-preset-lint-consistent": { + "version": "6.0.0", + "resolved": "https://registry.npmjs.org/remark-preset-lint-consistent/-/remark-preset-lint-consistent-6.0.0.tgz", + "integrity": "sha512-W3fwxajdietwjnFyTH5x2le63hxWGVOXxIs7KjRqU+5wkkN6ZQyuwPeeomblmS9wQr50fkidhXNHNDyCXtqgxQ==", + "dev": true, + "license": "MIT", + "dependencies": { + "remark-lint": "^10.0.0", + "remark-lint-blockquote-indentation": "^4.0.0", + "remark-lint-checkbox-character-style": "^5.0.0", + "remark-lint-code-block-style": "^4.0.0", + "remark-lint-emphasis-marker": "^4.0.0", + "remark-lint-fenced-code-marker": "^4.0.0", + "remark-lint-heading-style": "^4.0.0", + "remark-lint-link-title-style": "^4.0.0", + "remark-lint-list-item-content-indent": "^4.0.0", + "remark-lint-ordered-list-marker-style": "^4.0.0", + "remark-lint-ordered-list-marker-value": "^4.0.0", + "remark-lint-rule-style": "^4.0.0", + "remark-lint-strong-marker": "^4.0.0", + "remark-lint-table-cell-padding": "^5.0.0", + "unified": "^11.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-preset-lint-markdown-style-guide": { + "version": "6.0.0", + "resolved": "https://registry.npmjs.org/remark-preset-lint-markdown-style-guide/-/remark-preset-lint-markdown-style-guide-6.0.0.tgz", + "integrity": "sha512-izsfNTHeqrRP64VWV6OdJnSUDwKFSthMKiiDcu14ODpPV0t7YiotCQWzgc7L4eW9Ctcp4aB4nHNLSuDmwhEWrQ==", + "dev": true, + "license": "MIT", + "dependencies": { + "remark-lint": "^10.0.0", + "remark-lint-blockquote-indentation": "^4.0.0", + "remark-lint-code-block-style": "^4.0.0", + "remark-lint-definition-case": "^4.0.0", + "remark-lint-definition-spacing": "^4.0.0", + "remark-lint-emphasis-marker": "^4.0.0", + "remark-lint-fenced-code-flag": "^4.0.0", + "remark-lint-fenced-code-marker": "^4.0.0", + "remark-lint-file-extension": "^3.0.0", + "remark-lint-final-definition": "^4.0.0", + "remark-lint-hard-break-spaces": "^4.0.0", + "remark-lint-heading-increment": "^4.0.0", + "remark-lint-heading-style": "^4.0.0", + "remark-lint-link-title-style": "^4.0.0", + "remark-lint-list-item-content-indent": "^4.0.0", + "remark-lint-list-item-indent": "^4.0.0", + "remark-lint-list-item-spacing": "^5.0.0", + "remark-lint-maximum-heading-length": "^4.0.0", + "remark-lint-maximum-line-length": "^4.0.0", + "remark-lint-no-blockquote-without-marker": "^6.0.0", + "remark-lint-no-consecutive-blank-lines": "^5.0.0", + "remark-lint-no-duplicate-headings": "^4.0.0", + "remark-lint-no-emphasis-as-heading": "^4.0.0", + "remark-lint-no-file-name-articles": "^3.0.0", + "remark-lint-no-file-name-consecutive-dashes": "^3.0.0", + "remark-lint-no-file-name-irregular-characters": "^3.0.0", + "remark-lint-no-file-name-mixed-case": "^3.0.0", + "remark-lint-no-file-name-outer-dashes": "^3.0.0", + "remark-lint-no-heading-punctuation": "^4.0.0", + "remark-lint-no-literal-urls": "^4.0.0", + "remark-lint-no-multiple-toplevel-headings": "^4.0.0", + "remark-lint-no-shell-dollars": "^4.0.0", + "remark-lint-no-shortcut-reference-image": "^4.0.0", + "remark-lint-no-shortcut-reference-link": "^4.0.0", + "remark-lint-no-table-indentation": "^5.0.0", + "remark-lint-ordered-list-marker-style": "^4.0.0", + "remark-lint-ordered-list-marker-value": "^4.0.0", + "remark-lint-rule-style": "^4.0.0", + "remark-lint-strong-marker": "^4.0.0", + "remark-lint-table-cell-padding": "^5.0.0", + "remark-lint-table-pipe-alignment": "^4.0.0", + "remark-lint-table-pipes": "^5.0.0", + "remark-lint-unordered-list-marker-style": "^4.0.0", + "unified": "^11.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-preset-lint-recommended": { + "version": "7.0.0", + "resolved": "https://registry.npmjs.org/remark-preset-lint-recommended/-/remark-preset-lint-recommended-7.0.0.tgz", + "integrity": "sha512-A9aPDL78OO12xG2a83DVd+M2QzdBMjn545fbXj40BFJdpt9t//MADkPAwRfpMCBkKi+iECPUTFCb3Jm8SsFG2w==", + "dev": true, + "license": "MIT", + "dependencies": { + "remark-lint": "^10.0.0", + "remark-lint-final-newline": "^3.0.0", + "remark-lint-hard-break-spaces": "^4.0.0", + "remark-lint-list-item-bullet-indent": "^5.0.0", + "remark-lint-list-item-indent": "^4.0.0", + "remark-lint-no-blockquote-without-marker": "^6.0.0", + "remark-lint-no-duplicate-definitions": "^4.0.0", + "remark-lint-no-heading-content-indent": "^5.0.0", + "remark-lint-no-literal-urls": "^4.0.0", + "remark-lint-no-shortcut-reference-image": "^4.0.0", + "remark-lint-no-shortcut-reference-link": "^4.0.0", + "remark-lint-no-undefined-references": "^5.0.0", + "remark-lint-no-unused-definitions": "^4.0.0", + "remark-lint-ordered-list-marker-style": "^4.0.0", + "unified": "^11.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-rehype": { + "version": "11.1.1", + "resolved": "https://registry.npmjs.org/remark-rehype/-/remark-rehype-11.1.1.tgz", + "integrity": "sha512-g/osARvjkBXb6Wo0XvAeXQohVta8i84ACbenPpoSsxTOQH/Ae0/RGP4WZgnMH5pMLpsj4FG7OHmcIcXxpza8eQ==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/hast": "^3.0.0", + "@types/mdast": "^4.0.0", + "mdast-util-to-hast": "^13.0.0", + "unified": "^11.0.0", + "vfile": "^6.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-stringify": { + "version": "11.0.0", + "resolved": "https://registry.npmjs.org/remark-stringify/-/remark-stringify-11.0.0.tgz", + "integrity": "sha512-1OSmLd3awB/t8qdoEOMazZkNsfVTeY4fTsgzcQFdXNq8ToTN4ZGwrMnlda4K6smTFKD+GRV6O48i6Z4iKgPPpw==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/mdast": "^4.0.0", + "mdast-util-to-markdown": "^2.0.0", + "unified": "^11.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-torchlight": { + "version": "0.0.5", + "resolved": "https://registry.npmjs.org/remark-torchlight/-/remark-torchlight-0.0.5.tgz", + "integrity": "sha512-aFnnUfbIGYFYr1HQDT8AVHBVsRRswLBdOM4ht9YB8e+gyV9UKN64b9i7xwRqWu78bzXTmxhqcQxnIaVNQO4iWA==", + "dev": true, + "license": "MIT", + "dependencies": { + "@torchlight-api/torchlight-cli": "^0.1.7", + "hast-util-from-parse5": "^7.1.0", + "parse5": "^6.0.1", + "unist-util-map": "^3.0.0" + } + }, + "node_modules/remark-torchlight/node_modules/@types/hast": { + "version": "2.3.10", + "resolved": "https://registry.npmjs.org/@types/hast/-/hast-2.3.10.tgz", + "integrity": "sha512-McWspRw8xx8J9HurkVBfYj0xKoE25tOFlHGdx4MJ5xORQrMGZNqJhVQWaIbm6Oyla5kYOXtDiopzKRJzEOkwJw==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/unist": "^2" + } + }, + "node_modules/remark-torchlight/node_modules/hast-util-from-parse5": { + "version": "7.1.2", + "resolved": "https://registry.npmjs.org/hast-util-from-parse5/-/hast-util-from-parse5-7.1.2.tgz", + "integrity": "sha512-Nz7FfPBuljzsN3tCQ4kCBKqdNhQE2l0Tn+X1ubgKBPRoiDIu1mL08Cfw4k7q71+Duyaw7DXDN+VTAp4Vh3oCOw==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/hast": "^2.0.0", + "@types/unist": "^2.0.0", + "hastscript": "^7.0.0", + "property-information": "^6.0.0", + "vfile": "^5.0.0", + "vfile-location": "^4.0.0", + "web-namespaces": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-torchlight/node_modules/hast-util-parse-selector": { + "version": "3.1.1", + "resolved": "https://registry.npmjs.org/hast-util-parse-selector/-/hast-util-parse-selector-3.1.1.tgz", + "integrity": "sha512-jdlwBjEexy1oGz0aJ2f4GKMaVKkA9jwjr4MjAAI22E5fM/TXVZHuS5OpONtdeIkRKqAaryQ2E9xNQxijoThSZA==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/hast": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-torchlight/node_modules/hastscript": { + "version": "7.2.0", + "resolved": "https://registry.npmjs.org/hastscript/-/hastscript-7.2.0.tgz", + "integrity": "sha512-TtYPq24IldU8iKoJQqvZOuhi5CyCQRAbvDOX0x1eW6rsHSxa/1i2CCiptNTotGHJ3VoHRGmqiv6/D3q113ikkw==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/hast": "^2.0.0", + "comma-separated-tokens": "^2.0.0", + "hast-util-parse-selector": "^3.0.0", + "property-information": "^6.0.0", + "space-separated-tokens": "^2.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/remark-torchlight/node_modules/is-buffer": { + "version": "2.0.5", + "resolved": "https://registry.npmjs.org/is-buffer/-/is-buffer-2.0.5.tgz", + "integrity": "sha512-i2R6zNFDwgEHJyQUtJEk0XFi1i0dPFn/oqjK3/vPCcDeJvW5NQ83V8QbicfF1SupOaB0h8ntgBC2YiE7dfyctQ==", + "dev": true, + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ], + "license": "MIT", + "engines": { + "node": ">=4" + } + }, + "node_modules/remark-torchlight/node_modules/parse5": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/parse5/-/parse5-6.0.1.tgz", + "integrity": "sha512-Ofn/CTFzRGTTxwpNEs9PP93gXShHcTq255nzRYSKe8AkVpZY7e1fpmTfOyoIvjP5HG7Z2ZM7VS9PPhQGW2pOpw==", + "dev": true, + "license": "MIT" + }, + "node_modules/remark-torchlight/node_modules/unist-util-stringify-position": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/unist-util-stringify-position/-/unist-util-stringify-position-3.0.3.tgz", + "integrity": "sha512-k5GzIBZ/QatR8N5X2y+drfpWG8IDBzdnVj6OInRNWm1oXrzydiaAT2OQiA8DPRRZyAKb9b6I2a6PxYklZD0gKg==", + "dev": true, "license": "MIT", "dependencies": { - "@types/mdast": "^4.0.0", - "mdast-util-from-markdown": "^2.0.0", - "micromark-util-types": "^2.0.0", - "unified": "^11.0.0" + "@types/unist": "^2.0.0" }, "funding": { "type": "opencollective", "url": "https://opencollective.com/unified" } }, - "node_modules/remark-preset-lint-markdown-style-guide": { - "version": "6.0.0", - "resolved": "https://registry.npmjs.org/remark-preset-lint-markdown-style-guide/-/remark-preset-lint-markdown-style-guide-6.0.0.tgz", - "integrity": "sha512-izsfNTHeqrRP64VWV6OdJnSUDwKFSthMKiiDcu14ODpPV0t7YiotCQWzgc7L4eW9Ctcp4aB4nHNLSuDmwhEWrQ==", + "node_modules/remark-torchlight/node_modules/vfile": { + "version": "5.3.7", + "resolved": "https://registry.npmjs.org/vfile/-/vfile-5.3.7.tgz", + "integrity": "sha512-r7qlzkgErKjobAmyNIkkSpizsFPYiUPuJb5pNW1RB4JcYVZhs4lIbVqk8XPk033CV/1z8ss5pkax8SuhGpcG8g==", + "dev": true, "license": "MIT", "dependencies": { - "remark-lint": "^10.0.0", - "remark-lint-blockquote-indentation": "^4.0.0", - "remark-lint-code-block-style": "^4.0.0", - "remark-lint-definition-case": "^4.0.0", - "remark-lint-definition-spacing": "^4.0.0", - "remark-lint-emphasis-marker": "^4.0.0", - "remark-lint-fenced-code-flag": "^4.0.0", - "remark-lint-fenced-code-marker": "^4.0.0", - "remark-lint-file-extension": "^3.0.0", - "remark-lint-final-definition": "^4.0.0", - "remark-lint-hard-break-spaces": "^4.0.0", - "remark-lint-heading-increment": "^4.0.0", - "remark-lint-heading-style": "^4.0.0", - "remark-lint-link-title-style": "^4.0.0", - "remark-lint-list-item-content-indent": "^4.0.0", - "remark-lint-list-item-indent": "^4.0.0", - "remark-lint-list-item-spacing": "^5.0.0", - "remark-lint-maximum-heading-length": "^4.0.0", - "remark-lint-maximum-line-length": "^4.0.0", - "remark-lint-no-blockquote-without-marker": "^6.0.0", - "remark-lint-no-consecutive-blank-lines": "^5.0.0", - "remark-lint-no-duplicate-headings": "^4.0.0", - "remark-lint-no-emphasis-as-heading": "^4.0.0", - "remark-lint-no-file-name-articles": "^3.0.0", - "remark-lint-no-file-name-consecutive-dashes": "^3.0.0", - "remark-lint-no-file-name-irregular-characters": "^3.0.0", - "remark-lint-no-file-name-mixed-case": "^3.0.0", - "remark-lint-no-file-name-outer-dashes": "^3.0.0", - "remark-lint-no-heading-punctuation": "^4.0.0", - "remark-lint-no-literal-urls": "^4.0.0", - "remark-lint-no-multiple-toplevel-headings": "^4.0.0", - "remark-lint-no-shell-dollars": "^4.0.0", - "remark-lint-no-shortcut-reference-image": "^4.0.0", - "remark-lint-no-shortcut-reference-link": "^4.0.0", - "remark-lint-no-table-indentation": "^5.0.0", - "remark-lint-ordered-list-marker-style": "^4.0.0", - "remark-lint-ordered-list-marker-value": "^4.0.0", - "remark-lint-rule-style": "^4.0.0", - "remark-lint-strong-marker": "^4.0.0", - "remark-lint-table-cell-padding": "^5.0.0", - "remark-lint-table-pipe-alignment": "^4.0.0", - "remark-lint-table-pipes": "^5.0.0", - "remark-lint-unordered-list-marker-style": "^4.0.0", - "unified": "^11.0.0" + "@types/unist": "^2.0.0", + "is-buffer": "^2.0.0", + "unist-util-stringify-position": "^3.0.0", + "vfile-message": "^3.0.0" }, "funding": { "type": "opencollective", "url": "https://opencollective.com/unified" } }, - "node_modules/remark-rehype": { - "version": "11.1.1", - "resolved": "https://registry.npmjs.org/remark-rehype/-/remark-rehype-11.1.1.tgz", - "integrity": "sha512-g/osARvjkBXb6Wo0XvAeXQohVta8i84ACbenPpoSsxTOQH/Ae0/RGP4WZgnMH5pMLpsj4FG7OHmcIcXxpza8eQ==", + "node_modules/remark-torchlight/node_modules/vfile-location": { + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/vfile-location/-/vfile-location-4.1.0.tgz", + "integrity": "sha512-YF23YMyASIIJXpktBa4vIGLJ5Gs88UB/XePgqPmTa7cDA+JeO3yclbpheQYCHjVHBn/yePzrXuygIL+xbvRYHw==", + "dev": true, "license": "MIT", "dependencies": { - "@types/hast": "^3.0.0", - "@types/mdast": "^4.0.0", - "mdast-util-to-hast": "^13.0.0", - "unified": "^11.0.0", - "vfile": "^6.0.0" + "@types/unist": "^2.0.0", + "vfile": "^5.0.0" }, "funding": { "type": "opencollective", "url": "https://opencollective.com/unified" } }, - "node_modules/remark-stringify": { - "version": "11.0.0", - "resolved": "https://registry.npmjs.org/remark-stringify/-/remark-stringify-11.0.0.tgz", - "integrity": "sha512-1OSmLd3awB/t8qdoEOMazZkNsfVTeY4fTsgzcQFdXNq8ToTN4ZGwrMnlda4K6smTFKD+GRV6O48i6Z4iKgPPpw==", + "node_modules/remark-torchlight/node_modules/vfile-message": { + "version": "3.1.4", + "resolved": "https://registry.npmjs.org/vfile-message/-/vfile-message-3.1.4.tgz", + "integrity": "sha512-fa0Z6P8HUrQN4BZaX05SIVXic+7kE3b05PWAtPuYP9QLHsLKYR7/AlLW3NtOrpXRLeawpDLMsVkmk5DG0NXgWw==", + "dev": true, "license": "MIT", "dependencies": { - "@types/mdast": "^4.0.0", - "mdast-util-to-markdown": "^2.0.0", - "unified": "^11.0.0" + "@types/unist": "^2.0.0", + "unist-util-stringify-position": "^3.0.0" }, "funding": { "type": "opencollective", "url": "https://opencollective.com/unified" } }, - "node_modules/remark-torchlight": { - "version": "0.0.5", - "resolved": "https://registry.npmjs.org/remark-torchlight/-/remark-torchlight-0.0.5.tgz", - "integrity": "sha512-aFnnUfbIGYFYr1HQDT8AVHBVsRRswLBdOM4ht9YB8e+gyV9UKN64b9i7xwRqWu78bzXTmxhqcQxnIaVNQO4iWA==", - "license": "MIT", - "dependencies": { - "@torchlight-api/torchlight-cli": "^0.1.7", - "hast-util-from-parse5": "^7.1.0", - "parse5": "^6.0.1", - "unist-util-map": "^3.0.0" - } - }, "node_modules/remark-validate-links": { "version": "13.0.1", "resolved": "https://registry.npmjs.org/remark-validate-links/-/remark-validate-links-13.0.1.tgz", "integrity": "sha512-GWDZWJAQU0+Fsm1GCLNeJoVcE9L3XTVrWCgQZOYREfXqRFIYaSoIBbARZizLm/vBESq+a3GwEBnIflSCNw26tw==", + "dev": true, "license": "MIT", "dependencies": { "@types/hosted-git-info": "^3.0.0", @@ -6696,6 +7337,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/resolve-from/-/resolve-from-4.0.0.tgz", "integrity": "sha512-pb/MYmXstAkysRFx8piNI1tGFNQIFA3vkE3Gq4EuA1dF6gHp/+vgZqsCGJapvy8N3Q+4o7FwvquPJcnZ7RYy4g==", + "dev": true, "license": "MIT", "engines": { "node": ">=4" @@ -6705,6 +7347,7 @@ "version": "3.1.0", "resolved": "https://registry.npmjs.org/restore-cursor/-/restore-cursor-3.1.0.tgz", "integrity": "sha512-l+sSefzHpj5qimhFSE5a8nufZYAM3sBSVMAPtYkmC+4EH2anSGaEMXSD0izRQbu9nfyQ9y5JrVmp7E8oZrUjvA==", + "dev": true, "license": "MIT", "dependencies": { "onetime": "^5.1.0", @@ -6718,6 +7361,7 @@ "version": "0.12.0", "resolved": "https://registry.npmjs.org/retry/-/retry-0.12.0.tgz", "integrity": "sha512-9LkiTwjUh6rT555DtE9rTX+BKByPfrMzEAtnlEtdEwr3Nkffwiihqe2bWADg+OQRjt9gl6ICdmB/ZFDCGAtSow==", + "dev": true, "license": "MIT", "engines": { "node": ">= 4" @@ -6727,6 +7371,7 @@ "version": "1.0.4", "resolved": "https://registry.npmjs.org/reusify/-/reusify-1.0.4.tgz", "integrity": "sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw==", + "dev": true, "license": "MIT", "engines": { "iojs": ">=1.0.0", @@ -6737,6 +7382,7 @@ "version": "2.4.1", "resolved": "https://registry.npmjs.org/run-async/-/run-async-2.4.1.tgz", "integrity": "sha512-tvVnVv01b8c1RrA6Ep7JkStj85Guv/YrMcwqYQnwjsAS2cTmmPGBBjAjpCW7RrSodNSoE2/qg9O4bceNvUuDgQ==", + "dev": true, "license": "MIT", "engines": { "node": ">=0.12.0" @@ -6746,6 +7392,7 @@ "version": "1.2.0", "resolved": "https://registry.npmjs.org/run-parallel/-/run-parallel-1.2.0.tgz", "integrity": "sha512-5l4VyZR86LZ/lDxZTR6jqL8AFE2S0IFLMP26AbjsLVADxHdhB/c0GUsH+y39UfCi3dzz8OlQuPmnaJOMoDHQBA==", + "dev": true, "funding": [ { "type": "github", @@ -6769,6 +7416,7 @@ "version": "7.8.1", "resolved": "https://registry.npmjs.org/rxjs/-/rxjs-7.8.1.tgz", "integrity": "sha512-AA3TVj+0A2iuIoQkWEK/tqFjBq2j+6PO6Y0zJcvzLAFhEFIO3HL0vls9hWLncZbAAbK0mar7oZ4V079I/qPMxg==", + "dev": true, "license": "Apache-2.0", "dependencies": { "tslib": "^2.1.0" @@ -6797,6 +7445,7 @@ "version": "5.2.1", "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.2.1.tgz", "integrity": "sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==", + "dev": true, "funding": [ { "type": "github", @@ -6835,6 +7484,7 @@ "version": "2.1.2", "resolved": "https://registry.npmjs.org/safer-buffer/-/safer-buffer-2.1.2.tgz", "integrity": "sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==", + "dev": true, "license": "MIT" }, "node_modules/semver": { @@ -6885,6 +7535,7 @@ "version": "2.0.0", "resolved": "https://registry.npmjs.org/shebang-command/-/shebang-command-2.0.0.tgz", "integrity": "sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==", + "dev": true, "license": "MIT", "dependencies": { "shebang-regex": "^3.0.0" @@ -6897,6 +7548,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/shebang-regex/-/shebang-regex-3.0.0.tgz", "integrity": "sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==", + "dev": true, "license": "MIT", "engines": { "node": ">=8" @@ -6925,12 +7577,14 @@ "version": "3.0.7", "resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-3.0.7.tgz", "integrity": "sha512-wnD2ZE+l+SPC/uoS0vXeE9L1+0wuaMqKlfz9AMUo38JsyLSBWSFcHR1Rri62LZc12vLr1gb3jl7iwQhgwpAbGQ==", + "dev": true, "license": "ISC" }, "node_modules/space-separated-tokens": { "version": "2.0.2", "resolved": "https://registry.npmjs.org/space-separated-tokens/-/space-separated-tokens-2.0.2.tgz", "integrity": "sha512-PEGlAwrG8yXGXRjW32fGbg66JAlOAwbObuqVoJpv/mRgoWDQfgH1wDPvtzWyUSNAXBGSk8h755YDbbcEy3SH2Q==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -6941,6 +7595,7 @@ "version": "3.2.0", "resolved": "https://registry.npmjs.org/spdx-correct/-/spdx-correct-3.2.0.tgz", "integrity": "sha512-kN9dJbvnySHULIluDHy32WHRUu3Og7B9sbY7tsFLctQkIqnMh3hErYgdMjTYuqmcXX+lK5T1lnUt3G7zNswmZA==", + "dev": true, "license": "Apache-2.0", "dependencies": { "spdx-expression-parse": "^3.0.0", @@ -6951,12 +7606,14 @@ "version": "2.5.0", "resolved": "https://registry.npmjs.org/spdx-exceptions/-/spdx-exceptions-2.5.0.tgz", "integrity": "sha512-PiU42r+xO4UbUS1buo3LPJkjlO7430Xn5SVAhdpzzsPHsjbYVflnnFdATgabnLude+Cqu25p6N+g2lw/PFsa4w==", + "dev": true, "license": "CC-BY-3.0" }, "node_modules/spdx-expression-parse": { "version": "3.0.1", "resolved": "https://registry.npmjs.org/spdx-expression-parse/-/spdx-expression-parse-3.0.1.tgz", "integrity": "sha512-cbqHunsQWnJNE6KhVSMsMeH5H/L9EpymbzqTQ3uLwNCLZ1Q481oWaofqH7nO6V07xlXwY6PhQdQ2IedWx/ZK4Q==", + "dev": true, "license": "MIT", "dependencies": { "spdx-exceptions": "^2.1.0", @@ -6967,12 +7624,14 @@ "version": "3.0.20", "resolved": "https://registry.npmjs.org/spdx-license-ids/-/spdx-license-ids-3.0.20.tgz", "integrity": "sha512-jg25NiDV/1fLtSgEgyvVyDunvaNHbuwF9lfNV17gSmPFAlYzdfNBlLtLzXTevwkPj7DhGbmN9VnmJIgLnhvaBw==", + "dev": true, "license": "CC0-1.0" }, "node_modules/string_decoder": { "version": "1.3.0", "resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-1.3.0.tgz", "integrity": "sha512-hkRX8U1WjJFd8LsDJ2yQ/wWWxaopEsABU1XfkM8A+j0+85JAGppt16cr1Whg6KIbb4okU6Mql6BOj+uup/wKeA==", + "dev": true, "license": "MIT", "dependencies": { "safe-buffer": "~5.2.0" @@ -6982,6 +7641,7 @@ "version": "4.2.3", "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz", "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==", + "dev": true, "license": "MIT", "dependencies": { "emoji-regex": "^8.0.0", @@ -6997,6 +7657,7 @@ "version": "4.2.3", "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz", "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==", + "dev": true, "license": "MIT", "dependencies": { "emoji-regex": "^8.0.0", @@ -7063,6 +7724,7 @@ "version": "4.0.4", "resolved": "https://registry.npmjs.org/stringify-entities/-/stringify-entities-4.0.4.tgz", "integrity": "sha512-IwfBptatlO+QCJUo19AqvrPNqlVMpW9YEL2LIVY+Rpv2qsjCGxaDLNRgeGsQWJhfItebuJhsGSLjaBbNSQ+ieg==", + "dev": true, "license": "MIT", "dependencies": { "character-entities-html4": "^2.0.0", @@ -7077,6 +7739,7 @@ "version": "6.0.1", "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "dev": true, "license": "MIT", "dependencies": { "ansi-regex": "^5.0.1" @@ -7090,6 +7753,7 @@ "version": "6.0.1", "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "dev": true, "license": "MIT", "dependencies": { "ansi-regex": "^5.0.1" @@ -7112,6 +7776,7 @@ "version": "3.1.1", "resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-3.1.1.tgz", "integrity": "sha512-6fPc+R4ihwqP6N/aIv2f1gMH8lOVtWQHoqC4yK6oSDVVocumAsfCqjkXnqiYMhmMwS/mEHLp7Vehlt3ql6lEig==", + "dev": true, "license": "MIT", "engines": { "node": ">=8" @@ -7124,6 +7789,7 @@ "version": "7.2.0", "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-7.2.0.tgz", "integrity": "sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==", + "dev": true, "license": "MIT", "dependencies": { "has-flag": "^4.0.0" @@ -7149,18 +7815,21 @@ "version": "0.2.0", "resolved": "https://registry.npmjs.org/text-table/-/text-table-0.2.0.tgz", "integrity": "sha512-N+8UisAXDGk8PFXP4HAzVR9nbfmVJ3zYLAWiTIoqC5v5isinhr+r5uaO8+7r3BMfuNIufIsA7RdpVgacC2cSpw==", + "dev": true, "license": "MIT" }, "node_modules/through": { "version": "2.3.8", "resolved": "https://registry.npmjs.org/through/-/through-2.3.8.tgz", "integrity": "sha512-w89qg7PI8wAdvX60bMDP+bFoD5Dvhm9oLheFp5O4a2QF0cSBGsBX4qZmadPMvVqlLJBBci+WqGGOAPvcDeNSVg==", + "dev": true, "license": "MIT" }, "node_modules/tmp": { "version": "0.0.33", "resolved": "https://registry.npmjs.org/tmp/-/tmp-0.0.33.tgz", "integrity": "sha512-jRCJlojKnZ3addtTOjdIqoRuPEKBvNXcGYqzO6zWZX8KfKEpnGY5jfggJQ3EjKuu8D4bJRr0y+cYJFmYbImXGw==", + "dev": true, "license": "MIT", "dependencies": { "os-tmpdir": "~1.0.2" @@ -7173,6 +7842,7 @@ "version": "5.0.1", "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz", "integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==", + "dev": true, "license": "MIT", "dependencies": { "is-number": "^7.0.0" @@ -7185,6 +7855,7 @@ "version": "3.0.1", "resolved": "https://registry.npmjs.org/trim-lines/-/trim-lines-3.0.1.tgz", "integrity": "sha512-kRj8B+YHZCc9kQYdWfJB2/oUl9rA99qbowYYBtr4ui4mZyAQ2JpvVBd/6U2YloATfqBhBTSMhTpgBHtU0Mf3Rg==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -7195,6 +7866,7 @@ "version": "2.2.0", "resolved": "https://registry.npmjs.org/trough/-/trough-2.2.0.tgz", "integrity": "sha512-tmMpK00BjZiUyVyvrBK7knerNgmgvcV/KLVyuma/SC+TQN167GrMRciANTz09+k3zW8L8t60jWO1GpfkZdjTaw==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -7205,6 +7877,7 @@ "version": "1.3.0", "resolved": "https://registry.npmjs.org/ts-api-utils/-/ts-api-utils-1.3.0.tgz", "integrity": "sha512-UQMIo7pb8WRomKR1/+MFVLTroIvDVtMX3K6OUir8ynLyzB8Jeriont2bTAtmNPa1ekAgN7YPDyf6V+ygrdU+eQ==", + "dev": true, "license": "MIT", "engines": { "node": ">=16" @@ -7230,12 +7903,14 @@ "version": "2.8.0", "resolved": "https://registry.npmjs.org/tslib/-/tslib-2.8.0.tgz", "integrity": "sha512-jWVzBLplnCmoaTr13V9dYbiQ99wvZRd0vNWaDRg+aVYRcjDF3nDksxFDE/+fkXnKhpnUUkmx5pK/v8mCtLVqZA==", + "dev": true, "license": "0BSD" }, "node_modules/type-check": { "version": "0.4.0", "resolved": "https://registry.npmjs.org/type-check/-/type-check-0.4.0.tgz", "integrity": "sha512-XleUoc9uwGXqjWwXaUTZAmzMcFZ5858QA2vvx1Ur5xIcixXIP+8LnFDgRplU30us6teqdlskFfu+ae4K79Ooew==", + "dev": true, "license": "MIT", "dependencies": { "prelude-ls": "^1.2.1" @@ -7325,12 +8000,14 @@ "version": "0.0.6", "resolved": "https://registry.npmjs.org/typedarray/-/typedarray-0.0.6.tgz", "integrity": "sha512-/aCDEGatGvZ2BIk+HmLf4ifCJFwvKFNb9/JeZPMulfgFracn9QFcAf5GO8B/mweUjSoblS5In0cWhqpfs/5PQA==", + "dev": true, "license": "MIT" }, "node_modules/typescript": { "version": "5.6.3", "resolved": "https://registry.npmjs.org/typescript/-/typescript-5.6.3.tgz", "integrity": "sha512-hjcS1mhfuyi4WW8IWtjP7brDrG2cuDZukyrYrSauoXGNgx0S7zceP07adYkJycEr56BOUTNPzbInooiN3fn1qw==", + "dev": true, "license": "Apache-2.0", "peer": true, "bin": { @@ -7361,6 +8038,7 @@ "version": "6.20.1", "resolved": "https://registry.npmjs.org/undici/-/undici-6.20.1.tgz", "integrity": "sha512-AjQF1QsmqfJys+LXfGTNum+qw4S88CojRInG/6t31W/1fk6G59s92bnAvGz5Cmur+kQv2SURXEvvudLmbrE8QA==", + "dev": true, "license": "MIT", "engines": { "node": ">=18.17" @@ -7370,12 +8048,14 @@ "version": "6.19.8", "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-6.19.8.tgz", "integrity": "sha512-ve2KP6f/JnbPBFyobGHuerC9g1FYGn/F8n1LWTwNxCEzd6IfqTwUQcNXgEtmmQ6DlRrC1hrSrBnCZPokRrDHjw==", + "dev": true, "license": "MIT" }, "node_modules/unified": { "version": "11.0.5", "resolved": "https://registry.npmjs.org/unified/-/unified-11.0.5.tgz", "integrity": "sha512-xKvGhPWw3k84Qjh8bI3ZeJjqnyadK+GEFtazSfZv/rKeTkTjOJho6mFqh2SM96iIcZokxiOpg78GazTSg8+KHA==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0", @@ -7391,10 +8071,88 @@ "url": "https://opencollective.com/unified" } }, + "node_modules/unified-args": { + "version": "11.0.1", + "resolved": "https://registry.npmjs.org/unified-args/-/unified-args-11.0.1.tgz", + "integrity": "sha512-WEQghE91+0s3xPVs0YW6a5zUduNLjmANswX7YbBfksHNDGMjHxaWCql4SR7c9q0yov/XiIEdk6r/LqfPjaYGcw==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/text-table": "^0.2.0", + "chalk": "^5.0.0", + "chokidar": "^3.0.0", + "comma-separated-tokens": "^2.0.0", + "json5": "^2.0.0", + "minimist": "^1.0.0", + "strip-ansi": "^7.0.0", + "text-table": "^0.2.0", + "unified-engine": "^11.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/unified-args/node_modules/ansi-regex": { + "version": "6.1.0", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.1.0.tgz", + "integrity": "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA==", + "dev": true, + "license": "MIT", + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/ansi-regex?sponsor=1" + } + }, + "node_modules/unified-args/node_modules/chalk": { + "version": "5.3.0", + "resolved": "https://registry.npmjs.org/chalk/-/chalk-5.3.0.tgz", + "integrity": "sha512-dLitG79d+GV1Nb/VYcCDFivJeK1hiukt9QjRNVOsUtTy1rR1YJsmpGGTZ3qJos+uw7WmWF4wUwBd9jxjocFC2w==", + "dev": true, + "license": "MIT", + "engines": { + "node": "^12.17.0 || ^14.13 || >=16.0.0" + }, + "funding": { + "url": "https://github.com/chalk/chalk?sponsor=1" + } + }, + "node_modules/unified-args/node_modules/json5": { + "version": "2.2.3", + "resolved": "https://registry.npmjs.org/json5/-/json5-2.2.3.tgz", + "integrity": "sha512-XmOWe7eyHYH14cLdVPoyg+GOH3rYX++KpzrylJwSW98t3Nk+U8XOl8FWKOgwtzdb8lXGf6zYwDUzeHMWfxasyg==", + "dev": true, + "license": "MIT", + "bin": { + "json5": "lib/cli.js" + }, + "engines": { + "node": ">=6" + } + }, + "node_modules/unified-args/node_modules/strip-ansi": { + "version": "7.1.0", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz", + "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==", + "dev": true, + "license": "MIT", + "dependencies": { + "ansi-regex": "^6.0.1" + }, + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/strip-ansi?sponsor=1" + } + }, "node_modules/unified-engine": { "version": "11.2.1", "resolved": "https://registry.npmjs.org/unified-engine/-/unified-engine-11.2.1.tgz", "integrity": "sha512-xBAdZ8UY2X4R9Hm6X6kMne4Nz0PlpOc1oE6DPeqJnewr5Imkb8uT5Eyvy1h7xNekPL3PSWh3ZJyNrMW6jnNQBg==", + "dev": true, "license": "MIT", "dependencies": { "@types/concat-stream": "^2.0.0", @@ -7428,12 +8186,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/unified-engine/node_modules/brace-expansion": { "version": "2.0.1", "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", + "dev": true, "license": "MIT", "dependencies": { "balanced-match": "^1.0.0" @@ -7443,6 +8203,7 @@ "version": "10.4.5", "resolved": "https://registry.npmjs.org/glob/-/glob-10.4.5.tgz", "integrity": "sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==", + "dev": true, "license": "ISC", "dependencies": { "foreground-child": "^3.1.0", @@ -7463,6 +8224,7 @@ "version": "9.0.5", "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.5.tgz", "integrity": "sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==", + "dev": true, "license": "ISC", "dependencies": { "brace-expansion": "^2.0.1" @@ -7478,6 +8240,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/unified-lint-rule/-/unified-lint-rule-3.0.0.tgz", "integrity": "sha512-Sz96ILLsTy3djsG3H44zFb2b77MFf9CQVYnV3PWkxgRX8/n31fFrr+JnzUaJ6cbOHTtZnL1A71+YodsTjzwAew==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0", @@ -7494,12 +8257,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/unified-message-control": { "version": "5.0.0", "resolved": "https://registry.npmjs.org/unified-message-control/-/unified-message-control-5.0.0.tgz", "integrity": "sha512-B2cSAkpuMVVmPP90KCfKdBhm1e9KYJ+zK3x5BCa0N65zpq1Ybkc9C77+M5qwR8FWO7RF3LM5QRRPZtgjW6DUCw==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0", @@ -7520,18 +8285,21 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/unified/node_modules/@types/unist": { "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/unist-builder": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/unist-builder/-/unist-builder-4.0.0.tgz", "integrity": "sha512-wmRFnH+BLpZnTKpc5L7O67Kac89s9HMrtELpnNaE6TAobq5DTZZs5YaTQfAZBA9bFPECx2uVAPO31c+GVug8mg==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0" @@ -7545,12 +8313,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/unist-util-find-after": { "version": "5.0.0", "resolved": "https://registry.npmjs.org/unist-util-find-after/-/unist-util-find-after-5.0.0.tgz", "integrity": "sha512-amQa0Ep2m6hE2g72AugUItjbuM8X8cGQnFoHk0pGfrFeT9GZhzN5SW8nRsiGKK7Aif4CrACPENkA6P/Lw6fHGQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0", @@ -7565,12 +8335,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/unist-util-find-between-all": { "version": "1.0.5", "resolved": "https://registry.npmjs.org/unist-util-find-between-all/-/unist-util-find-between-all-1.0.5.tgz", "integrity": "sha512-zqpIPPzhbG6fI5lqYZhS1UPsMvxV9IY6dwbizLHLPAGNb3pQT3mTvmzXpP1K2lmUh4bhUwAN4gkQcxhR/OLS4g==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0", @@ -7585,12 +8357,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/unist-util-inspect": { "version": "8.1.0", "resolved": "https://registry.npmjs.org/unist-util-inspect/-/unist-util-inspect-8.1.0.tgz", "integrity": "sha512-mOlg8Mp33pR0eeFpo5d2902ojqFFOKMMG2hF8bmH7ZlhnmjFgh0NI3/ZDwdaBJNbvrS7LZFVrBVtIE9KZ9s7vQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0" @@ -7604,12 +8378,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/unist-util-is": { "version": "6.0.0", "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-6.0.0.tgz", "integrity": "sha512-2qCTHimwdxLfz+YzdGfkqNlH0tLi9xjTnHddPmJwtIG9MGsdbutfTc4P+haPD7l7Cjxf/WZj+we5qfVPvvxfYw==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0" @@ -7623,12 +8399,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/unist-util-map": { "version": "3.1.3", "resolved": "https://registry.npmjs.org/unist-util-map/-/unist-util-map-3.1.3.tgz", "integrity": "sha512-4/mDauoxqZ6geK97lJ6n2kDk6JK88Vh+hWMSJqyaaP/7eqN1dDhjcjnNxKNm3YU6Sw7PVJtcFMUbnmHvYzb6Vg==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^2.0.0" @@ -7642,6 +8420,7 @@ "version": "5.0.0", "resolved": "https://registry.npmjs.org/unist-util-position/-/unist-util-position-5.0.0.tgz", "integrity": "sha512-fucsC7HjXvkB5R3kTCO7kUjRdrS0BJt3M/FPxmHMBOm8JQi2BsHAHFsy27E0EolP8rp0NzXsJ+jNPyDWvOJZPA==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0" @@ -7655,12 +8434,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/unist-util-stringify-position": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/unist-util-stringify-position/-/unist-util-stringify-position-4.0.0.tgz", "integrity": "sha512-0ASV06AAoKCDkS2+xw5RXJywruurpbC4JZSm7nr7MOt1ojAzvyyaO+UxZf18j8FCF6kmzCZKcAgN/yu2gm2XgQ==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0" @@ -7674,12 +8455,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/unist-util-visit": { "version": "5.0.0", "resolved": "https://registry.npmjs.org/unist-util-visit/-/unist-util-visit-5.0.0.tgz", "integrity": "sha512-MR04uvD+07cwl/yhVuVWAtw+3GOR/knlL55Nd/wAdblk27GCVt3lqpTivy/tkJcZoNPzTwS1Y+KMojlLDhoTzg==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0", @@ -7695,6 +8478,7 @@ "version": "6.0.1", "resolved": "https://registry.npmjs.org/unist-util-visit-parents/-/unist-util-visit-parents-6.0.1.tgz", "integrity": "sha512-L/PqWzfTP9lzzEa6CKs0k2nARxTdZduw3zyh8d2NVBnsyvHjSX4TWse388YrrQKbvI8w20fGjGlhgT96WwKykw==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0", @@ -7709,18 +8493,21 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/unist-util-visit/node_modules/@types/unist": { "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/universalify": { "version": "2.0.1", "resolved": "https://registry.npmjs.org/universalify/-/universalify-2.0.1.tgz", "integrity": "sha512-gptHNQghINnc/vTGIk0SOFGFNXw7JVrlRUtConJRlvaw6DuX0wO5Jeko9sWrMBhh+PsYAZ7oXAiOnf/UKogyiw==", + "dev": true, "license": "MIT", "engines": { "node": ">= 10.0.0" @@ -7730,6 +8517,7 @@ "version": "4.4.1", "resolved": "https://registry.npmjs.org/uri-js/-/uri-js-4.4.1.tgz", "integrity": "sha512-7rKUyy33Q1yc98pQ1DAmLtwX109F7TIfWlW1Ydo8Wl1ii1SeHieeh0HHfPeL2fMXK6z0s8ecKs9frCuLJvndBg==", + "dev": true, "license": "BSD-2-Clause", "dependencies": { "punycode": "^2.1.0" @@ -7739,12 +8527,14 @@ "version": "1.0.2", "resolved": "https://registry.npmjs.org/util-deprecate/-/util-deprecate-1.0.2.tgz", "integrity": "sha512-EPD5q1uXyFxJpCrLnCc1nHnq3gOa6DZBocAIiI2TaSCA7VCJ1UJDMagCzIkXNsUYfD1daK//LTEQ8xiIbrHtcw==", + "dev": true, "license": "MIT" }, "node_modules/validate-npm-package-license": { "version": "3.0.4", "resolved": "https://registry.npmjs.org/validate-npm-package-license/-/validate-npm-package-license-3.0.4.tgz", "integrity": "sha512-DpKm2Ui/xN7/HQKCtpZxoRWBhZ9Z0kqtygG8XCgNQ8ZlDnxuQmWhj566j8fN4Cu3/JmbhsDo7fcAJq4s9h27Ew==", + "dev": true, "license": "Apache-2.0", "dependencies": { "spdx-correct": "^3.0.0", @@ -7755,6 +8545,7 @@ "version": "5.0.1", "resolved": "https://registry.npmjs.org/validate-npm-package-name/-/validate-npm-package-name-5.0.1.tgz", "integrity": "sha512-OljLrQ9SQdOUqTaQxqL5dEfZWrXExyyWsozYlAWFawPVNuD83igl7uJD2RTkNMbniIYgt8l81eCJGIdQF7avLQ==", + "dev": true, "license": "ISC", "engines": { "node": "^14.17.0 || ^16.13.0 || >=18.0.0" @@ -7764,6 +8555,7 @@ "version": "6.0.3", "resolved": "https://registry.npmjs.org/vfile/-/vfile-6.0.3.tgz", "integrity": "sha512-KzIbH/9tXat2u30jf+smMwFCsno4wHVdNmzFyL+T/L3UGqqk6JKfVqOFOZEpZSHADH1k40ab6NUIXZq422ov3Q==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0", @@ -7778,6 +8570,7 @@ "version": "5.0.3", "resolved": "https://registry.npmjs.org/vfile-location/-/vfile-location-5.0.3.tgz", "integrity": "sha512-5yXvWDEgqeiYiBe1lbxYF7UMAIm/IcopxMHrMQDq3nvKcjPKIhZklUKL+AE7J7uApI4kwe2snsK+eI6UTj9EHg==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0", @@ -7792,12 +8585,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/vfile-message": { "version": "4.0.2", "resolved": "https://registry.npmjs.org/vfile-message/-/vfile-message-4.0.2.tgz", "integrity": "sha512-jRDZ1IMLttGj41KcZvlrYAaI3CfqpLpfpf+Mfig13viT6NKvRzWZ+lXz0Y5D60w6uJIBAOGq9mSHf0gktF0duw==", + "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^3.0.0", @@ -7812,12 +8607,14 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/vfile-reporter": { "version": "8.1.1", "resolved": "https://registry.npmjs.org/vfile-reporter/-/vfile-reporter-8.1.1.tgz", "integrity": "sha512-qxRZcnFSQt6pWKn3PAk81yLK2rO2i7CDXpy8v8ZquiEOMLSnPw6BMSi9Y1sUCwGGl7a9b3CJT1CKpnRF7pp66g==", + "dev": true, "license": "MIT", "dependencies": { "@types/supports-color": "^8.0.0", @@ -7838,6 +8635,7 @@ "version": "6.1.0", "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.1.0.tgz", "integrity": "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA==", + "dev": true, "license": "MIT", "engines": { "node": ">=12" @@ -7850,12 +8648,14 @@ "version": "10.4.0", "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-10.4.0.tgz", "integrity": "sha512-EC+0oUMY1Rqm4O6LLrgjtYDvcVYTy7chDnM4Q7030tP4Kwj3u/pR6gP9ygnp2CJMK5Gq+9Q2oqmrFJAz01DXjw==", + "dev": true, "license": "MIT" }, "node_modules/vfile-reporter/node_modules/string-width": { "version": "6.1.0", "resolved": "https://registry.npmjs.org/string-width/-/string-width-6.1.0.tgz", "integrity": "sha512-k01swCJAgQmuADB0YIc+7TuatfNvTBVOoaUWJjTB9R4VJzR5vNWzf5t42ESVZFPS8xTySF7CAdV4t/aaIm3UnQ==", + "dev": true, "license": "MIT", "dependencies": { "eastasianwidth": "^0.2.0", @@ -7873,6 +8673,7 @@ "version": "7.1.0", "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz", "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==", + "dev": true, "license": "MIT", "dependencies": { "ansi-regex": "^6.0.1" @@ -7888,6 +8689,7 @@ "version": "9.4.0", "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-9.4.0.tgz", "integrity": "sha512-VL+lNrEoIXww1coLPOmiEmK/0sGigko5COxI09KzHc2VJXJsQ37UaQ+8quuxjDeA7+KnLGTWRyOXSLLR2Wb4jw==", + "dev": true, "license": "MIT", "engines": { "node": ">=12" @@ -7900,6 +8702,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/vfile-sort/-/vfile-sort-4.0.0.tgz", "integrity": "sha512-lffPI1JrbHDTToJwcq0rl6rBmkjQmMuXkAxsZPRS9DXbaJQvc642eCg6EGxcX2i1L+esbuhq+2l9tBll5v8AeQ==", + "dev": true, "license": "MIT", "dependencies": { "vfile": "^6.0.0", @@ -7914,6 +8717,7 @@ "version": "3.0.0", "resolved": "https://registry.npmjs.org/vfile-statistics/-/vfile-statistics-3.0.0.tgz", "integrity": "sha512-/qlwqwWBWFOmpXujL/20P+Iuydil0rZZNglR+VNm6J0gpLHwuVM5s7g2TfVoswbXjZ4HuIhLMySEyIw5i7/D8w==", + "dev": true, "license": "MIT", "dependencies": { "vfile": "^6.0.0", @@ -7928,18 +8732,21 @@ "version": "3.0.3", "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, "license": "MIT" }, "node_modules/walk-up-path": { "version": "3.0.1", "resolved": "https://registry.npmjs.org/walk-up-path/-/walk-up-path-3.0.1.tgz", "integrity": "sha512-9YlCL/ynK3CTlrSRrDxZvUauLzAswPCrsaCgilqFevUYpeEW0/3ScEjaa3kbW/T0ghhkEr7mv+fpjqn1Y1YuTA==", + "dev": true, "license": "ISC" }, "node_modules/wcwidth": { "version": "1.0.1", "resolved": "https://registry.npmjs.org/wcwidth/-/wcwidth-1.0.1.tgz", "integrity": "sha512-XHPEwS0q6TaxcvG85+8EYkbiCux2XtWG2mkc47Ng2A77BQu9+DqIOJldST4HgPkuea7dvKSj5VgX3P1d4rW8Tg==", + "dev": true, "license": "MIT", "dependencies": { "defaults": "^1.0.3" @@ -7949,6 +8756,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/web-namespaces/-/web-namespaces-2.0.1.tgz", "integrity": "sha512-bKr1DkiNa2krS7qxNtdrtHAmzuYGFQLiQ13TsorsdT6ULTkPLKuu5+GsFpDlg6JFjUTwX2DyhMPG2be8uPrqsQ==", + "dev": true, "license": "MIT", "funding": { "type": "github", @@ -7959,6 +8767,7 @@ "version": "3.1.1", "resolved": "https://registry.npmjs.org/whatwg-encoding/-/whatwg-encoding-3.1.1.tgz", "integrity": "sha512-6qN4hJdMwfYBtE3YBTTHhoeuUrDBPZmbQaxWAqSALV/MeEnR5z1xd8UKud2RAkFoPkmB+hli1TZSnyi84xz1vQ==", + "dev": true, "license": "MIT", "dependencies": { "iconv-lite": "0.6.3" @@ -7971,6 +8780,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/whatwg-mimetype/-/whatwg-mimetype-4.0.0.tgz", "integrity": "sha512-QaKxh0eNIi2mE9p2vEdzfagOKHCcj1pJ56EEHGQOVxp8r9/iszLUUV7v89x9O1p/T+NlTM5W7jW6+cz4Fq1YVg==", + "dev": true, "license": "MIT", "engines": { "node": ">=18" @@ -7980,6 +8790,7 @@ "version": "2.0.2", "resolved": "https://registry.npmjs.org/which/-/which-2.0.2.tgz", "integrity": "sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==", + "dev": true, "license": "ISC", "dependencies": { "isexe": "^2.0.0" @@ -8032,6 +8843,7 @@ "version": "1.2.5", "resolved": "https://registry.npmjs.org/word-wrap/-/word-wrap-1.2.5.tgz", "integrity": "sha512-BN22B5eaMMI9UMtjrGd5g5eCYPpCPDUy0FJXbYsaT5zYxjFOckS53SQDE3pWkVoWpHXVb3BrYcEN4Twa55B5cA==", + "dev": true, "license": "MIT", "engines": { "node": ">=0.10.0" @@ -8041,6 +8853,7 @@ "version": "6.2.0", "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-6.2.0.tgz", "integrity": "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA==", + "dev": true, "license": "MIT", "dependencies": { "ansi-styles": "^4.0.0", @@ -8056,6 +8869,7 @@ "version": "7.0.0", "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz", "integrity": "sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==", + "dev": true, "license": "MIT", "dependencies": { "ansi-styles": "^4.0.0", @@ -8073,6 +8887,7 @@ "version": "2.6.0", "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.6.0.tgz", "integrity": "sha512-a6ae//JvKDEra2kdi1qzCyrJW/WZCgFi8ydDV+eXExl95t+5R+ijnqHJbz9tmMh8FUjx3iv2fCQ4dclAQlO2UQ==", + "dev": true, "license": "ISC", "bin": { "yaml": "bin.mjs" @@ -8085,6 +8900,7 @@ "version": "0.1.0", "resolved": "https://registry.npmjs.org/yocto-queue/-/yocto-queue-0.1.0.tgz", "integrity": "sha512-rVksvsnNCdJ/ohGc6xgPwyN8eheCxsiLM8mxuE/t/mOVqJewPuO1miLpTHQiRgTKCLexL4MeAFVagts7HmNZ2Q==", + "dev": true, "license": "MIT", "engines": { "node": ">=10" @@ -8097,6 +8913,7 @@ "version": "2.0.4", "resolved": "https://registry.npmjs.org/zwitch/-/zwitch-2.0.4.tgz", "integrity": "sha512-bXE4cR/kVZhKZX/RjPEflHaKVhUVl85noU3v6b8apfQEc1x4A+zBxjZ4lN8LqGd6WZ3dl98pY4o717VFmoPp+A==", + "dev": true, "license": "MIT", "funding": { "type": "github", diff --git a/package.json b/package.json index bb25a6bc..f979a1a4 100644 --- a/package.json +++ b/package.json @@ -5,32 +5,31 @@ "type": "module", "main": "index.js", "scripts": { - "lint": "eslint build/", - "build-all": "node build/build.js jsonschema-*.md proposals/*.md output/*.md", - "build": "node build/build.js" + "lint": "eslint . ; remark --no-stdout --frail specs/", + "build-all": "remark --rc-path specs/.remarkrc-build.js --output web/ specs/", + "build": "remark --rc-path specs/.remarkrc-build.js --output web/" }, "license": "MIT", - "dependencies": { + "devDependencies": { "@stylistic/eslint-plugin": "^2.9.0", + "dotenv": "^16.4.5", + "eslint": "^9.13.0", + "eslint-import-resolver-node": "^0.3.9", + "eslint-plugin-import": "^2.31.0", "mdast-builder": "^1.1.1", "mdast-util-find-and-replace": "^3.0.1", "mdast-util-to-string": "^4.0.0", + "rehype-document": "^7.0.3", "rehype-stringify": "^10.0.1", - "remark": "^15.0.1", + "remark-cli": "^12.0.1", "remark-flexible-containers": "^1.2.1", "remark-gfm": "^4.0.0", "remark-heading-id": "^1.0.1", + "remark-preset-lint-consistent": "^6.0.0", "remark-preset-lint-markdown-style-guide": "^6.0.0", + "remark-preset-lint-recommended": "^7.0.0", "remark-rehype": "^11.1.1", "remark-torchlight": "^0.0.5", - "remark-validate-links": "^13.0.1", - "unist-builder": "^4.0.0", - "vfile-reporter": "^8.1.1" - }, - "devDependencies": { - "dotenv": "^16.4.5", - "eslint": "^9.12.0", - "eslint-import-resolver-node": "^0.3.9", - "eslint-plugin-import": "^2.31.0" + "remark-validate-links": "^13.0.1" } } diff --git a/build/remark-code-titles.js b/remark/remark-code-titles.js similarity index 100% rename from build/remark-code-titles.js rename to remark/remark-code-titles.js diff --git a/build/remark-headings.js b/remark/remark-headings.js similarity index 100% rename from build/remark-headings.js rename to remark/remark-headings.js diff --git a/build/remark-reference-links.js b/remark/remark-reference-links.js similarity index 100% rename from build/remark-reference-links.js rename to remark/remark-reference-links.js diff --git a/build/remark-table-of-contents.js b/remark/remark-table-of-contents.js similarity index 100% rename from build/remark-table-of-contents.js rename to remark/remark-table-of-contents.js diff --git a/specs/.remarkrc-build.js b/specs/.remarkrc-build.js new file mode 100644 index 00000000..89ca8695 --- /dev/null +++ b/specs/.remarkrc-build.js @@ -0,0 +1,29 @@ +import { readFileSync } from "node:fs"; +import { resolve } from "node:path"; +import dotenv from "dotenv"; +import remarkTorchLight from "remark-torchlight"; +import remarkRehype from "remark-rehype"; +import rehypeStringify from "rehype-stringify"; +import rehypeDocument from "rehype-document"; +import specsPreset from "./.remarkrc-specs.js"; + + +dotenv.config(); + +export default { + plugins: [ + specsPreset, + remarkTorchLight, + remarkRehype, + [rehypeDocument, { + css: ["https://cdn.jsdelivr.net/npm/water.css@2/out/dark.css"], + style: readFileSync(resolve(import.meta.dirname, "spec.css"), "utf8") + }], + rehypeStringify, + () => (_tree, file) => { + if (file.extname) { + file.extname = ".html"; + } + } + ] +}; diff --git a/specs/.remarkrc-specs.js b/specs/.remarkrc-specs.js new file mode 100644 index 00000000..2e3058e6 --- /dev/null +++ b/specs/.remarkrc-specs.js @@ -0,0 +1,42 @@ +import remarkGfm from "remark-gfm"; +import remarkHeadingId from "remark-heading-id"; +import remarkFlexibleContainers from "remark-flexible-containers"; +import remarkCodeTitles from "../remark/remark-code-titles.js"; +import remarkHeadings from "../remark/remark-headings.js"; +import remarkReferenceLinks from "../remark/remark-reference-links.js"; +import remarkTableOfContents from "../remark/remark-table-of-contents.js"; + + +export default { + plugins: [ + remarkGfm, + remarkHeadingId, + [remarkHeadings, { + startDepth: 2, + skip: [ + "Abstract", + "Status", + "Note to Readers", + "Table of Contents", + "Authors' Addresses", + "Champions", + "\\[.*\\]", + "draft-.*" + ] + }], + remarkReferenceLinks, + [remarkTableOfContents, { + startDepth: 2, + skip: [ + "Abstract", + "Note to Readers", + "Authors' Addresses", + "Champions", + "\\[.*\\]", + "draft-.*" + ] + }], + remarkFlexibleContainers, + remarkCodeTitles + ] +}; diff --git a/specs/.remarkrc.js b/specs/.remarkrc.js new file mode 100644 index 00000000..11ab67dc --- /dev/null +++ b/specs/.remarkrc.js @@ -0,0 +1,10 @@ +import specPreset from "./.remarkrc-specs.js"; +import lintPreset from "../.remarkrc-lint.js"; + + +export default { + plugins: [ + specPreset, + lintPreset + ] +}; diff --git a/jsonschema-core.md b/specs/jsonschema-core.md similarity index 99% rename from jsonschema-core.md rename to specs/jsonschema-core.md index 1e041667..8b2be269 100644 --- a/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -2456,8 +2456,6 @@ to the document. ## [Appendix] Change Log[^19] -[^19]: This section to be removed before leaving Internet-Draft status. - ### draft-bhutton-json-schema-next - Use IRIs instead of URIs, including allowing unicode in plain-name fragments - Clarify that detecting duplicate IRIs for different schemas SHOULD raise an @@ -2619,7 +2617,9 @@ to the document. ## Authors' Addresses | Author | Company | Email | URI | -|--------------------------|---------|-------------------------|----------------------------------| +| ------------------------ | ------- | ----------------------- | -------------------------------- | | Austin Wright (*editor*) | | | | | Ben Hutton (*editor*) | Postman | | | | Greg Dennis | | | | + +[^19]: This section to be removed before leaving Internet-Draft status. diff --git a/jsonschema-validation.md b/specs/jsonschema-validation.md similarity index 88% rename from jsonschema-validation.md rename to specs/jsonschema-validation.md index 4a5ca2d1..c2b50e13 100644 --- a/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -1,3 +1,4 @@ + # JSON Schema Validation: A Vocabulary for Structural Validation of JSON ## Abstract @@ -880,7 +881,7 @@ draft-bhutton-json-schema-01, June 2022, ### Informative References -#### [RFC4329] {#rfc4329} +#### \[RFC4329\] {#rfc4329} Hoehrmann, B., "Scripting Media Types", RFC 4329, DOI 10.17487/RFC4329, April 2006, <>. @@ -895,108 +896,107 @@ Bowman, Gowry Sankar, Donald Pipowitch, Dave Finlay, Denis Laxalde, Phil Sturgeon, Shawn Silverman, and Karen Etheridge for their submissions and patches to the document. -## [Appendix] ChangeLog[^6] -[^6]: This section to be removed before leaving Internet-Draft status. +## [Appendix] Change Log[^6] - *draft-next* - - Use IRIs instead of URIs - - Move "minContains" and "maxContains" to the applicator vocabulary (see - also that changelog) - - Remove the optional automatic second-pass validation of "content*" - keywords - - Clarify that "contentSchema"'s value is a schema just like any other - subschema + - Use IRIs instead of URIs + - Move "minContains" and "maxContains" to the applicator vocabulary (see also + that changelog) + - Remove the optional automatic second-pass validation of "content*" keywords + - Clarify that "contentSchema"'s value is a schema just like any other + subschema - *draft-bhutton-json-schema-validation-01* - - Improve and clarify the `minContains` keyword explanation - - Remove the use of "production" in favour of "ABNF rule" + - Improve and clarify the `minContains` keyword explanation + - Remove the use of "production" in favour of "ABNF rule" - *draft-bhutton-json-schema-validation-00* - - Correct email format RFC reference to 5321 instead of 5322 - - Clarified the set and meaning of `contentEncoding` values - - Reference ECMA-262, 11th edition for regular expression support - - Split `format` into an annotation only vocabulary and an assertion - vocabulary - - Clarify `deprecated` when applicable to arrays + - Correct email format RFC reference to 5321 instead of 5322 + - Clarified the set and meaning of `contentEncoding` values + - Reference ECMA-262, 11th edition for regular expression support + - Split `format` into an annotation only vocabulary and an assertion + vocabulary + - Clarify `deprecated` when applicable to arrays - *draft-handrews-json-schema-validation-02* - - Grouped keywords into formal vocabularies - - Update `format` implementation requirements in terms of vocabularies - - By default, `format` MUST NOT be validated, although validation can be - enabled - - A vocabulary declaration can be used to require `format` validation - - Moved `definitions` to the core spec as `$defs` - - Moved applicator keywords to the core spec - - Renamed the array form of `dependencies` to `dependentRequired`, moved the -schema form to the core spec - - Specified all `content*` keywords as annotations, not assertions - - Added `contentSchema` to allow applying a schema to a string-encoded - document - - Also allow RFC 4648 encodings in `contentEncoding` - - Added `minContains` and `maxContains` - - Update RFC reference for nhostname" and "idn-hostname" - - Add "uuid" and "duration" formats + - Grouped keywords into formal vocabularies + - Update `format` implementation requirements in terms of vocabularies + - By default, `format` MUST NOT be validated, although validation can be + enabled + - A vocabulary declaration can be used to require `format` validation + - Moved `definitions` to the core spec as `$defs` + - Moved applicator keywords to the core spec + - Renamed the array form of `dependencies` to `dependentRequired`, moved the + schema form to the core spec + - Specified all `content*` keywords as annotations, not assertions + - Added `contentSchema` to allow applying a schema to a string-encoded + document + - Also allow RFC 4648 encodings in `contentEncoding` + - Added `minContains` and `maxContains` + - Update RFC reference for nhostname" and "idn-hostname" + - Add "uuid" and "duration" formats - *draft-handrews-json-schema-validation-01* - - This draft is purely a clarification with no functional changes - - Provided the general principle behind ignoring annotations under `not` and - similar cases - - Clarified `if`/`then`/`else` validation interactions - - Clarified `if`/`then`/`else` behavior for annotation - - Minor formatting and cross-referencing improvements + - This draft is purely a clarification with no functional changes + - Provided the general principle behind ignoring annotations under `not` and + similar cases + - Clarified `if`/`then`/`else` validation interactions + - Clarified `if`/`then`/`else` behavior for annotation + - Minor formatting and cross-referencing improvements - *draft-handrews-json-schema-validation-00* - - Added `if`/`then`/`else` - - Classify keywords as assertions or annotations per the core spec - - Warn of possibly removing `dependencies` in the future - - Grouped validation keywords into sub-sections for readability - - Moved `readOnly` from hyper-schema to validation meta-data - - Added `writeOnly` - - Added string-encoded media section, with former hyper-schema `media` - keywords - - Restored "regex" format (removal was unintentional) - - Added "date" and "time" formats, and reserved additional RFC 3339 format - names - - I18N formats: "iri", "iri-reference", "idn-hostname", "idn-email" - - Clarify that "json-pointer" format means string encoding, not URI fragment - - Fixed typo that inverted the meaning of `minimum` and `exclusiveMinimum` - - Move format syntax references into Normative References - - JSON is a normative requirement + - Added `if`/`then`/`else` + - Classify keywords as assertions or annotations per the core spec + - Warn of possibly removing `dependencies` in the future + - Grouped validation keywords into sub-sections for readability + - Moved `readOnly` from hyper-schema to validation meta-data + - Added `writeOnly` + - Added string-encoded media section, with former hyper-schema `media` + keywords + - Restored "regex" format (removal was unintentional) + - Added "date" and "time" formats, and reserved additional RFC 3339 format + names + - I18N formats: "iri", "iri-reference", "idn-hostname", "idn-email" + - Clarify that "json-pointer" format means string encoding, not URI fragment + - Fixed typo that inverted the meaning of `minimum` and `exclusiveMinimum` + - Move format syntax references into Normative References + - JSON is a normative requirement - *draft-wright-json-schema-validation-01* - - Standardized on hyphenated format names with full words ("uriref" becomes - "uri-reference") - - Add the formats "uri-template" and "json-pointer" - - Changed `exclusiveMaximum`/`exclusiveMinimum` from boolean modifiers of - `maximum`/`minimum` to independent numeric fields. - - Split the additionalItems/items into two sections - - Reworked properties/patternProperties/additionalProperties definition - - Added `examples` keyword - - Added `contains` keyword - - Allow empty `required` and `dependencies` arrays - - Fixed `type` reference to primitive types - - Added `const` keyword - - Added `propertyNames` keyword + - Standardized on hyphenated format names with full words ("uriref" becomes + "uri-reference") + - Add the formats "uri-template" and "json-pointer" + - Changed `exclusiveMaximum`/`exclusiveMinimum` from boolean modifiers of + `maximum`/`minimum` to independent numeric fields. + - Split the additionalItems/items into two sections + - Reworked properties/patternProperties/additionalProperties definition + - Added `examples` keyword + - Added `contains` keyword + - Allow empty `required` and `dependencies` arrays + - Fixed `type` reference to primitive types + - Added `const` keyword + - Added `propertyNames` keyword - *draft-wright-json-schema-validation-00* - - Added additional security considerations - - Removed reference to "latest version" meta-schema, use numbered version - instead - - Rephrased many keyword definitions for brevity - - Added "uriref" format that also allows relative URI references + - Added additional security considerations + - Removed reference to "latest version" meta-schema, use numbered version + instead + - Rephrased many keyword definitions for brevity + - Added "uriref" format that also allows relative URI references - *draft-fge-json-schema-validation-00* - - Initial draft. - - Salvaged from draft v3. - - Redefine the `required` keyword. - - Remove `extends`, `disallow` - - Add `anyOf`, `allOf`, `oneOf`, `not`, `definitions`, `minProperties`, - `maxProperties`. - - `dependencies` member values can no longer be single strings; at least one - element is required in a property dependency array. - - Rename `divisibleBy` to `multipleOf`. - - `type` arrays can no longer have schemas; remove `any` as a possible - value. - - Rework the `format` section; make support optional. - - `format": remove attributes "phone", "style", "color"; rename "ip-address" - to "ipv4"; add references for all attributes. - - Provide algorithms to calculate schema(s) for array/object instances. - - Add interoperability considerations. + - Initial draft. + - Salvaged from draft v3. + - Redefine the `required` keyword. + - Remove `extends`, `disallow` + - Add `anyOf`, `allOf`, `oneOf`, `not`, `definitions`, `minProperties`, + `maxProperties`. + - `dependencies` member values can no longer be single strings; at least one + element is required in a property dependency array. + - Rename `divisibleBy` to `multipleOf`. + - `type` arrays can no longer have schemas; remove `any` as a possible value. + - Rework the `format` section; make support optional. + - `format": remove attributes "phone", "style", "color"; rename "ip-address" + to "ipv4"; add references for all attributes. + - Provide algorithms to calculate schema(s) for array/object instances. + - Add interoperability considerations. ## Authors' Addresses | Author | Company | Email | URI | -|--------------------------|---------|----------------------|--------------------------| +| ------------------------ | ------- | -------------------- | ------------------------ | | Austin Wright (*editor*) | | | | | Ben Hutton (*editor*) | Postman | | | + +[^6]: This section to be removed before leaving Internet-Draft status. diff --git a/meta/applicator.json b/specs/meta/applicator.json similarity index 100% rename from meta/applicator.json rename to specs/meta/applicator.json diff --git a/meta/content.json b/specs/meta/content.json similarity index 100% rename from meta/content.json rename to specs/meta/content.json diff --git a/meta/core.json b/specs/meta/core.json similarity index 100% rename from meta/core.json rename to specs/meta/core.json diff --git a/meta/format-annotation.json b/specs/meta/format-annotation.json similarity index 100% rename from meta/format-annotation.json rename to specs/meta/format-annotation.json diff --git a/meta/format-assertion.json b/specs/meta/format-assertion.json similarity index 100% rename from meta/format-assertion.json rename to specs/meta/format-assertion.json diff --git a/meta/meta-data.json b/specs/meta/meta-data.json similarity index 100% rename from meta/meta-data.json rename to specs/meta/meta-data.json diff --git a/meta/unevaluated.json b/specs/meta/unevaluated.json similarity index 100% rename from meta/unevaluated.json rename to specs/meta/unevaluated.json diff --git a/meta/validation.json b/specs/meta/validation.json similarity index 100% rename from meta/validation.json rename to specs/meta/validation.json diff --git a/output/jsonschema-validation-output-machines.md b/specs/output/jsonschema-validation-output-machines.md similarity index 98% rename from output/jsonschema-validation-output-machines.md rename to specs/output/jsonschema-validation-output-machines.md index 9012da2e..b9d1787d 100644 --- a/output/jsonschema-validation-output-machines.md +++ b/specs/output/jsonschema-validation-output-machines.md @@ -1,3 +1,4 @@ + # A Specification for Machine-Readable Output for JSON Schema Validation and Annotation JSON Schema is defined to be platform-independent. As such, to increase @@ -621,37 +622,37 @@ mechanisms appropriate for their users' needs. ### Normative References -#### [RFC2119] {#rfc2119} +#### \[RFC2119\] {#rfc2119} Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>. -#### [RFC3986] {#rfc3986} +#### \[RFC3986\] {#rfc3986} Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <>. -#### [RFC3987] {#rfc3987} +#### \[RFC3987\] {#rfc3987} Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <>. -#### [RFC6901] {#rfc6901} +#### \[RFC6901\] {#rfc6901} Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <>. -#### [RFC8259] {#rfc8259} +#### \[RFC8259\] {#rfc8259} Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <>. -#### [json-schema] {#json-schema} +#### \[json-schema\] {#json-schema} Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON Schema: A Media Type for Describing JSON Documents", Work in Progress, Internet-Draft, diff --git a/output/schema.json b/specs/output/schema.json similarity index 100% rename from output/schema.json rename to specs/output/schema.json diff --git a/proposals/propertyDependencies-adr.md b/specs/proposals/propertyDependencies-adr.md similarity index 100% rename from proposals/propertyDependencies-adr.md rename to specs/proposals/propertyDependencies-adr.md diff --git a/proposals/propertyDependencies.md b/specs/proposals/propertyDependencies.md similarity index 86% rename from proposals/propertyDependencies.md rename to specs/proposals/propertyDependencies.md index ffc45a5f..066b9806 100644 --- a/proposals/propertyDependencies.md +++ b/specs/proposals/propertyDependencies.md @@ -30,7 +30,7 @@ listed on the homepage. ## Conventions and Terminology All conventions and terms used and defined by the [JSON Schema Core -specification](../jsonschema-core.html) also apply to this document. +specification](../jsonschema-core.md) also apply to this document. ## Overview @@ -91,10 +91,11 @@ those goals means that some trade-offs need to be made. The `propertyDependencies` keyword will be added to the `https://json-schema.org/vocab/applicator` [applicator -vocabulary](../jsonschema-core.html#applicatorvocab). +vocabulary](../jsonschema-core.md#applicators). + +1. The following will be added to the JSON Schema Core specification as a + subsection of "Keywords for Applying Subschemas Conditionally". -1. The following will be added to the JSON Schema Core specification as a -subsection of "Keywords for Applying Subschemas Conditionally". > ### `propertyDependencies` > > This keyword specifies subschemas that are evaluated if the instance is an @@ -110,7 +111,7 @@ subsection of "Keywords for Applying Subschemas Conditionally". > > Omitting this keyword has the same behavior as an empty object. -2. The following subschema will be added to the Applicator Vocabulary schema, +1. The following subschema will be added to the Applicator Vocabulary schema, `https://json-schema.org///meta/applicator` at `/properties/propertyDependencies`: @@ -120,8 +121,8 @@ subsection of "Keywords for Applying Subschemas Conditionally". "additionalProperties": { "type": "object", "additionalProperties": { - "$dynamicRef": "#meta", - "default": true + "$dynamicRef": "#meta", + "default": true }, "default": {} } @@ -130,12 +131,12 @@ subsection of "Keywords for Applying Subschemas Conditionally". ## [Appendix] Change Log -- [March 2021] - Initially proposed -- [October 2021] Added to specification document -- [May 2024] Extracted from specification document as experimental feature +- \[March 2021\] - Initially proposed +- \[October 2021\] Added to specification document +- \[May 2024\] Extracted from specification document as experimental feature ## Champions | Champion | Company | Email | URI | -|----------------------------|---------|----------------------|----------------------------------| +| -------------------------- | ------- | -------------------- | -------------------------------- | | Jason Desrosiers | Postman | | | diff --git a/proposals/proposal-template.md b/specs/proposals/proposal-template.md similarity index 94% rename from proposals/proposal-template.md rename to specs/proposals/proposal-template.md index 1c65f770..885a04cc 100644 --- a/proposals/proposal-template.md +++ b/specs/proposals/proposal-template.md @@ -83,10 +83,10 @@ For example ## [Appendix] Change Log -* [MMMM YYYY] Created +- \[MMMM YYYY\] Created ## [Appendix] Champions | Champion | Company | Email | URI | -|----------------------------|---------|-------------------------|----------------------------------| +| -------------------------- | ------- | ----------------------- | -------------------------------- | | Your Name | | | < GitHub profile page > | diff --git a/proposals/vocabularies-adr.md b/specs/proposals/vocabularies-adr.md similarity index 100% rename from proposals/vocabularies-adr.md rename to specs/proposals/vocabularies-adr.md diff --git a/proposals/vocabularies.md b/specs/proposals/vocabularies.md similarity index 98% rename from proposals/vocabularies.md rename to specs/proposals/vocabularies.md index 9690fa64..646f6885 100644 --- a/proposals/vocabularies.md +++ b/specs/proposals/vocabularies.md @@ -260,10 +260,10 @@ please assume conformance with the 2020-12 Core and Validation specifications.* ## [Appendix] Change Log -* 2024-06-10 - Created +- 2024-06-10 - Created ## [Appendix] Champions | Champion | Company | Email | URI | -|-------------|---------|--------------------------------|---------------------------------| +| ----------- | ------- | ------------------------------ | ------------------------------- | | Greg Dennis | | | | diff --git a/schema.json b/specs/schema.json similarity index 100% rename from schema.json rename to specs/schema.json diff --git a/specs/spec.css b/specs/spec.css new file mode 100644 index 00000000..06e9b041 --- /dev/null +++ b/specs/spec.css @@ -0,0 +1,94 @@ +svg { + fill: currentColor; +} + +/* Torchlight */ +pre { + border-radius: 0.5rem; + overflow-x: auto; + margin: 0; +} + +pre.torchlight code { + display: block; + min-width: -webkit-max-content; + min-width: -moz-max-content; + min-width: max-content; + border-radius: 0.5rem; +} + +pre.torchlight code .line { + padding-left: 1rem; + padding-right: 1rem; +} + +pre.torchlight code .line-number, +pre.torchlight code .summary-caret { + margin-right: 1rem; +} + +/* Flexible Code Titles */ +.remark-code-container{ + border-radius: 0.5rem; + margin-top: 1rem; + margin-bottom: 1rem; +} + +.remark-code-title { + height: 1.25rem; + border-radius: 0.5rem 0.5rem 0 0; + position: relative; + top: 0.5rem; + background-color: var(--background-alt); + padding: 0.5rem 0.5rem 0.5rem 2.5rem; + background-repeat: no-repeat; + background-size: 1.25rem; + background-position-y: center; + background-position-x: 0.75rem; +} + +.code-title-unknown { + padding-left: 1rem; +} + +.code-title-jsonschema { + background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' version='1.1' viewBox='0 0 70.423268 70.42326'%3E%3Cg transform='translate(-104.22785,-45.507923)' id='layer1' fill='%23ffffff'%3E%3Cpath id='path4544' d='m 122.99401,114.18985 c -4.32897,-0.9404 -7.58044,-3.47848 -8.71251,-6.80095 -0.78921,-2.31618 -0.67682,-6.07238 0.33363,-11.150598 0.48507,-2.437836 0.88169,-5.347843 0.88139,-6.466688 -9.8e-4,-3.718098 -1.71106,-5.735418 -5.1001,-6.016462 l -1.9549,-0.162116 v -2.392655 -2.392657 l 1.85208,-0.250855 c 2.70243,-0.366031 3.74441,-1.02838 4.57629,-2.908984 0.61121,-1.381726 0.68884,-2.068648 0.50552,-4.472869 -0.11913,-1.562244 -0.53527,-4.348568 -0.92477,-6.191832 -0.98954,-4.682868 -0.94822,-8.485471 0.11707,-10.773163 1.56862,-3.368589 5.43705,-5.854553 9.93248,-6.382903 l 1.93299,-0.227185 v 2.518015 2.518015 h -1.29973 c -1.77186,0 -4.2497,1.262413 -4.8835,2.488054 -0.60797,1.175674 -0.65405,2.864146 -0.15834,5.802223 0.78343,4.643508 1.04707,9.098344 0.67592,11.421636 -0.42464,2.658142 -1.97477,5.796328 -3.6791,7.448236 l -1.18012,1.143813 1.61497,1.982752 c 1.99051,2.443801 2.76458,4.148744 3.24284,7.142561 0.37835,2.368341 0.0844,7.282673 -0.67072,11.213982 -1.05359,5.48514 0.1623,7.65141 4.66209,8.30613 l 1.67569,0.24382 v 2.44782 c 0,2.79211 0.17086,2.69708 -3.43917,1.91286 z' style='fill:stroke-width:0.35277775'/%3E%3Cpath id='path4546' d='m 152.2304,112.24932 v -2.42987 l 2.04969,-0.42336 c 2.26276,-0.46736 4.054,-1.8634 4.45842,-3.47475 0.1274,-0.50758 -0.11267,-3.16398 -0.53347,-5.90311 -1.37183,-8.929552 -0.6114,-13.537042 2.85482,-17.297452 l 1.48237,-1.60818 -1.1108,-1.26512 c -3.97855,-4.53132 -4.66885,-8.552208 -3.15364,-18.369547 0.76342,-4.946305 0.76409,-4.994322 0.087,-6.173611 -0.79713,-1.388278 -3.28385,-2.776033 -4.97438,-2.776033 h -1.15997 v -2.469445 c 0,-2.811057 -0.0583,-2.773846 3.24583,-2.072788 3.9645,0.841179 6.80448,2.853272 8.27787,5.864775 0.84544,1.728026 0.97275,2.400136 0.94911,5.010889 -0.015,1.658349 -0.35758,4.682054 -0.76125,6.719346 -1.49867,7.563594 -1.3651,9.576204 0.7654,11.532814 0.98915,0.90842 1.64012,1.17274 3.37032,1.36849 l 2.14439,0.24261 v 2.42387 2.42388 l -1.6757,7.1e-4 c -2.1517,7e-4 -3.9323,0.90924 -4.83869,2.46889 -0.95194,1.63803 -0.89239,5.20675 0.17364,10.40695 0.90648,4.421902 1.05253,8.458452 0.3882,10.728752 -0.70059,2.39406 -3.81995,5.29609 -6.74745,6.27718 -1.26118,0.42266 -2.96775,0.87096 -3.79236,0.99623 l -1.49931,0.22775 z' style='stroke-width:0.35277778'/%3E%3Cpath id='path4548' d='m 131.74239,108.26592 c -1.02163,-1.2988 -0.87294,-3.53652 0.38087,-5.73185 0.92776,-1.62446 4.80862,-6.948549 7.61066,-10.440949 l 1.13094,-1.40958 -1.80213,-5.22523 c -2.02147,-5.86123 -2.0098,-5.97467 0.65581,-6.37225 l 1.46834,-0.219 1.64076,3.3506 c 0.90242,1.84283 1.76982,3.35061 1.92755,3.35061 0.15774,0 1.77489,-1.75542 3.59368,-3.90092 3.15918,-3.72667 3.35688,-3.89165 4.42591,-3.69334 0.64552,0.11974 1.21858,0.0465 1.35432,-0.17316 0.31818,-0.51481 1.23083,0.24704 1.23083,1.02746 0,0.32009 -0.45438,1.13409 -1.00972,1.80888 -2.26771,2.75549 -7.10417,9.27155 -7.10417,9.5713 0,0.17685 0.97502,2.45302 2.16671,5.05816 l 2.1667,4.736609 -0.65823,0.98459 c -0.36203,0.54152 -0.66236,1.12603 -0.6674,1.29891 -0.005,0.17288 -0.27769,0.48371 -0.60588,0.69073 -0.83174,0.52464 -1.44656,-0.11541 -3.9894,-4.153119 -1.16417,-1.84856 -2.23163,-3.36491 -2.37215,-3.36967 -0.31309,-0.0106 -3.7911,5.131969 -6.47955,9.580639 -2.37093,3.92324 -1.93885,3.4204 -3.26614,3.80106 -0.95533,0.27398 -1.19348,0.19843 -1.79831,-0.57048 z' style='stroke-width:0.35277775'/%3E%3Cpath id='path4550' d='m 131.98567,83.677091 c -2.15148,-3.8472 -6.0183,-9.42829 -7.57842,-10.93815 -0.79252,-0.76698 -1.44094,-1.57494 -1.44094,-1.79546 0,-0.6016 1.61695,-1.21975 3.19058,-1.21975 1.69822,0 3.49597,1.47777 5.0997,4.19203 0.58208,0.98515 1.15641,1.79434 1.27629,1.79819 0.11988,0.004 0.80873,-1.65116 1.53078,-3.67779 1.5464,-4.34039 5.62351,-12.777999 7.22453,-14.951229 1.3726,-1.86316 3.42936,-2.865165 5.90274,-2.875676 3.23375,-0.01374 3.24268,0.130067 0.20474,3.296663 -4.63599,4.832327 -6.76321,8.809632 -11.25155,21.037252 -1.24637,3.39549 -2.39032,6.47895 -2.54212,6.85214 -0.23022,0.56597 -0.49833,0.28096 -1.61633,-1.71822 z' style='stroke-width:0.35277775'/%3E%3C/g%3E%3C/svg%3E"); +} + +.code-title-json { + background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' version='1.1' viewBox='0 0 70.423268 70.42326'%3E%3Cg transform='translate(-104.22785,-45.507923)' id='layer1' fill='%23ffffff'%3E%3Cpath id='path4544' d='m 122.99401,114.18985 c -4.32897,-0.9404 -7.58044,-3.47848 -8.71251,-6.80095 -0.78921,-2.31618 -0.67682,-6.07238 0.33363,-11.150598 0.48507,-2.437836 0.88169,-5.347843 0.88139,-6.466688 -9.8e-4,-3.718098 -1.71106,-5.735418 -5.1001,-6.016462 l -1.9549,-0.162116 v -2.392655 -2.392657 l 1.85208,-0.250855 c 2.70243,-0.366031 3.74441,-1.02838 4.57629,-2.908984 0.61121,-1.381726 0.68884,-2.068648 0.50552,-4.472869 -0.11913,-1.562244 -0.53527,-4.348568 -0.92477,-6.191832 -0.98954,-4.682868 -0.94822,-8.485471 0.11707,-10.773163 1.56862,-3.368589 5.43705,-5.854553 9.93248,-6.382903 l 1.93299,-0.227185 v 2.518015 2.518015 h -1.29973 c -1.77186,0 -4.2497,1.262413 -4.8835,2.488054 -0.60797,1.175674 -0.65405,2.864146 -0.15834,5.802223 0.78343,4.643508 1.04707,9.098344 0.67592,11.421636 -0.42464,2.658142 -1.97477,5.796328 -3.6791,7.448236 l -1.18012,1.143813 1.61497,1.982752 c 1.99051,2.443801 2.76458,4.148744 3.24284,7.142561 0.37835,2.368341 0.0844,7.282673 -0.67072,11.213982 -1.05359,5.48514 0.1623,7.65141 4.66209,8.30613 l 1.67569,0.24382 v 2.44782 c 0,2.79211 0.17086,2.69708 -3.43917,1.91286 z' style='fill:stroke-width:0.35277775'/%3E%3Cpath id='path4546' d='m 152.2304,112.24932 v -2.42987 l 2.04969,-0.42336 c 2.26276,-0.46736 4.054,-1.8634 4.45842,-3.47475 0.1274,-0.50758 -0.11267,-3.16398 -0.53347,-5.90311 -1.37183,-8.929552 -0.6114,-13.537042 2.85482,-17.297452 l 1.48237,-1.60818 -1.1108,-1.26512 c -3.97855,-4.53132 -4.66885,-8.552208 -3.15364,-18.369547 0.76342,-4.946305 0.76409,-4.994322 0.087,-6.173611 -0.79713,-1.388278 -3.28385,-2.776033 -4.97438,-2.776033 h -1.15997 v -2.469445 c 0,-2.811057 -0.0583,-2.773846 3.24583,-2.072788 3.9645,0.841179 6.80448,2.853272 8.27787,5.864775 0.84544,1.728026 0.97275,2.400136 0.94911,5.010889 -0.015,1.658349 -0.35758,4.682054 -0.76125,6.719346 -1.49867,7.563594 -1.3651,9.576204 0.7654,11.532814 0.98915,0.90842 1.64012,1.17274 3.37032,1.36849 l 2.14439,0.24261 v 2.42387 2.42388 l -1.6757,7.1e-4 c -2.1517,7e-4 -3.9323,0.90924 -4.83869,2.46889 -0.95194,1.63803 -0.89239,5.20675 0.17364,10.40695 0.90648,4.421902 1.05253,8.458452 0.3882,10.728752 -0.70059,2.39406 -3.81995,5.29609 -6.74745,6.27718 -1.26118,0.42266 -2.96775,0.87096 -3.79236,0.99623 l -1.49931,0.22775 z' style='stroke-width:0.35277778'/%3E%3C/g%3E%3C/svg%3E"); +} + +/* Flexible Containers */ +.remark-container { + border: thin solid black; + border-radius: 1rem; + margin-bottom: 1rem; +} + +.remark-container-title { + border-radius: 1rem 1rem 0 0; + position: relative; + padding: .5rem 0 .5rem 2.5rem; + background-color: var(--background); + background-repeat: no-repeat; + background-size: 1.75rem; + background-position-y: center; + background-position-x: .25rem; +} + +.remark-container > :not(.remark-container-title) { + padding: 0 1rem 0 1rem; +} + +.remark-container-title.warning { + background-image: url("data:image/svg+xml,%3Csvg viewBox='0 0 24 24' fill='none' xmlns='http://www.w3.org/2000/svg'%3E%3Cg id='SVGRepo_bgCarrier' stroke-width='0'%3E%3C/g%3E%3Cg id='SVGRepo_tracerCarrier' stroke-linecap='round' stroke-linejoin='round'%3E%3C/g%3E%3Cg id='SVGRepo_iconCarrier'%3E%3Ccircle cx='12' cy='17' r='1' fill='%23ffffff'%3E%3C/circle%3E%3Cpath d='M12 10L12 14' stroke='%23ffffff' stroke-width='2' stroke-linecap='round' stroke-linejoin='round'%3E%3C/path%3E%3Cpath d='M3.44722 18.1056L10.2111 4.57771C10.9482 3.10361 13.0518 3.10362 13.7889 4.57771L20.5528 18.1056C21.2177 19.4354 20.2507 21 18.7639 21H5.23607C3.7493 21 2.78231 19.4354 3.44722 18.1056Z' stroke='%23ffffff' stroke-width='2' stroke-linecap='round' stroke-linejoin='round'%3E%3C/path%3E%3C/g%3E%3C/svg%3E"); +} + +.remark-container-title.note { + background-image: url("data:image/svg+xml,%3Csvg viewBox='0 0 32 32' version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' xmlns:sketch='http://www.bohemiancoding.com/sketch/ns' fill='%23ffffff'%3E%3Cg id='SVGRepo_bgCarrier' stroke-width='0'%3E%3C/g%3E%3Cg id='SVGRepo_tracerCarrier' stroke-linecap='round' stroke-linejoin='round'%3E%3C/g%3E%3Cg id='SVGRepo_iconCarrier'%3E%3Ctitle%3Enote-text%3C/title%3E%3Cdesc%3ECreated with Sketch Beta.%3C/desc%3E%3Cdefs%3E%3C/defs%3E%3Cg id='Page-1' stroke='none' stroke-width='1' fill='none' fill-rule='evenodd' sketch:type='MSPage'%3E%3Cg id='Icon-Set' sketch:type='MSLayerGroup' transform='translate(-308.000000, -99.000000)' fill='%23ffffff'%3E%3Cpath d='M332,107 L316,107 C315.447,107 315,107.448 315,108 C315,108.553 315.447,109 316,109 L332,109 C332.553,109 333,108.553 333,108 C333,107.448 332.553,107 332,107 L332,107 Z M338,127 C338,128.099 336.914,129.012 335.817,129.012 L311.974,129.012 C310.877,129.012 309.987,128.122 309.987,127.023 L309.987,103.165 C309.987,102.066 310.902,101 312,101 L336,101 C337.098,101 338,101.902 338,103 L338,127 L338,127 Z M336,99 L312,99 C309.806,99 308,100.969 308,103.165 L308,127.023 C308,129.22 309.779,131 311.974,131 L335.817,131 C338.012,131 340,129.196 340,127 L340,103 C340,100.804 338.194,99 336,99 L336,99 Z M332,119 L316,119 C315.447,119 315,119.448 315,120 C315,120.553 315.447,121 316,121 L332,121 C332.553,121 333,120.553 333,120 C333,119.448 332.553,119 332,119 L332,119 Z M332,113 L316,113 C315.447,113 315,113.448 315,114 C315,114.553 315.447,115 316,115 L332,115 C332.553,115 333,114.553 333,114 C333,113.448 332.553,113 332,113 L332,113 Z' id='note-text' sketch:type='MSShapeGroup'%3E%3C/path%3E%3C/g%3E%3C/g%3E%3C/g%3E%3C/svg%3E"); +} + +.remark-container-title.experimental { + background-image: url("data:image/svg+xml,%3Csvg version='1.1' id='designs' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' viewBox='0 0 32 32' xml:space='preserve' fill='%23ffffff'%3E%3Cg id='SVGRepo_bgCarrier' stroke-width='0'%3E%3C/g%3E%3Cg id='SVGRepo_tracerCarrier' stroke-linecap='round' stroke-linejoin='round'%3E%3C/g%3E%3Cg id='SVGRepo_iconCarrier'%3E%3Cstyle type='text/css'%3E .sketchy_een%7Bfill:%23ffffff;%7D %3C/style%3E%3Cpath class='sketchy_een' d='M27.958,26.693c-0.023-0.207-0.066-0.377-0.22-0.531c-0.006-0.006-0.015-0.008-0.021-0.014 c0.06-0.187,0.051-0.395-0.057-0.573c-0.326-0.538-0.64-1.08-0.942-1.631c-0.345-0.629-0.716-1.241-1.059-1.87 c-0.351-0.642-0.676-1.296-1.016-1.942c-0.352-0.675-0.773-1.309-1.142-1.974c-0.506-0.907-0.961-1.842-1.47-2.749 c-0.494-0.88-0.958-1.772-1.422-2.667c0.008-0.161-0.007-0.328-0.012-0.488c-0.004-0.168-0.009-0.337-0.017-0.506 c-0.015-0.364-0.042-0.726-0.064-1.087c-0.045-0.722-0.102-1.444-0.133-2.167c-0.062-1.561-0.036-3.121,0.043-4.68 c0.159,0.001,0.318,0.002,0.478,0.001c0.26-0.004,0.519-0.023,0.779-0.011c0.485,0.023,0.89-0.422,0.89-0.89 c0-0.235-0.095-0.462-0.261-0.629c-0.176-0.178-0.386-0.242-0.629-0.261C21.443,2.005,21.202,2,20.96,2 c-0.264,0-0.528,0.006-0.789,0.008C20.05,2.01,19.929,2.01,19.808,2.01c-0.201,0-0.402,0-0.602,0.002 c-0.347,0.004-0.695,0.026-1.042,0.034c-0.39,0.006-0.782,0.002-1.173,0.01c-0.402,0.01-0.803,0.028-1.203,0.042 c-0.769,0.025-1.536,0.068-2.308,0.068c-0.441,0-0.883,0.004-1.322,0c-0.5-0.004-0.998-0.045-1.499-0.066 c-0.445-0.021-0.818,0.386-0.818,0.818c0,0.458,0.373,0.805,0.818,0.82c0.12,0.004,0.24,0.003,0.36,0.006 c0.038,0.704,0.098,1.408,0.133,2.114c0.036,0.722,0.028,1.444,0.049,2.165c0.021,0.68,0.04,1.362,0.061,2.042 c0.019,0.608,0.055,1.214,0.07,1.822c-0.354,0.653-0.68,1.32-1.049,1.964c-0.195,0.341-0.385,0.682-0.563,1.031 c-0.172,0.333-0.316,0.68-0.468,1.023c-0.15,0.337-0.296,0.676-0.46,1.006c-0.165,0.328-0.333,0.656-0.489,0.987 c-0.165,0.352-0.324,0.708-0.493,1.061c-0.155,0.33-0.328,0.652-0.489,0.979c-0.263,0.534-0.496,1.082-0.746,1.622 c-0.267,0.58-0.525,1.165-0.777,1.752c-0.241,0.561-0.519,1.104-0.758,1.665c-0.225,0.529-0.428,1.068-0.647,1.6 c-0.039,0.093-0.079,0.184-0.118,0.278c-0.052,0.117-0.081,0.229-0.091,0.344c-0.087,0.136-0.152,0.288-0.159,0.459 c-0.019,0.46-0.019,0.911,0.218,1.324c0.159,0.281,0.358,0.478,0.618,0.663c0.135,0.095,0.305,0.14,0.457,0.199 c0.241,0.095,0.519,0.097,0.777,0.114c0.368,0.023,0.733,0.002,1.101-0.009c0.402-0.013,0.801-0.034,1.203-0.062 c0.405-0.03,0.813-0.036,1.218-0.047c0.801-0.025,1.605-0.019,2.406-0.004c0.762,0.013,1.519,0.038,2.279,0.1 c0.765,0.064,1.525,0.066,2.292,0.064c0.159,0,0.32,0,0.479,0c0.64,0.002,1.281,0.002,1.923-0.032 c0.756-0.042,1.514-0.053,2.271-0.085c0.392-0.017,0.781-0.055,1.169-0.093c0.377-0.036,0.756-0.047,1.133-0.062 c0.686-0.027,1.37-0.023,2.05-0.117c0.138-0.019,0.277-0.042,0.415-0.07c0.195-0.042,0.369-0.116,0.551-0.195 c0.282-0.121,0.527-0.314,0.748-0.525c0.275-0.261,0.421-0.599,0.53-0.957c0.097-0.314,0.138-0.656,0.114-0.983 C27.973,26.817,27.965,26.756,27.958,26.693z M15.375,3.768c0.449-0.004,0.9-0.002,1.351,0.002c0.322,0.002,0.644,0.006,0.966,0.004 c0.385-0.001,0.77,0.01,1.154,0.021c-0.028,0.789-0.017,1.581-0.015,2.372c0,0.754-0.009,1.51,0.01,2.264 c0.019,0.716,0.047,1.434,0.1,2.15c0.019,0.259,0.042,0.521,0.062,0.782c-0.342,0.013-0.685,0.025-1.027,0.039 c-0.572,0.021-1.146,0.025-1.718,0.068c-1.152,0.088-2.305,0.091-3.46,0.077c-0.036-0.807-0.057-1.615-0.065-2.424 c0.384-0.011,0.768-0.021,1.152-0.032c0.424-0.013,0.781-0.345,0.781-0.781c0-0.42-0.352-0.781-0.774-0.781 c-0.002,0-0.004,0-0.007,0c-0.389,0.004-0.779,0.008-1.168,0.011c-0.002-0.539,0.001-1.077-0.023-1.615 c-0.032-0.719-0.05-1.437-0.076-2.154C13.537,3.779,14.456,3.778,15.375,3.768z M26.457,27.054c-0.021,0.106-0.049,0.21-0.085,0.312 c-0.036,0.076-0.077,0.15-0.122,0.221c-0.054,0.056-0.112,0.108-0.172,0.159c-0.078,0.053-0.159,0.1-0.243,0.141 c-0.225,0.079-0.462,0.123-0.698,0.158c-0.307,0.032-0.615,0.033-0.922,0.049c-0.311,0.015-0.62,0.043-0.928,0.059 c-0.771,0.034-1.535,0.121-2.306,0.154c-0.758,0.032-1.519,0.034-2.279,0.061c-0.803,0.028-1.608,0.028-2.412,0.019 c-0.377-0.004-0.754-0.002-1.131-0.011c-0.366-0.008-0.729-0.034-1.095-0.059c-0.779-0.049-1.557-0.042-2.338-0.03 c-0.799,0.011-1.599,0.04-2.398,0.057c-0.798,0.017-1.591,0.055-2.389,0.055c-0.263,0.002-0.525-0.011-0.786-0.034 c-0.09-0.015-0.179-0.033-0.266-0.059c-0.03-0.015-0.059-0.032-0.087-0.049c-0.01-0.01-0.021-0.02-0.031-0.03 c-0.011-0.018-0.022-0.036-0.032-0.054c-0.005-0.17,0.01-0.342,0.017-0.511c0.005-0.097-0.021-0.188-0.051-0.275 c0.126-0.329,0.26-0.655,0.383-0.984c0.13-0.346,0.26-0.691,0.401-1.033c0.134-0.304,0.277-0.606,0.412-0.91 c0.007-0.015,0.013-0.031,0.02-0.046c0.333,0.005,0.668,0.002,1-0.004c0.582-0.008,1.165-0.017,1.749,0.021 c0.404,0.027,0.741-0.356,0.741-0.741c0-0.411-0.337-0.731-0.741-0.741c-0.692-0.016-1.384-0.045-2.076-0.07 c0.233-0.516,0.471-1.031,0.707-1.547c0.116-0.252,0.241-0.499,0.365-0.746c0.093,0.037,0.192,0.061,0.296,0.058 c0.36-0.008,0.722-0.021,1.082-0.04c0.258-0.013,0.523-0.049,0.782-0.032c0.436,0.03,0.801-0.386,0.801-0.801 c0-0.458-0.366-0.777-0.801-0.803c-0.023-0.002-0.045-0.002-0.068-0.002c-0.083,0-0.165,0.009-0.249,0.014 c-0.15,0.006-0.301,0.006-0.451,0.008c-0.209,0.002-0.419,0.003-0.628,0.004c0.099-0.22,0.198-0.441,0.301-0.66 c0.157-0.33,0.32-0.654,0.468-0.987c0.078-0.177,0.155-0.354,0.232-0.532c0.057,0.012,0.111,0.034,0.171,0.031 c0.754-0.044,1.506-0.097,2.262-0.14c0.419-0.023,0.771-0.333,0.771-0.771c0-0.426-0.35-0.765-0.771-0.773 c-0.067-0.001-0.133-0.001-0.2-0.001c-0.495,0-0.991,0.026-1.486,0.054c0.052-0.101,0.095-0.206,0.15-0.305 c0.34-0.613,0.68-1.226,1.023-1.838c0.055,0.013,0.107,0.034,0.166,0.034c1.25,0.002,2.497-0.082,3.745-0.146 c0.572-0.028,1.146-0.036,1.718-0.049c0.246-0.006,0.494-0.002,0.741,0c0.059,0.002,0.119,0.002,0.18,0.002 c0.034,0,0.069,0.003,0.103,0.003c0,0.14,0.021,0.28,0.091,0.41c0.383,0.71,0.799,1.404,1.203,2.101 c0.385,0.669,0.763,1.338,1.122,2.021c0.356,0.676,0.709,1.355,1.097,2.012c0.189,0.318,0.4,0.623,0.584,0.945 c0.188,0.324,0.358,0.657,0.53,0.991c0.466,0.89,0.949,1.77,1.47,2.631c0.241,0.398,0.468,0.803,0.703,1.205 c0.21,0.356,0.441,0.705,0.629,1.072c0.021,0.042,0.058,0.068,0.088,0.103c-0.04,0.091-0.062,0.19-0.059,0.295 C26.462,26.814,26.465,26.934,26.457,27.054z M24.139,25.03c0.191,0.358,0.093,0.807-0.267,1.017 c-0.172,0.1-0.381,0.129-0.572,0.076c-0.172-0.047-0.368-0.174-0.445-0.341c-0.481-1.029-1.029-2.027-1.555-3.031 c-0.286-0.546-0.557-1.099-0.852-1.641c-0.313-0.576-0.61-1.157-0.894-1.747c-0.093-0.193-0.136-0.383-0.078-0.593 c0.053-0.193,0.182-0.36,0.354-0.46c0.117-0.069,0.253-0.105,0.389-0.105c0.069,0,0.137,0.009,0.204,0.027 c0.178,0.049,0.379,0.182,0.458,0.354c0.28,0.593,0.557,1.186,0.851,1.771c0.277,0.551,0.54,1.11,0.832,1.654 c0.28,0.521,0.57,1.038,0.839,1.565c0.131,0.26,0.26,0.519,0.396,0.773C23.917,24.575,24.02,24.807,24.139,25.03z'%3E%3C/path%3E%3C/g%3E%3C/svg%3E"); +} diff --git a/web/.gitkeep b/web/.gitkeep new file mode 100644 index 00000000..e69de29b From 3a799f40ae794186b1887d4b02820344c737964f Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Mon, 28 Oct 2024 18:30:01 -0700 Subject: [PATCH 673/780] Move IETF specs to the specs folder --- Makefile | 6 +++--- jsonschema-use-cases.xml => specs/jsonschema-use-cases.xml | 0 .../relative-json-pointer.xml | 0 3 files changed, 3 insertions(+), 3 deletions(-) rename jsonschema-use-cases.xml => specs/jsonschema-use-cases.xml (100%) rename relative-json-pointer.xml => specs/relative-json-pointer.xml (100%) diff --git a/Makefile b/Makefile index 4ad478e3..f5b21217 100644 --- a/Makefile +++ b/Makefile @@ -6,13 +6,13 @@ OUT = \ all: $(VENV) $(OUT) -%.txt: %.xml +%.txt: specs/%.xml $(XML2RFC) --text $< -o $@ -%.pdf: %.xml +%.pdf: specs/%.xml $(XML2RFC) --pdf $< -o $@ -%.html: %.xml +%.html: specs/%.xml $(XML2RFC) --html $< -o $@ json-schema.tar.gz: $(OUT) diff --git a/jsonschema-use-cases.xml b/specs/jsonschema-use-cases.xml similarity index 100% rename from jsonschema-use-cases.xml rename to specs/jsonschema-use-cases.xml diff --git a/relative-json-pointer.xml b/specs/relative-json-pointer.xml similarity index 100% rename from relative-json-pointer.xml rename to specs/relative-json-pointer.xml From e65125537e7f2ff2a4b18759e9bcefe6f6b4fbe9 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Wed, 30 Oct 2024 15:20:17 -0700 Subject: [PATCH 674/780] Change appendix heading pattern --- README.md | 2 +- remark/remark-headings.js | 2 +- specs/jsonschema-core.md | 12 ++++++------ specs/jsonschema-validation.md | 4 ++-- specs/proposals/propertyDependencies-adr.md | 2 +- specs/proposals/propertyDependencies.md | 2 +- specs/proposals/proposal-template.md | 4 ++-- specs/proposals/vocabularies.md | 4 ++-- 8 files changed, 16 insertions(+), 16 deletions(-) diff --git a/README.md b/README.md index 9f3e4a42..e68f7b0c 100644 --- a/README.md +++ b/README.md @@ -54,7 +54,7 @@ features they make available to you. - [remark-headings](/json-schema-org/json-schema-spec/blob/main/remark-headings.js) -- A collection of enhancements for headings. - Adds hierarchical section numbers to headings. - - Use the `[Appendix]` prefix on headings that should be numbered as an + - Use the `%appendix%` prefix on headings that should be numbered as an appendix. - Adds id anchors to headers that don't have one - Example: `#section-2-13` diff --git a/remark/remark-headings.js b/remark/remark-headings.js index 6cecefcd..1cc6abb8 100644 --- a/remark/remark-headings.js +++ b/remark/remark-headings.js @@ -7,7 +7,7 @@ import { toString as nodeToString } from "mdast-util-to-string"; const defaultOptions = { startDepth: 1, skip: [], - appendixToken: "[Appendix]", + appendixToken: "%appendix%", appendixPrefix: "Appendix" }; diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 8b2be269..fcce6fad 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -2156,7 +2156,7 @@ Bray, T., Ed., Hollander, D., Ed., Layman, A., Ed., and R. Tobin, Ed., "Namespaces in XML 1.1 (Second Edition)", August 2006, <>. -## [Appendix] Schema identification examples {#idexamples} +## %appendix% Schema identification examples {#idexamples} Consider the following schema, which shows `$id` being used to identify both the root schema and various subschemas, and `$anchor` being used to define plain @@ -2258,7 +2258,7 @@ Document location `/$defs/C`: - base IRI of enclosing (root.json) resource plus fragment: `https://example.com/root.json#/$defs/C` -## [Appendix] Manipulating schema documents and references +## %appendix% Manipulating schema documents and references Various tools have been created to rearrange schema documents based on how and where references (`$ref`) appear. This appendix discusses which use cases and @@ -2300,7 +2300,7 @@ scope of this specification to determine or provide a set of safe `$ref` removal transformations, as they depend not only on the schema structure but also on the intended usage. -## [Appendix] Example of recursive schema extension {#recursive-example} +## %appendix% Example of recursive schema extension {#recursive-example} Consider the following two schemas describing a simple recursive tree structure, where each node in the tree can have a "data" field of any type. The first @@ -2394,7 +2394,7 @@ of the node schema objects were moved under `$defs`. It is the matching `$dynamicAnchor` values which tell us how to resolve the dynamic reference, not any sort of correlation in JSON structure. -## [Appendix] References and generative use cases +## %appendix% References and generative use cases While the presence of references is expected to be transparent to validation results, generative use cases such as code generators and UI renderers often @@ -2444,7 +2444,7 @@ instance of a distinct class. This style of usage requires the annotation to be in the same object as the reference, which must be recognizable as a reference. -## [Appendix] Acknowledgments +## %appendix% Acknowledgments Thanks to Gary Court, Francis Galiegue, Kris Zyp, Geraint Luff, and Henry Andrews for their work on the initial drafts of JSON Schema. @@ -2454,7 +2454,7 @@ Bowman, Gowry Sankar, Donald Pipowitch, Dave Finlay, Denis Laxalde, Phil Sturgeon, Shawn Silverman, and Karen Etheridge for their submissions and patches to the document. -## [Appendix] Change Log[^19] +## %appendix% Change Log[^19] ### draft-bhutton-json-schema-next - Use IRIs instead of URIs, including allowing unicode in plain-name fragments diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index c2b50e13..c6d985ac 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -886,7 +886,7 @@ draft-bhutton-json-schema-01, June 2022, Hoehrmann, B., "Scripting Media Types", RFC 4329, DOI 10.17487/RFC4329, April 2006, <>. -## [Appendix] Acknowledgments +## %appendix% Acknowledgments Thanks to Gary Court, Francis Galiegue, Kris Zyp, Geraint Luff, and Henry Andrews for their work on the initial drafts of JSON Schema. @@ -896,7 +896,7 @@ Bowman, Gowry Sankar, Donald Pipowitch, Dave Finlay, Denis Laxalde, Phil Sturgeon, Shawn Silverman, and Karen Etheridge for their submissions and patches to the document. -## [Appendix] Change Log[^6] +## %appendix% Change Log[^6] - *draft-next* - Use IRIs instead of URIs diff --git a/specs/proposals/propertyDependencies-adr.md b/specs/proposals/propertyDependencies-adr.md index f6ae0200..04db71fc 100644 --- a/specs/proposals/propertyDependencies-adr.md +++ b/specs/proposals/propertyDependencies-adr.md @@ -235,7 +235,7 @@ cases carried a lower priority. - Properties with non-string values cannot be supported using this keyword and the `allOf`-`if`-`then` pattern must still be used. -## [Appendix] Problems With Existing Patterns {#problems} +## %appendix% Problems With Existing Patterns {#problems} ### `oneOf`/`anyOf` diff --git a/specs/proposals/propertyDependencies.md b/specs/proposals/propertyDependencies.md index 066b9806..2e7685f7 100644 --- a/specs/proposals/propertyDependencies.md +++ b/specs/proposals/propertyDependencies.md @@ -129,7 +129,7 @@ vocabulary](../jsonschema-core.md#applicators). } ``` -## [Appendix] Change Log +## %appendix% Change Log - \[March 2021\] - Initially proposed - \[October 2021\] Added to specification document diff --git a/specs/proposals/proposal-template.md b/specs/proposals/proposal-template.md index 885a04cc..e187380d 100644 --- a/specs/proposals/proposal-template.md +++ b/specs/proposals/proposal-template.md @@ -81,11 +81,11 @@ For example ``` --> -## [Appendix] Change Log +## %appendix% Change Log - \[MMMM YYYY\] Created -## [Appendix] Champions +## %appendix% Champions | Champion | Company | Email | URI | | -------------------------- | ------- | ----------------------- | -------------------------------- | diff --git a/specs/proposals/vocabularies.md b/specs/proposals/vocabularies.md index 646f6885..2ddd86ea 100644 --- a/specs/proposals/vocabularies.md +++ b/specs/proposals/vocabularies.md @@ -258,11 +258,11 @@ worth the time and effort to fill in this section just yet. As such, please read the above sections for loose requirements. For tighter requirements, please assume conformance with the 2020-12 Core and Validation specifications.* -## [Appendix] Change Log +## %appendix% Change Log - 2024-06-10 - Created -## [Appendix] Champions +## %appendix% Champions | Champion | Company | Email | URI | | ----------- | ------- | ------------------------------ | ------------------------------- | From 4b21ddd2f3f1e339d8c2993e684684eebc8fcf39 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 31 Oct 2024 11:14:56 -0700 Subject: [PATCH 675/780] Remove bulid-all npm task --- .github/workflows/ci.yml | 2 +- README.md | 4 ++-- package.json | 1 - 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index df0006d7..92557e7f 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -14,7 +14,7 @@ jobs: cache: npm - run: npm ci - run: npm run lint - - run: npm run build-all + - run: npm run build -- specs specs-ietf: runs-on: ubuntu-latest diff --git a/README.md b/README.md index e68f7b0c..8328f069 100644 --- a/README.md +++ b/README.md @@ -25,8 +25,8 @@ Labels are assigned based on [Sensible Github Labels](https://github.com/Releque ## Authoring and Building ### Specification -To build the spec files to HTML from the Markdown sources, run `npm run -build-all`. You can also build each individually with `npm run build -- +To build all the spec files to HTML from the Markdown sources, run `npm run +build -- specs`. You can also build each individually with `npm run build -- specs/filename.md` (Example: `npm run build -- specs/jsonschema-core.md`). You can also use wildcards to build multiple specs at the same time: `npm run build -- specs/jsonschema-*.md`. The HTML files will be available in the `web` folder. diff --git a/package.json b/package.json index f979a1a4..59d407d3 100644 --- a/package.json +++ b/package.json @@ -6,7 +6,6 @@ "main": "index.js", "scripts": { "lint": "eslint . ; remark --no-stdout --frail specs/", - "build-all": "remark --rc-path specs/.remarkrc-build.js --output web/ specs/", "build": "remark --rc-path specs/.remarkrc-build.js --output web/" }, "license": "MIT", From 9b19a36c84604786daaeae1128a05e203e63829e Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Mon, 28 Oct 2024 21:02:51 +1300 Subject: [PATCH 676/780] make format validate by default --- specs/jsonschema-validation.md | 90 +++++++++++++++------------------- 1 file changed, 40 insertions(+), 50 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index c6d985ac..6bfe57a0 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -293,39 +293,46 @@ Structural validation alone may be insufficient to allow an application to correctly utilize certain values. The `format` annotation keyword is defined to allow schema authors to convey semantic information for a fixed subset of values which are accurately described by authoritative resources, be they RFCs or other -external specifications. +external specifications. Format values defined externally to this document +SHOULD also be based on such authoritative resources in order to foster +interoperability. -The value of this keyword is called a format attribute. It MUST be a string. A -format attribute can generally only validate a given set of instance types. If -the type of the instance to validate is not in this set, validation for this -format attribute and instance SHOULD succeed. All format attributes defined in -this section apply to strings, but a format attribute can be specified to apply -to any instance types defined in the data model defined in the [core JSON -Schema.](#json-schema)[^1] +The value of this keyword MUST be a string. While this keyword can validate any +type, each distinct value will generally only validate a given set of instance +types. If the type of the instance to validate is not in this set, validation +for this keyword SHOULD succeed. All format values defined in this section apply +to strings, but a format value can be specified to apply to any instance types +defined in the data model defined in the [core JSON Schema](#json-schema)[^1]. [^1]: Note that the `type` keyword in this specification defines an "integer" type which is not part of the data model. Therefore a format attribute can be limited to numbers, but not specifically to integers. However, a numeric format -can be used alongside the `type` keyword with a value of "integer", or could be -explicitly defined to always pass if the number is not an integer, which +can be used alongside the `type` keyword with a value of "integer", or it could +be explicitly defined to always pass if the number is not an integer, which produces essentially the same behavior as only applying to integers. -Implementing support for `format` as an annotation is REQUIRED (if the -implementation supports annotation collection). +Implementations SHOULD provide assertion behavior for the format values defined +by this document[^2] and MUST refuse to process any schema which contains an +unsupported format value. -Implementing support for `format` as an assertion is OPTIONAL. Implementations -which choose to support assertion behavior: +[^2]: Assertion behavior is called out very explicitly because it is a departure +from previous iterations of this specification. Previously, `format` was an +annotation-only keyword by default and implementations that supported assertion +were required to offer some configuration that allowed users to explicitly +enable assertion. Assertion is now a requirement in order to meet user +expectations. See [json-schema-org/json-schema-spec #1520](https://github.com/json-schema-org/json-schema-spec/issues/1520) for more. + +In addition to the assertion behavior, this keyword also produces its value as +an annotation. + +Implementations: -- MUST still collect the keyword's value as an annotation (if the implementation - supports annotation collection), -- MUST provide a configuration option to enable assertion behavior, defaulting - to annotation-only behavior - SHOULD provide an implementation-specific best effort validation for each - format attribute defined below;[^3] -- MAY choose to implement validation of any or all format attributes as a no-op - by always producing a validation result of true;[^4] -- SHOULD use a common parsing library for each format, or a well-known regular - expression; + format attribute defined in this document;[^3] +- MAY support format values not defined in this document, but such support MUST + be configurable and disabled by default; +- SHOULD use a common parsing library or a well-known regular expression for + each format; - SHOULD clearly document how and to what degree each format attribute is validated. @@ -338,18 +345,11 @@ example, an instance string that does not contain an "@" is clearly not a valid email address, and an "email" or "hostname" containing characters outside of 7-bit ASCII is likewise clearly invalid. -[^4]: This matches the current reality of implementations, which provide widely -varying levels of validation, including no validation at all, for some or all -format attributes. It is also designed to encourage relying only on the -annotation behavior and performing semantic validation in the application, which -is the recommended best practice. - -The requirement for minimal validation of format attributes is +The requirement for minimal validation of format values in general is intentionally vague and permissive, due to the complexity involved in many of the attributes. Note in particular that the requirement is limited to syntactic -checking; it is not to be expected that an implementation would send an email, -attempt to connect to a URL, or otherwise check the existence of an entity -identified by a format instance. +checking; implementations SHOULD NOT attempt to send an email, connect to a URL, +or otherwise check the existence of an entity identified by a format instance. #### Custom format attributes @@ -357,11 +357,6 @@ Implementations MAY support custom format attributes. Save for agreement between parties, schema authors SHALL NOT expect a peer implementation to support such custom format attributes. -An implementation MUST NOT fail to collect unknown formats as annotations. - -When configured for assertion behavior for `format`, implementations MUST fail -upon encountering unknown formats. - ### Defined Formats #### Dates, Times, and Duration @@ -372,22 +367,17 @@ Date and time format names are derived from [RFC 3339, section 5.6](#rfc3339). The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339. -Implementations supporting formats SHOULD implement support for the following -attributes: - -- *date-time:* A string instance is valid against this attribute if it is a +- *date-time*: A string instance is valid against this attribute if it is a valid representation according to the "date-time" ABNF rule (referenced above) -- *date:* A string instance is valid against this attribute if it is a valid +- *date*: A string instance is valid against this attribute if it is a valid representation according to the "full-date" ABNF rule (referenced above) -- *time:* A string instance is valid against this attribute if it is a valid +- *time*: A string instance is valid against this attribute if it is a valid representation according to the "full-time" ABNF rule (referenced above) -- *duration:* A string instance is valid against this attribute if it is a valid +- *duration*: A string instance is valid against this attribute if it is a valid representation according to the "duration" ABNF rule (referenced above) Implementations MAY support additional attributes using the other format names -defined anywhere in that RFC. If "full-date" or "full-time" are implemented, the -corresponding short form ("date" or "time" respectively) MUST be implemented, -and MUST behave identically. Implementations SHOULD NOT define extension +defined anywhere in that RFC. Implementations SHOULD NOT define extension attributes with any name matching an RFC 3339 format unless it validates according to the rules of that format.[^5] @@ -401,7 +391,7 @@ likely either be promoted to fully specified attributes or dropped. These attributes apply to string instances. -A string instance is valid against these attributes if it is a valid Internet +A string instance is valid against these format values if it is a valid Internet email address as follows: - *email:* As defined by the "Mailbox" ABNF rule in [RFC 5321, section @@ -489,7 +479,7 @@ A regular expression, which SHOULD be valid according to the [ECMA-262](#ecma262) regular expression dialect. Implementations that validate formats MUST accept at least the subset of -ECMA-262 defined in {{regexinterop}}), and SHOULD accept all valid ECMA-262 +ECMA-262 defined in {{regexinterop}}, and SHOULD accept all valid ECMA-262 expressions. ## Keywords for the Contents of String-Encoded Data {#content} From 3de61f21eb3aff04714dd703569583177b2a76f7 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 2 Nov 2024 15:06:29 +1300 Subject: [PATCH 677/780] add ADR for change in format behavior --- adr/2024-11-2-assertion-format.md | 74 +++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 adr/2024-11-2-assertion-format.md diff --git a/adr/2024-11-2-assertion-format.md b/adr/2024-11-2-assertion-format.md new file mode 100644 index 00000000..397d5018 --- /dev/null +++ b/adr/2024-11-2-assertion-format.md @@ -0,0 +1,74 @@ +# [short title of solved problem and solution] + +* Status: proposed + +* Deciders: @gregsdennis @jdesrosiers @jviotti @mwadams @karenetheridge @awwright @benjam @relequestual +* Date: 2024-11-02 +* Technical Story: https://github.com/json-schema-org/json-schema-spec/issues/1520 +* Voting issue: https://github.com/json-schema-org/TSC/issues/19 + +## Context and Problem Statement + +There's a long and sticky history around format. + +1. Going back all the way to Draft 01, format has never required validation. +2. Whether to support format validation has always been the decision of the implementation. +3. The extent to which formats are validated has also been the decision of the implementation. + +The result of all of this is that implementation support for validation has been spotty at best. Despite the JSON Schema specs referencing very concretely defined formats (by referencing other specs), implementations that do support validation don't all support each format equally. This has been the primary driving force behind keeping format as an opt-in validation. + +With 2019-09, we decided that it was time to give the option of format validation to the schema author. They could enable validation by using a meta-schema which listed the Format Vocabulary with a true value, which meant, "format validation is required to process this schema." + +In 2020-12, we further refined this by offering two separate vocabularies, one that treats the keyword as an annotation and one that treats it as an assertion. The argument was that the behavior of a keyword shouldn't change based on whether the vocabulary was required or not. + +However, the fact remains that our users consistently report (via questions in Slack, GitHub, and StackOverflow) that they expect format to validate. (The most recent case I can think of was only last week, in .Net's effort to build a short-term solution for schema generation from types.) + +Due to this consistency in user expectations have decided to: + +1. make format an assertion keyword and strictly, +2. enforce it by moving the appropriate tests into the required section of the Test Suite. + +## Decision Drivers + +* User expectation +* Current behavior +* Historical context +* Disparity of current implementation support vs the proposed requirements + +## Considered Options + +### `format` remains an annotation keyword by default + +This is the current state. The primary benefit is that we don't need to make a breaking change. + +The primary downside is that the current system of (1) configuring the tool or (2) incluing the `format-assertion` vocab[^1] is confusing for many and doesn't align with user expectations. + +[^1] The `format-assertion` vocabulary will no longer be an option since we have demoted vocabularies to a proposal for the stable release. This leaves tool configuration as the only option to enable `format` validation. + +### `format` becomes an assertion keyword by default + +We change the spec to require `format` validation. Furthermore: + +* Implementations SHOULD support `format` with the defined values +* Implementations MAY support others, but only by explicit config +* Implementations MUST refuse to process a schema that contains an unsupported format + +## Decision Outcome + +The TSC has decided via vote (see voting issue above) that we should change `format` to act as an assertion by default, in line with option (2). + +### Positive Consequences + +* Aligns with user expectations. +* Users are still able to have purely annotative behavior through use of something like `x-format`. +* Increased consistency for `format` validation across implementations. + +### Negative Consequences + +* This is a breaking change, which means that we will likely have to re-educate our users. +* The burden on implementations will be greater since format validation was previously optional. + +## Links + +* [Link type] [Link to ADR] +* … From e13e15695ce44bd120fc059bd7bda7b759110a92 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 7 Nov 2024 16:14:29 +1300 Subject: [PATCH 678/780] removed permissive language from format requirements --- specs/jsonschema-validation.md | 22 ++++++---------------- 1 file changed, 6 insertions(+), 16 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 6bfe57a0..7ddee49e 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -327,8 +327,8 @@ an annotation. Implementations: -- SHOULD provide an implementation-specific best effort validation for each - format attribute defined in this document;[^3] +- SHOULD provide validation for each format attribute defined in this + document; - MAY support format values not defined in this document, but such support MUST be configurable and disabled by default; - SHOULD use a common parsing library or a well-known regular expression for @@ -336,20 +336,10 @@ Implementations: - SHOULD clearly document how and to what degree each format attribute is validated. -[^3]: The expectation is that for simple formats such as date-time, syntactic -validation will be thorough. For a complex format such as email addresses, which -are the amalgamation of various standards and numerous adjustments over time, -with obscure and/or obsolete rules that may or may not be restricted by other -applications making use of the value, a minimal validation is sufficient. For -example, an instance string that does not contain an "@" is clearly not a valid -email address, and an "email" or "hostname" containing characters outside of -7-bit ASCII is likewise clearly invalid. - -The requirement for minimal validation of format values in general is -intentionally vague and permissive, due to the complexity involved in many of -the attributes. Note in particular that the requirement is limited to syntactic -checking; implementations SHOULD NOT attempt to send an email, connect to a URL, -or otherwise check the existence of an entity identified by a format instance. +The requirement for validation of format values in general is limited to +syntactic checking; implementations SHOULD NOT attempt to send an email, connect +to a URL, or otherwise check the existence of an entity identified by a format +instance. #### Custom format attributes From d1935d2b0dbadce90f64253a51bb2615539c1341 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Mon, 21 Oct 2024 18:18:24 +1300 Subject: [PATCH 679/780] remove redundant sections about keyword independence --- specs/jsonschema-core.md | 23 ----------------------- 1 file changed, 23 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index fcce6fad..350e45ba 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -1468,19 +1468,6 @@ operators can contact the owner of a potentially misbehaving script. This section defines a set of keywords that enable schema combinations and composition. -### Keyword Independence - -Schema keywords typically operate independently, without affecting each other's -outcomes. - -For schema author convenience, there are some exceptions among these keywords: - -- `additionalProperties`, whose behavior is defined in terms of `properties` and - `patternProperties` -- `items`, whose behavior is defined in terms of `prefixItems` -- `contains`, whose behavior is affected by the presence and value of - `minContains` - ### Keywords for Applying Subschemas in Place {#in-place} These keywords apply subschemas to the same location in the instance as the @@ -1822,16 +1809,6 @@ The behaviors of these keywords depend on adjacent keywords as well as any keywords in successfully validated subschemas that apply to the same instance location. -### Keyword Independence - -Schema keywords typically operate independently, without affecting each other's -outcomes. However, these keywords are notable exceptions: - -- `unevaluatedItems`, whose behavior is defined in terms of annotations from - `prefixItems`, `items`, `contains`, and itself -- `unevaluatedProperties`, whose behavior is defined in terms of annotations - from `properties`, `patternProperties`, `additionalProperties`, and itself - ### `unevaluatedItems` {#unevaluateditems} The value of `unevaluatedItems` MUST be a valid JSON Schema. From a0aa2b2ab3d622d5347fcb54f218260e637c72cc Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 13 Nov 2024 10:47:47 +1300 Subject: [PATCH 680/780] remove reference to CBOR as a compatible format --- specs/jsonschema-core.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 350e45ba..d8795678 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -98,8 +98,7 @@ interchangeable because of the data model it defines in {{data-model}}. JSON Schema is only defined over JSON documents. However, any document or memory structure that can be parsed into or processed according to the JSON Schema data -model can be interpreted against a JSON Schema, including media types like -[CBOR](#rfc7049). +model can be interpreted against a JSON Schema. ### Instance From 19ccdb648fce6ea49652359be1c1b785bd34d20b Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 13 Nov 2024 11:21:05 +1300 Subject: [PATCH 681/780] clarify that a meta-schema applies to the schema resource, not necessarily the whole document --- specs/jsonschema-core.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 350e45ba..db79974a 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -833,9 +833,11 @@ Meta-schemas are used to inform an implementation how to interpret a schema. Every schema has a meta-schema, which can be explicitly declared using the `$schema` keyword. -The meta-schema serves to describe valid schema syntax. A schema MUST +The meta-schema serves to describe valid schema syntax. A schema resource MUST successfully validate against its meta-schema, which constrains the syntax of -the available keywords. The syntax described for a given keyword is expected to +the available keywords. (See {{compound-validation}} for information on +validating schemas which contain embedded schema resources that declare a +different meta-schema.) The syntax described for a given keyword is expected to be compatible with the document which defines the keyword; while it is possible to describe an incompatible syntax, such a meta-schema would be unlikely to be useful. @@ -1339,7 +1341,7 @@ Since any schema that can be referenced can also be embedded, embedded schema resources MAY specify different processing dialects using the `$schema` values from their enclosing resource. -#### Validating +#### Validating {#compound-validation} Given that a Compound Schema Document may have embedded resources which identify as using different dialects, these documents SHOULD NOT be validated by applying From bcf0c1aa48448304b8ba73f9d6991fd9a8ab510a Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 13 Nov 2024 12:47:38 +1300 Subject: [PATCH 682/780] clarify that `type` must be a non-empty array --- specs/jsonschema-validation.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index c6d985ac..8579bdf1 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -108,7 +108,8 @@ an instance. These keywords are all assertions without any annotation behavior. #### `type` The value of this keyword MUST be either a string or an array. If it is an -array, elements of the array MUST be strings and MUST be unique. +array, it MUST be non-empty, and elements of the array MUST be strings and MUST +be unique. String values MUST be one of the six primitive types ("null", "boolean", "object", "array", "number", or "string"), or "integer" which matches any number From 8bb22f11db734eddca94890a745b280807d69edb Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Tue, 12 Nov 2024 15:53:37 -0800 Subject: [PATCH 683/780] Update deprecated github actions --- .github/workflows/ci.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 92557e7f..08e5a0b2 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -19,14 +19,14 @@ jobs: specs-ietf: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v3 - - uses: actions/setup-python@v4 + - uses: actions/checkout@v4 + - uses: actions/setup-python@v5 with: python-version: "3.10" - run: pip install --requirement requirements.txt - run: xml2rfc --version - run: make all - - uses: actions/upload-artifact@v3 + - uses: actions/upload-artifact@v4 with: name: specification-docs path: | From 81d64babc720d923bdbfff3210b8e3208de0a282 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 13 Nov 2024 13:38:15 +1300 Subject: [PATCH 684/780] Update adr/2024-11-2-assertion-format.md Co-authored-by: Jason Desrosiers --- adr/2024-11-2-assertion-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/2024-11-2-assertion-format.md b/adr/2024-11-2-assertion-format.md index 397d5018..f8dc08fa 100644 --- a/adr/2024-11-2-assertion-format.md +++ b/adr/2024-11-2-assertion-format.md @@ -23,7 +23,7 @@ In 2020-12, we further refined this by offering two separate vocabularies, one t However, the fact remains that our users consistently report (via questions in Slack, GitHub, and StackOverflow) that they expect format to validate. (The most recent case I can think of was only last week, in .Net's effort to build a short-term solution for schema generation from types.) -Due to this consistency in user expectations have decided to: +Due to this consistency in user expectations, we have decided to: 1. make format an assertion keyword and strictly, 2. enforce it by moving the appropriate tests into the required section of the Test Suite. From 16a751563d83d1edca59375f159f3472fcbf4153 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 13 Nov 2024 13:39:44 +1300 Subject: [PATCH 685/780] Update specs/jsonschema-validation.md Co-authored-by: Jason Desrosiers --- specs/jsonschema-validation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 7ddee49e..36fe5d8d 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -302,7 +302,7 @@ type, each distinct value will generally only validate a given set of instance types. If the type of the instance to validate is not in this set, validation for this keyword SHOULD succeed. All format values defined in this section apply to strings, but a format value can be specified to apply to any instance types -defined in the data model defined in the [core JSON Schema](#json-schema)[^1]. +defined in the data model defined in the [core JSON Schema](#json-schema) specification[^1]. [^1]: Note that the `type` keyword in this specification defines an "integer" type which is not part of the data model. Therefore a format attribute can be From 1b0e4bb38fb5ed86ec8df654059fe4da63a746f1 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 13 Nov 2024 13:41:40 +1300 Subject: [PATCH 686/780] Update specs/jsonschema-validation.md Co-authored-by: Jason Desrosiers --- specs/jsonschema-validation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 36fe5d8d..e76106a2 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -341,11 +341,11 @@ syntactic checking; implementations SHOULD NOT attempt to send an email, connect to a URL, or otherwise check the existence of an entity identified by a format instance. -#### Custom format attributes +#### Custom format values -Implementations MAY support custom format attributes. Save for agreement between +Implementations MAY support custom format values. Save for agreement between parties, schema authors SHALL NOT expect a peer implementation to support such -custom format attributes. +custom format values. ### Defined Formats From ff8f074d7f782a9a9e2fce0e6a8e707c4644c853 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 13 Nov 2024 14:45:55 +1300 Subject: [PATCH 687/780] update adr with results of vote --- adr/2024-11-2-assertion-format.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/adr/2024-11-2-assertion-format.md b/adr/2024-11-2-assertion-format.md index f8dc08fa..22a36010 100644 --- a/adr/2024-11-2-assertion-format.md +++ b/adr/2024-11-2-assertion-format.md @@ -2,10 +2,13 @@ * Status: proposed -* Deciders: @gregsdennis @jdesrosiers @jviotti @mwadams @karenetheridge @awwright @benjam @relequestual +* Deciders: @gregsdennis @jdesrosiers @julian @jviotti @mwadams @karenetheridge @relequestual * Date: 2024-11-02 * Technical Story: https://github.com/json-schema-org/json-schema-spec/issues/1520 * Voting issue: https://github.com/json-schema-org/TSC/issues/19 + For - @gregsdennis @jdesrosiers @jviotti @mwadams @karenetheridge + Neutral - @relequestual + Against - @julian ## Context and Problem Statement @@ -25,8 +28,8 @@ However, the fact remains that our users consistently report (via questions in S Due to this consistency in user expectations, we have decided to: -1. make format an assertion keyword and strictly, -2. enforce it by moving the appropriate tests into the required section of the Test Suite. +1. make format an assertion keyword, and +2. strictly enforce it by moving the appropriate tests into the required section of the Test Suite and building them more completely. ## Decision Drivers @@ -65,7 +68,8 @@ The TSC has decided via vote (see voting issue above) that we should change `for ### Negative Consequences -* This is a breaking change, which means that we will likely have to re-educate our users. +* This is a breaking change, which means that we will likely have to re-educate the users who correctly treat it as an annotation. +* Older schemas which do not specify a version (`$schema`) may change their validation outcome. * The burden on implementations will be greater since format validation was previously optional. ## Links From 8e33d21e95c05505fe1d1c77b6593fc43a32a226 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 14 Nov 2024 09:06:13 +1300 Subject: [PATCH 688/780] Update specs/jsonschema-validation.md Co-authored-by: Jason Desrosiers --- specs/jsonschema-validation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index e76106a2..be9f15b4 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -312,8 +312,8 @@ be explicitly defined to always pass if the number is not an integer, which produces essentially the same behavior as only applying to integers. Implementations SHOULD provide assertion behavior for the format values defined -by this document[^2] and MUST refuse to process any schema which contains an -unsupported format value. +by this document[^2] and MUST refuse to process any schema which contains a +format value it doesn't support. [^2]: Assertion behavior is called out very explicitly because it is a departure from previous iterations of this specification. Previously, `format` was an From 9ed207ff45dd15f6750037dd8eab64380530b0e7 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 22 Oct 2024 20:36:56 +1300 Subject: [PATCH 689/780] lint contributing --- CONTRIBUTING.md | 58 +++++++++++++++++++++++++++++++++++-------------- 1 file changed, 42 insertions(+), 16 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a196f61e..a2fa14aa 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,45 +2,71 @@ ## Contributing to JSON Schema Specification -Thanks for taking the time to contribute! 🎉👍 +Thanks for taking the time to contribute! 🎉👍 -JSON Schema is an evolving language. This repository contains the specification text as well as Pull Requests with suggested improvements and contributions. +JSON Schema is an evolving language. This repository contains the specification +text as well as Pull Requests with suggested improvements and contributions. -Contributions that do not change the interpretation of the spec but instead improve legibility, fix editorial errors, clear up ambiguity and improve examples are encouraged and are often merged by a spec editor with little process. +Contributions that do not change the interpretation of the spec but instead +improve legibility, fix editorial errors, clear up ambiguity and improve +examples are encouraged and are often merged by a spec editor with little +process. -However, contributions that _do_ meaningfully change the interpretation of the spec must follow the Specification Development Process which is ⚠️currently under discussion and development⚠️. +However, contributions that *do* meaningfully change the interpretation of the +spec must follow the [Specification Development Process](./PROCESS.md). ## Issues -Issues should identify a problem, enhancement, or use case; and propose some course of action for the draft. For alternate support channels, see the [SUPPORT.md](https://github.com/json-schema-org/.github/blob/main/SUPPORT.md). +Issues should identify a problem, enhancement, or use case; and propose some +course of action for the draft. For alternate support channels, see the +[SUPPORT.md](https://github.com/json-schema-org/.github/blob/main/SUPPORT.md). ## Pull Requests -We welcome pull requests, both for editorial suggestions and to resolve open issues. +We welcome pull requests, both for editorial suggestions and to resolve open +issues. -If the pull request would solve a particular issue, reference the issue in the pull request description. +If the pull request would solve a particular issue, reference the issue in the +pull request description. -Changes that would affect implementation behavior should typically be opened as an issue first. +Changes that would affect implementation behavior should typically be opened as +an issue first. -Generally, pull requests should be made to the `main` branch unless it is a patch update and we are in a patch phase. In that case there will be a branch named something like `2020-12-patch` that the PR should target instead. +Generally, pull requests should be made to the `main` branch unless it is a +patch update and we are in a patch phase. In that case there will be a branch +named something like `2020-12-patch` that the PR should target instead. -Most PRs, including all PRs that impact implementation behavior, will be left open for a minimum of 14 days. Minor wording fixes may be merged more quickly once approved by a project member. +Most PRs, including all PRs that impact implementation behavior, will be left +open for a minimum of 14 days. Minor wording fixes may be merged more quickly +once approved by a project member. ## Milestones -Each milestone is an estimation of the work that will be done for the next draft. Milestones are typically named after the meta-schema draft number, and the _open_ milestone with the lowest draft number is the current active project. +Each milestone is an estimation of the work that will be done for the next +draft. Milestones are typically named after the meta-schema draft number, and +the *open* milestone with the lowest draft number is the current active project. -Issues may be removed from a milestoned due to lack of consensus, lack of anyone with the correct expertise to make a PR, or simply because we wish to publish a draft and defer the remaining issues to the next draft. +Issues may be removed from a milestoned due to lack of consensus, lack of anyone +with the correct expertise to make a PR, or simply because we wish to publish a +draft and defer the remaining issues to the next draft. -Numbered milestones other than the lowest-numbered one are used to tentatively organize future work, but may be completely reorganized once work on that draft actually begins. +Numbered milestones other than the lowest-numbered one are used to tentatively +organize future work, but may be completely reorganized once work on that draft +actually begins. -The `draft-future` milestone is for issues for which there is an agreement that they should be addressed, but no specific timeline. +The `draft-future` milestone is for issues for which there is an agreement that +they should be addressed, but no specific timeline. ## Code of Conduct -All official channels including the mailing list, GitHub organization and Slack server, follow our [Code of Conduct](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md). +All official channels including the mailing list, GitHub organization and Slack +server, follow our +[Code of Conduct](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md). ## Have Questions? -You can join the `#specification` channel in our [Slack workspace](https://json-schema.org/slack) to interact with other community members involved in the Specification development, share new ideas and ask questions. +You can join the `#specification` channel in our +[Slack workspace](https://json-schema.org/slack) to interact with other +community members involved in the Specification development, share new ideas and +ask questions. From e1fc15b7ed678d565a2da6b82c8ded237a0d02d9 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 22 Oct 2024 20:45:52 +1300 Subject: [PATCH 690/780] lint process --- PROCESS.md | 159 +++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 112 insertions(+), 47 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index eed30e85..952793bb 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -2,7 +2,8 @@ ## Purpose -This document describes the development and publication process for the JSON Schema specifications contained within this repository. +This document describes the development and publication process for the JSON +Schema specifications contained within this repository. - [JSON Schema Core](./jsonschema-core.md) - [JSON Schema Validation](./jsonschema-validation.md) @@ -11,27 +12,41 @@ This document describes the development and publication process for the JSON Sch ### Defined Behavior -Some behaviors within JSON Schema may be explicitly or implicitly undefined by the specifications for various reasons. How to handle these behaviors is generally left to implementations. +Some behaviors within JSON Schema may be explicitly or implicitly undefined by +the specifications for various reasons. How to handle these behaviors is +generally left to implementations. -A defined behavior is one that is fully and unambiguously defined by the specifications. +A defined behavior is one that is fully and unambiguously defined by the +specifications. -An undefined behavior is said to have an "indeterminate" validation result since implementations may resolve the behavior in different ways. +An undefined behavior is said to have an "indeterminate" validation result since +implementations may resolve the behavior in different ways. ### Stability and Breaking Changes -Stability is defined using the level of compatibility between sequential releases. If all schemas which are written to one release produce the same defined behavior under the following release, then those releases are compatible, and the specification is said to be stable between them. +Stability is defined using the level of compatibility between sequential +releases. If all schemas which are written to one release produce the same +defined behavior under the following release, then those releases are +compatible, and the specification is said to be stable between them. -If an existing schema under the new release exhibits defined behavior that is contrary to defined behavior under the previous release, the new release is said to contain breaking changes and the specification is unstable between those releases. +If an existing schema under the new release exhibits defined behavior that is +contrary to defined behavior under the previous release, the new release is said +to contain breaking changes and the specification is unstable between those +releases. -If a new release fully defines a previously undefined (or under-defined) behavior, the new release is still considered compatible, even if it contradicts the decision of any particular implementation. +If a new release fully defines a previously undefined (or under-defined) +behavior, the new release is still considered compatible, even if it contradicts +the decision of any particular implementation. -For reference, this table shows the validation results of a hypothetical schema and instance across two consecutive releases to illustrate the compatibility of those releases: +For reference, this table shows the validation results of a hypothetical schema +and instance across two consecutive releases to illustrate the compatibility of +those releases: -| _Next_ ➡️
⬇️ _Current_ | pass | fail | indeterminate | -|:---:|:---:|:---:|:---:| -| **pass** | ✅ | ❌ | ❌ | -| **fail** | ❌ | ✅ | ❌ | -| **indeterminate** | ✅ | ✅ | ✅ | +| *Next* ➡️
⬇️ *Current* | pass | fail | indeterminate | +|:-----------------------:|:----:|:----:|:-------------:| +| **pass** | ✅ | ❌ | ❌ | +| **fail** | ❌ | ✅ | ❌ | +| **indeterminate** | ✅ | ✅ | ✅ | ### Release @@ -43,30 +58,40 @@ Consecutive releases which maintain compatibility with each other comprise a ver ## Release and Version -The JSON Schema specification will aim to publish annually on or about the First of January each year. Releases are identified by the year they are published. +The JSON Schema specification will aim to publish annually on or about the First +of January each year. Releases are identified by the year they are published. -When a new release contains breaking changes, that release begins a new version of JSON Schema. +When a new release contains breaking changes, that release begins a new version +of JSON Schema. -The version will be identified as an integer, starting with `1` and incrementing as needed. +The version will be identified as an integer, starting with `1` and incrementing +as needed. -Stability will be prioritized when making changes to the specification. Breaking changes are undesired and should be avoided when possible. +Stability will be prioritized when making changes to the specification. Breaking +changes are undesired and should be avoided when possible. ## Publication ### Specifications -The specifications will be published on the JSON Schema website, https://json-schema.org/, using a path comprised of the version, year, and document name. For example, +The specifications will be published on the JSON Schema website, +, using a path comprised of the version, year, and +document name. For example, ``` https://json-schema.org/1/2025/core.html https://json-schema.org/1/2025/validation.html ``` -Once a specification document has been published, neither the document (save for minor errata such as spelling mistakes) nor its publication URL may change. If the TSC elects to alter the above URL scheme, the new scheme only applies to future publications and are not retroactive. +Once a specification document has been published, neither the document (save for +minor errata such as spelling mistakes) nor its publication URL may change. If +the TSC elects to alter the above URL scheme, the new scheme only applies to +future publications and are not retroactive. ### Meta-schemas -A release meta-schema will be published under the same path using `schema.json` as the file name. +A release meta-schema will be published under the same path using `schema.json` +as the file name. ``` https://json-schema.org/1/2025/schema.json @@ -78,20 +103,25 @@ The website will also be configured to: ``` https://json-schema.org/1/2025/ ``` -- serve the meta-schema for the latest release in a version from its version folder +- serve the meta-schema for the latest release in a version from its version + folder ``` https://json-schema.org/1/ ``` -The latest-release meta-schemas will be updated with proposals as indicated by the [Proposal section](#proposal) of this document. +The latest-release meta-schemas will be updated with proposals as indicated by +the [Proposal section](#proposal) of this document. + +> [!IMPORTANT] +> These are only publication and availability URLs. The specification will +> define the `$id` values for the meta-schemas. -```diff -@@ These are only publication and availability URLs. The specification will define the `$id` values for the meta-schemas. @@ -``` ## Feature Life Cycle -New features will progress through a sequence of stages before being added to the specification, and existing stable features must be formally deprecated before being removed. The stages of the life cycle, in order, are: +New features will progress through a sequence of stages before being added to +the specification, and existing stable features must be formally deprecated +before being removed. The stages of the life cycle, in order, are: - Concept - Proposal @@ -117,34 +147,56 @@ stateDiagram-v2 ### Concept -The feature life cycle begins with an idea expressed in a GitHub issue in this repository. Initial discussion may occur in Slack or another space, but the life cycle does not formally begin until a GitHub issue is created. +The feature life cycle begins with an idea expressed in a GitHub issue in this +repository. Initial discussion may occur in Slack or another space, but the life +cycle does not formally begin until a GitHub issue is created. -The discussion should cover how the feature could work, use cases, syntax, alternatives, whether it’s a breaking change, etc., with a goal of deciding rough requirements. +The discussion should cover how the feature could work, use cases, syntax, +alternatives, whether it’s a breaking change, etc., with a goal of deciding +rough requirements. -During this stage, members of the Core Team will implement private prototypes of the ideas expressed in the issue to get a feel for how it integrates with the stable features. Questions to address may include: +During this stage, members of the Core Team will implement private prototypes of +the ideas expressed in the issue to get a feel for how it integrates with the +stable features. Questions to address may include: -- Does the idea operate within the confines of existing JSON Schema evaluation processes, or does it define something new? -- Is the idea merely a shortcut for some existing functionality (syntactic sugar), or does it solve a previously unsolvable problem? +- Does the idea operate within the confines of existing JSON Schema evaluation + processes, or does it define something new? +- Is the idea merely a shortcut for some existing functionality (syntactic + sugar), or does it solve a previously unsolvable problem? - What is the expected complexity for implementing the feature? -At least two (2) Core Team members must have implemented prototypes before the concept can continue to the formal proposal process. +At least two (2) Core Team members must have implemented prototypes before the +concept can continue to the formal proposal process. -### Proposal +### Proposal {#proposal} -Once a rough consensus for the idea has been reached, a formal proposal will be written, separate from the specification, with the goal of precisely defining specification changes. +Once a rough consensus for the idea has been reached, a formal proposal will be +written, separate from the specification, with the goal of precisely defining +specification changes. -The proposal will use the [Proposal Template](./proposals/proposal-template.md) and be stored in this repository's `proposals` folder. +The proposal will use the [Proposal Template](./proposals/proposal-template.md) +and be stored in this repository's `proposals` folder. -Additionally, a draft ADR will be included using the file name of the proposal document with an `-adr` suffix: `{proposal-file-name}-adr.md`. This ADR will include additional information from the "Concept" discussion. +Additionally, a draft ADR will be included using the file name of the proposal +document with an `-adr` suffix: `{proposal-file-name}-adr.md`. This ADR will +include additional information from the "Concept" discussion. Proposed keywords will be added to the appropriate vocabulary meta-schemas in: - latest published release and - the `main` branch of this repository. -The subschema for the proposed keyword will contain only a `$comment` keyword indicating that the feature is experimental and containing a link to the proposal document. Aside from the `$comment` keyword, the subschema will be empty. +The subschema for the proposed keyword will contain only a `$comment` keyword +indicating that the feature is experimental and containing a link to the +proposal document. Aside from the `$comment` keyword, the subschema will be +empty. -_This is done so that a proposed keyword is allowed but not validated as its syntax may change during the proposal/experimentation process. It also permits different implementations to support different variations of each proposal separately throughout this process. It will be up to the implementation to validate these keywords in accordance with their support._ +> [!NOTE] +> This is done so that a proposed keyword is allowed but not validated as its +> syntax may change during the proposal/experimentation process. It also permits +> different implementations to support different variations of each proposal +> separately throughout this process. It will be up to the implementation to +> validate these keywords in accordance with their support. Tests for the proposal are added to the JSON Schema Test Suite. @@ -152,13 +204,15 @@ Tests for the proposal are added to the JSON Schema Test Suite. @@ TODO: Identify a location within the test suite for proposals. @@ ``` -Once an initial draft of the proposal has been completed and published, the feature moves into Experimentation. +Once an initial draft of the proposal has been completed and published, the +feature moves into Experimentation. ### Experimentation Implementations may begin to support the new feature. -Feedback from implementers and users are expected to result in refinements to the proposal, which will then be updated in the implementations. +Feedback from implementers and users are expected to result in refinements to +the proposal, which will then be updated in the implementations. Breaking changes to a proposed feature MAY occur, but are highly discouraged. @@ -174,28 +228,39 @@ In order to proceed to the next stage ([Stable](#stable)): Experimental features are not considered to be interoperable across implementations. -If a proposal cannot advance to the next stage, it may be removed. The proposal document is moved to an `archive` subfolder, the keyword is removed from the meta-schemas, and any tests are moved to an `archive` subfolder. The removal of a feature which has not reached the stable state is not considered a breaking change. +If a proposal cannot advance to the next stage, it may be removed. The proposal +document is moved to an `archive` subfolder, the keyword is removed from the +meta-schemas, and any tests are moved to an `archive` subfolder. The removal of +a feature which has not reached the stable state is not considered a breaking +change. -### Stable +### Stable {#stable} -The feature is incorporated into the specification in the `main` branch as specified by the proposal document, and the feature will be required as of the next release. +The feature is incorporated into the specification in the `main` branch as +specified by the proposal document, and the feature will be required as of the +next release. The draft ADR is completed, dated, and moved to the `adr` folder. -The appropriate vocabulary meta-schema in the `main` branch is updated to include a subschema that validates the feature's syntax requirements. This will be made available with the next release. +The appropriate vocabulary meta-schema in the `main` branch is updated to +include a subschema that validates the feature's syntax requirements. This will +be made available with the next release. -Upon publication of the new release, the meta-schema for the lapsed release will have the keyword removed. +Upon publication of the new release, the meta-schema for the lapsed release will +have the keyword removed. The appropriate tests are incorporated into the main suite. ### Deprecated -If a feature is no longer useful, e.g. it has been replaced, it may be deprecated by indicating it as such in the specification. +If a feature is no longer useful, e.g. it has been replaced, it may be +deprecated by indicating it as such in the specification. Implementations must support deprecated features. ### Removed -A feature must have been published as deprecated for at least one release before it can be considered for removal. +A feature must have been published as deprecated for at least one release before +it can be considered for removal. Feature removal is considered a breaking change. From f78a2954cafbc6cd070325e68ab557fd7ac0323d Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 22 Oct 2024 21:01:06 +1300 Subject: [PATCH 691/780] lint readme --- README.md | 62 +++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 40 insertions(+), 22 deletions(-) diff --git a/README.md b/README.md index 8328f069..67e7f1bc 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,15 @@ # Welcome to JSON Schema -[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg)](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md) [![Project Status: Active – The project has reached a stable, usable state and is being actively developed.](https://www.repostatus.org/badges/latest/active.svg)](https://www.repostatus.org/#active) [![Financial Contributors on Open Collective](https://opencollective.com/json-schema/all/badge.svg?label=financial+contributors)](https://opencollective.com/json-schema) +[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg)](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md) +[![Project Status: Active – The project has reached a stable, usable state and is being actively developed.](https://www.repostatus.org/badges/latest/active.svg)](https://www.repostatus.org/#active) +[![Financial Contributors on Open Collective](https://opencollective.com/json-schema/all/badge.svg?label=financial+contributors)](https://opencollective.com/json-schema) -JSON Schema is a vocabulary that allows you to validate, annotate, and manipulate JSON documents. +JSON Schema is a vocabulary that allows you to validate, annotate, and +manipulate JSON documents. -This repository contains the sources for the **work in progress** of the next set of JSON Schema IETF Internet Draft (I-D) documents. -For the latest released I-Ds, please see the [Specification page](http://json-schema.org/specification.html) on the website. +This repository contains the sources for the **work in progress** of the next +set of JSON Schema IETF Internet Draft (I-D) documents. For the latest released +I-Ds, please see the +[Specification page](http://json-schema.org/specification.html) on the website. ## Call for contributions and feedback @@ -12,15 +17,20 @@ Reviews, comments and suggestions are most welcome! Please read our [guidelines for contributing](CONTRIBUTING.md). ## Status -For the current status of issues and pull requests, please see the following labels -[![Available](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20Available.svg?color=brightgreen)](https://github.com/json-schema-org/json-schema-spec/issues?q=is%3Aopen+is%3Aissue+label%3A%22Status%3A+Available%22) [![In Progress](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20In%20Progress.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Status:%20In%20Progress) [![Review Needed](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20Review%20Needed.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Status%3A%20Review%20Needed) +For the current status of issues and pull requests, please see the following labels +[![Available](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20Available.svg?color=brightgreen)](https://github.com/json-schema-org/json-schema-spec/issues?q=is%3Aopen+is%3Aissue+label%3A%22Status%3A+Available%22) +[![In Progress](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20In%20Progress.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Status:%20In%20Progress) +[![Review Needed](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20Review%20Needed.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Status%3A%20Review%20Needed) [![Critical](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Critical.svg?color=critical -)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Critical) [![High](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20High.svg?color=important)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20High) [![Medium](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Medium.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Medium) [![Low](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Low.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Low) +)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Critical) +[![High](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20High.svg?color=important)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20High) +[![Medium](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Medium.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Medium) +[![Low](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Priority:%20Low.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Priority%3A%20Low) - -Labels are assigned based on [Sensible Github Labels](https://github.com/Relequestual/sensible-github-labels). +Labels are assigned based on +[Sensible Github Labels](https://github.com/Relequestual/sensible-github-labels). ## Authoring and Building @@ -38,6 +48,7 @@ a [VSCode extension](https://github.com/remarkjs/vscode-remark) we can use to get linting an link checking while developing the spec. #### Plugins + The following is a not-necessarily-complete list of configured plugins and the features they make available to you. @@ -51,7 +62,7 @@ features they make available to you. - [remark-heading-id](https://github.com/imcuttle/remark-heading-id) -- Adds support for `{#my-anchor}` syntax to add an `id` to an element so it can be referenced using URI fragment syntax. -- [remark-headings](/json-schema-org/json-schema-spec/blob/main/remark-headings.js) +- [remark-headings](/json-schema-org/json-schema-spec/blob/main/build/remark-headings.js) -- A collection of enhancements for headings. - Adds hierarchical section numbers to headings. - Use the `%appendix%` prefix on headings that should be numbered as an @@ -60,7 +71,7 @@ features they make available to you. - Example: `#section-2-13` - Example: `#appendix-a` - Makes the heading a link utilizing its anchor -- [remark-reference-links](/json-schema-org/json-schema-spec/blob/main/remark-reference-link.js) +- [remark-reference-links](/json-schema-org/json-schema-spec/blob/main/build/remark-reference-links.js) -- Adds new syntax for referencing a section of the spec using the section number as the link text. - Example: @@ -68,13 +79,14 @@ features they make available to you. ## Foo {#foo} ## Bar + This is covered in {{foo}} // --> Renders to "This is covered in [Section 2.3](#foo)" - Link text will use "Section" or "Appendix" as needed ``` -- [remark-table-of-contents](/json-schema-org/json-schema-spec/blob/main/remark-table-of-contents.js) +- [remark-table-of-contents](/json-schema-org/json-schema-spec/blob/main/build/remark-table-of-contents.js) -- Adds a table of contents in a section with a header called "Table of Contents". -- [remark-code-titles](/json-schema-org/json-schema-spec/blob/main/remark-code-titles.js) +- [remark-code-titles](/json-schema-org/json-schema-spec/blob/main/build/remark-code-titles.js) -- Add titles to code blocks - Example: ```markdown @@ -87,7 +99,7 @@ features they make available to you. escaped characters. So, to get `My "quoted" title`, you would need to be `"My \\\\"quoted\\\\" title"`. - [remark-torchlight](https://github.com/torchlight-api/remark-torchlight) -- - Syntax highlighting and more using https://torchlight.dev. Features include + Syntax highlighting and more using . Features include line numbers and line highlighting. - [remark-flexible-containers](https://github.com/ipikuka/remark-flexible-containers) -- Add a callout box using the following syntax. Supported container types are @@ -100,6 +112,7 @@ features they make available to you. ``` ### Internet-Drafts + To build components that are being maintained as IETF Internet-Drafts, run `make`. The Makefile will create the necessary Python venv for you as part of the regular make target. @@ -115,10 +128,10 @@ The version of "xml2rfc" that this project uses is updated by modifying Descriptions of the xml2rfc, I-D documents, and RFC processes: -* https://xml2rfc.tools.ietf.org/authoring/draft-mrose-writing-rfcs.html -* https://www.ietf.org/tao.html -* https://www.ietf.org/ietf-ftp/1id-guidelines.html -* https://www.rfc-editor.org/rfc/rfc7322.txt +- +- +- +- ## Test suites @@ -127,7 +140,7 @@ Conformance tests for JSON Schema and its vocabularies may be found ## The website -The JSON Schema web site is at http://json-schema.org/ +The JSON Schema web site is at The source for the website is [maintained in a separate repository](https://github.com/json-schema-org/website). @@ -135,12 +148,16 @@ The source for the website is [maintained in a separate repository](https://gith ### Code Contributors -This project exists thanks to all the people who contribute. [[Contribute](CONTRIBUTING.md)]. - +This project exists thanks to all the people who contribute. +[[Contribute](CONTRIBUTING.md)]. ### Financial Contributors Become a financial contributor and help us sustain our community. [[Contribute](https://opencollective.com/json-schema/contribute)] + #### Sponsors Here are our top sponsors. You could be next! [[Become a sponsor](https://opencollective.com/json-schema#sponsor)] @@ -162,4 +179,5 @@ Here are our top sponsors. You could be next! [[Become a sponsor](https://openco ## License -The contents of this repository are [licensed under](./LICENSE) either the BSD 3-clause license *or* the Academic Free License v3.0. +The contents of this repository are [licensed under](./LICENSE) either the BSD +3-clause license *or* the Academic Free License v3.0. From 9f29cff4af888c308f251a2938c83c34fe204c36 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 7 Nov 2024 14:54:51 -0800 Subject: [PATCH 692/780] Add linting config for Github markdown files --- .remarkrc.js | 10 ++++++++++ package.json | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) create mode 100644 .remarkrc.js diff --git a/.remarkrc.js b/.remarkrc.js new file mode 100644 index 00000000..95040a50 --- /dev/null +++ b/.remarkrc.js @@ -0,0 +1,10 @@ +import remarkGfm from "remark-gfm"; +import lintPreset from "./.remarkrc-lint.js"; + + +export default { + plugins: [ + remarkGfm, + lintPreset + ] +}; diff --git a/package.json b/package.json index 59d407d3..34b5f129 100644 --- a/package.json +++ b/package.json @@ -5,7 +5,7 @@ "type": "module", "main": "index.js", "scripts": { - "lint": "eslint . ; remark --no-stdout --frail specs/", + "lint": "eslint . ; remark --no-stdout --frail .", "build": "remark --rc-path specs/.remarkrc-build.js --output web/" }, "license": "MIT", From 668be4b15f43c3d52dabfe0fc8e9b7b513521909 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Sun, 10 Nov 2024 18:56:21 -0800 Subject: [PATCH 693/780] Additional lint cleanup --- .github/PULL_REQUEST_TEMPLATE.md | 6 +- .github/SECURITY.md | 23 +++- .remarkrc-lint.js | 4 +- PROCESS.md | 51 ++++--- README.md | 37 +++-- ...iguity-and-fix-later-gh-spec-issue-1172.md | 126 +++++++++++------- adr/2022-09-decouple-from-ietf.md | 38 +++--- adr/2022-11-stable-spec.md | 41 ++++-- adr/2023-04-sva-prefix.md | 82 +++++++----- adr/2024-02-object-contains.md | 85 +++++++----- adr/2024-05-08-extract-unstable-keywords.md | 53 +++++--- adr/README.md | 32 ++--- adr/template.md | 73 +++++----- 13 files changed, 375 insertions(+), 276 deletions(-) diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 48ecff5b..eecb49d8 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -15,9 +15,9 @@ Thanks for submitting a pull request! Please provide enough information so that ### Issue & Discussion References -- Closes #___ -- Related to #___ -- Others? +- Closes #___ +- Related to #___ +- Others? ### Summary diff --git a/.github/SECURITY.md b/.github/SECURITY.md index 87b438e3..8b847267 100644 --- a/.github/SECURITY.md +++ b/.github/SECURITY.md @@ -1,11 +1,24 @@ # Reporting Security Issues -The JSON Schema project does not house any implementation of JSON Schema itself. If you have found a security issue in any implementation of JSON Schema, please contact the appropriate maintainers, per the projects security reporting guidelines, if any. +The JSON Schema project does not house any implementation of JSON Schema itself. +If you have found a security issue in any implementation of JSON Schema, please +contact the appropriate maintainers, per the projects security reporting +guidelines, if any. -To report a security issue, please use the GitHub Security Advisory "https://github.com/json-schema-org/json-schema-spec/security/advisories/new" tab. +To report a security issue, please use the GitHub Security Advisory +"" +tab. -If you find a security issue in relation to the JSON Schema specification or another repository within this GitHub organization, please use the above. +If you find a security issue in relation to the JSON Schema specification or +another repository within this GitHub organization, please use the above. -The JSON Schema project TSC will review and respond to all security reports. Please follow [coordinated disclosure](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/about-coordinated-disclosure-of-security-vulnerabilities). +The JSON Schema project TSC will review and respond to all security reports. +Please follow [coordinated disclosure](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/about-coordinated-disclosure-of-security-vulnerabilities). + +If you are a maintainer of an implementation, please consider [adding a security +policy](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository). +If you need assistance in understanding a report, or remediation of a confirmed +issue, please feel free to reach out to us on our Slack server, in the +`#implementations` channel, and ask for a temporary private channel to discuss +your situation or concerns. -If you are a maintainer of an implementation, please consider [adding a security policy](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository). If you need assistance in understanding a report, or remediation of a confirmed issue, please feel free to reach out to us on our Slack server, in the `#implementations` channel, and ask for a temporary private channel to discuss your situation or concerns. \ No newline at end of file diff --git a/.remarkrc-lint.js b/.remarkrc-lint.js index f628bc82..1e60073f 100644 --- a/.remarkrc-lint.js +++ b/.remarkrc-lint.js @@ -5,6 +5,7 @@ import remarkPresetLintMarkdownStyleGuide from "remark-preset-lint-markdown-styl import remarkLintListItemIndent from "remark-lint-list-item-indent"; import remarkLintListItemSpacing from "remark-lint-list-item-spacing"; import remarkLintNoFileNameMixedCase from "remark-lint-no-file-name-mixed-case"; +import remarkLintNoFileNameIrregularCharacters from "remark-lint-no-file-name-irregular-characters"; export default { @@ -15,6 +16,7 @@ export default { remarkPresetLintMarkdownStyleGuide, [remarkLintListItemIndent, "one"], [remarkLintListItemSpacing, { checkBlanks: true }], - [remarkLintNoFileNameMixedCase, false] + [remarkLintNoFileNameMixedCase, false], + [remarkLintNoFileNameIrregularCharacters, false] ] }; diff --git a/PROCESS.md b/PROCESS.md index 952793bb..b0a06cb0 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -1,3 +1,4 @@ + # JSON Schema Specification Development and Publication Process ## Purpose @@ -5,8 +6,8 @@ This document describes the development and publication process for the JSON Schema specifications contained within this repository. -- [JSON Schema Core](./jsonschema-core.md) -- [JSON Schema Validation](./jsonschema-validation.md) +- [JSON Schema Core](./specs/jsonschema-core.md) +- [JSON Schema Validation](./specs/jsonschema-validation.md) ## Definitions @@ -43,18 +44,20 @@ and instance across two consecutive releases to illustrate the compatibility of those releases: | *Next* ➡️
⬇️ *Current* | pass | fail | indeterminate | -|:-----------------------:|:----:|:----:|:-------------:| +| :-----------------------: | :--: | :--: | :-----------: | | **pass** | ✅ | ❌ | ❌ | | **fail** | ❌ | ✅ | ❌ | | **indeterminate** | ✅ | ✅ | ✅ | ### Release -A release is any single publication of the JSON Schema specifications (as a group). +A release is any single publication of the JSON Schema specifications (as a +group). ### Version -Consecutive releases which maintain compatibility with each other comprise a version. +Consecutive releases which maintain compatibility with each other comprise a +version. ## Release and Version @@ -78,10 +81,8 @@ The specifications will be published on the JSON Schema website, , using a path comprised of the version, year, and document name. For example, -``` -https://json-schema.org/1/2025/core.html -https://json-schema.org/1/2025/validation.html -``` +- `https://json-schema.org/1/2025/core.html` +- `https://json-schema.org/1/2025/validation.html` Once a specification document has been published, neither the document (save for minor errata such as spelling mistakes) nor its publication URL may change. If @@ -93,30 +94,22 @@ future publications and are not retroactive. A release meta-schema will be published under the same path using `schema.json` as the file name. -``` -https://json-schema.org/1/2025/schema.json -``` +- `https://json-schema.org/1/2025/schema.json` The website will also be configured to: -- serve the meta-schema from its release folder - ``` - https://json-schema.org/1/2025/ - ``` +- serve the meta-schema from its release folder: + `https://json-schema.org/1/2025/` - serve the meta-schema for the latest release in a version from its version - folder - ``` - https://json-schema.org/1/ - ``` + folder: `https://json-schema.org/1/` The latest-release meta-schemas will be updated with proposals as indicated by the [Proposal section](#proposal) of this document. -> [!IMPORTANT] +> \[!IMPORTANT] > These are only publication and availability URLs. The specification will > define the `$id` values for the meta-schemas. - ## Feature Life Cycle New features will progress through a sequence of stages before being added to @@ -168,14 +161,15 @@ stable features. Questions to address may include: At least two (2) Core Team members must have implemented prototypes before the concept can continue to the formal proposal process. -### Proposal {#proposal} +### Proposal Once a rough consensus for the idea has been reached, a formal proposal will be written, separate from the specification, with the goal of precisely defining specification changes. -The proposal will use the [Proposal Template](./proposals/proposal-template.md) -and be stored in this repository's `proposals` folder. +The proposal will use the [Proposal +Template](./specs/proposals/proposal-template.md) and be stored in this +repository's `proposals` folder. Additionally, a draft ADR will be included using the file name of the proposal document with an `-adr` suffix: `{proposal-file-name}-adr.md`. This ADR will @@ -191,7 +185,7 @@ indicating that the feature is experimental and containing a link to the proposal document. Aside from the `$comment` keyword, the subschema will be empty. -> [!NOTE] +> \[!NOTE] > This is done so that a proposed keyword is allowed but not validated as its > syntax may change during the proposal/experimentation process. It also permits > different implementations to support different variations of each proposal @@ -226,7 +220,8 @@ In order to proceed to the next stage ([Stable](#stable)): @@ TODO: Determine usage metrics. @@ ``` -Experimental features are not considered to be interoperable across implementations. +Experimental features are not considered to be interoperable across +implementations. If a proposal cannot advance to the next stage, it may be removed. The proposal document is moved to an `archive` subfolder, the keyword is removed from the @@ -234,7 +229,7 @@ meta-schemas, and any tests are moved to an `archive` subfolder. The removal of a feature which has not reached the stable state is not considered a breaking change. -### Stable {#stable} +### Stable The feature is incorporated into the specification in the `main` branch as specified by the proposal document, and the feature will be required as of the diff --git a/README.md b/README.md index 67e7f1bc..981d9445 100644 --- a/README.md +++ b/README.md @@ -18,7 +18,8 @@ Please read our [guidelines for contributing](CONTRIBUTING.md). ## Status -For the current status of issues and pull requests, please see the following labels +For the current status of issues and pull requests, please see the following +labels [![Available](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20Available.svg?color=brightgreen)](https://github.com/json-schema-org/json-schema-spec/issues?q=is%3Aopen+is%3Aissue+label%3A%22Status%3A+Available%22) [![In Progress](https://img.shields.io/github/issues/json-schema-org/json-schema-spec/Status:%20In%20Progress.svg)](https://github.com/json-schema-org/json-schema-spec/labels/Status:%20In%20Progress) @@ -62,7 +63,7 @@ features they make available to you. - [remark-heading-id](https://github.com/imcuttle/remark-heading-id) -- Adds support for `{#my-anchor}` syntax to add an `id` to an element so it can be referenced using URI fragment syntax. -- [remark-headings](/json-schema-org/json-schema-spec/blob/main/build/remark-headings.js) +- [remark-headings](/json-schema-org/json-schema-spec/blob/main/remark/remark-headings.js) -- A collection of enhancements for headings. - Adds hierarchical section numbers to headings. - Use the `%appendix%` prefix on headings that should be numbered as an @@ -71,22 +72,20 @@ features they make available to you. - Example: `#section-2-13` - Example: `#appendix-a` - Makes the heading a link utilizing its anchor -- [remark-reference-links](/json-schema-org/json-schema-spec/blob/main/build/remark-reference-links.js) +- [remark-reference-links](/json-schema-org/json-schema-spec/blob/main/remark/remark-reference-links.js) -- Adds new syntax for referencing a section of the spec using the section number as the link text. - - Example: + - Example: ```markdown ## Foo {#foo} - ## Bar - This is covered in {{foo}} // --> Renders to "This is covered in [Section 2.3](#foo)" - Link text will use "Section" or "Appendix" as needed ``` -- [remark-table-of-contents](/json-schema-org/json-schema-spec/blob/main/build/remark-table-of-contents.js) +- [remark-table-of-contents](/json-schema-org/json-schema-spec/blob/main/remark/remark-table-of-contents.js) -- Adds a table of contents in a section with a header called "Table of Contents". -- [remark-code-titles](/json-schema-org/json-schema-spec/blob/main/build/remark-code-titles.js) +- [remark-code-titles](/json-schema-org/json-schema-spec/blob/main/remark/remark-code-titles.js) -- Add titles to code blocks - Example: ```markdown @@ -104,12 +103,11 @@ features they make available to you. - [remark-flexible-containers](https://github.com/ipikuka/remark-flexible-containers) -- Add a callout box using the following syntax. Supported container types are `warning`, `note`, and `experimental`. - - ``` - ::: {type} {title} - {content} - ::: - ``` + ```markdown + ::: {type} {title} + {content} + ::: + ``` ### Internet-Drafts @@ -148,19 +146,16 @@ The source for the website is [maintained in a separate repository](https://gith ### Code Contributors -This project exists thanks to all the people who contribute. -[[Contribute](CONTRIBUTING.md)]. +This project exists thanks to all the people who contribute. \[[Contribute](CONTRIBUTING.md)]. + ### Financial Contributors -Become a financial contributor and help us sustain our community. [[Contribute](https://opencollective.com/json-schema/contribute)] +Become a financial contributor and help us sustain our community. \[[Contribute](https://opencollective.com/json-schema/contribute)] #### Sponsors -Here are our top sponsors. You could be next! [[Become a sponsor](https://opencollective.com/json-schema#sponsor)] +Here are our top sponsors. You could be next! \[[Become a sponsor](https://opencollective.com/json-schema#sponsor)] diff --git a/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md index 5e83dd95..548b5b86 100644 --- a/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md +++ b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md @@ -1,91 +1,115 @@ + # Acknowledge ambiguity in additionalProperties behaviour and fix after patch release -* Status: accepted -* Deciders: @relequestual @gregsdennis, @jdesrosiers, @karenetheridge -* Date: 2022-05-19 +- Status: accepted +- Deciders: @relequestual @gregsdennis, @jdesrosiers, @karenetheridge +- Date: 2022-05-19 Related... -Issue: https://github.com/json-schema-org/json-schema-spec/issues/1172 +Issue: -Discussion: https://github.com/json-schema-org/community/discussions/57 +Discussion: -Pull Request: https://github.com/json-schema-org/json-schema-spec/pull/1203 +Pull Request: ## Context and Problem Statement -When we changed the specification to use annotations as the context in which some keywords behave, we included a clause that allowed implementations which didn't use annotations to optimize the processing of `additionalProperties` in another way which produces the same effect as the prior behaviour. -This section created an ambiguity in terms of the resulting output format, but not validation. +When we changed the specification to use annotations as the context in which +some keywords behave, we included a clause that allowed implementations which +didn't use annotations to optimize the processing of `additionalProperties` in +another way which produces the same effect as the prior behaviour. This section +created an ambiguity in terms of the resulting output format, but not +validation. -We needed to decide on how to proceed for the patch release of the 2020-12 version of the specification. +We needed to decide on how to proceed for the patch release of the 2020-12 +version of the specification. -The two above links are to a GitHub Discussion and a GitHub Issue detailing the problems. -Details with an example of the problem can be seen in the Discussion's opening post specifically. +The two above links are to a GitHub Discussion and a GitHub Issue detailing the +problems. Details with an example of the problem can be seen in the Discussion's +opening post specifically. ## Decision Drivers -* The "patch release" should not change anything functionally -* Annotations as they are, are confusing to users, implementers, and specification editors alike -* Patch release is behind schedule -* There are currently no tests for the output format -* It's hard to see any immediate consensus on changing the annotation based behaviour +- The "patch release" should not change anything functionally +- Annotations as they are, are confusing to users, implementers, and + specification editors alike +- Patch release is behind schedule +- There are currently no tests for the output format +- It's hard to see any immediate consensus on changing the annotation based + behaviour ## Considered Options -* [Leaving it "as is" and do nothing](https://github.com/json-schema-org/community/discussions/57#discussioncomment-1413777) -* [Pick one](https://github.com/json-schema-org/community/discussions/57#discussioncomment-1416683) of the behaviours -* [Revert back to draft-07 behaviour](https://github.com/json-schema-org/community/discussions/57#discussioncomment-1453723) -* [Reinterpret how we understand annotation collection](https://github.com/json-schema-org/json-schema-spec/issues/1172#issuecomment-1049686478) to allow reading annotations within the same schema object regardless of assertion results -* [Acknowledge and accept that two approaches and results are allowable](https://github.com/json-schema-org/community/issues/161#issue-1173742930) -* Redefine annotation collection behaviour and/or how `additionalProperties` works +- [Leaving it "as is" and do nothing](https://github.com/json-schema-org/community/discussions/57#discussioncomment-1413777) +- [Pick one](https://github.com/json-schema-org/community/discussions/57#discussioncomment-1416683) + of the behaviours +- [Revert back to draft-07 behaviour](https://github.com/json-schema-org/community/discussions/57#discussioncomment-1453723) +- [Reinterpret how we understand annotation collection](https://github.com/json-schema-org/json-schema-spec/issues/1172#issuecomment-1049686478) + to allow reading annotations within the same schema object regardless of + assertion results +- [Acknowledge and accept that two approaches and results are allowable](https://github.com/json-schema-org/community/issues/161#issue-1173742930) +- Redefine annotation collection behaviour and/or how `additionalProperties` + works ## Decision Outcome -Chosen option: "Acknowledge and accept that two approaches and results are allowable", because +Chosen option: "Acknowledge and accept that two approaches and results are +allowable", because -* Leaving it "as is" will continue to cause confusion -* The change is non-functional which is required for the patch release -* The patch release is behind schedule -* Finding consensus of other solutions proved to be difficult -* There's no test suite for the output format, so it's not easy to see unintended consequences of a functional change -* We need to properly re-evaluate annotation collection and how annotations are used by other keywords +- Leaving it "as is" will continue to cause confusion +- The change is non-functional which is required for the patch release +- The patch release is behind schedule +- Finding consensus of other solutions proved to be difficult +- There's no test suite for the output format, so it's not easy to see + unintended consequences of a functional change +- We need to properly re-evaluate annotation collection and how annotations are + used by other keywords ### Positive Consequences -* Patch release can move forward -* Validation result is not impacted -* Confusion is at least seen and acknowledged -* Implementations which pick either approach are seen to be compliant +- Patch release can move forward +- Validation result is not impacted +- Confusion is at least seen and acknowledged +- Implementations which pick either approach are seen to be compliant ### Negative Consequences -* May have an impact for downstream tools which process full output data -* A test suite (not yet developed) which covers this situation needs to allow for multiple valid answers +- May have an impact for downstream tools which process full output data +- A test suite (not yet developed) which covers this situation needs to allow + for multiple valid answers ## Pros and Cons of the Options ### Leaving it "as is" and do nothing -Agree to do nothing and hope for the best. There isn't any downstream tooling yet anyway. +Agree to do nothing and hope for the best. There isn't any downstream tooling +yet anyway. -* Good, because no functional change -* Good, because no impact on downstream tooling -* Bad, because leaves a known ambiguity in the specification +- Good, because no functional change +- Good, because no impact on downstream tooling +- Bad, because leaves a known ambiguity in the specification + ### Pick one / Revert to draft-07 behaviour / Reinterpret annotation collection -* Good, because ambiguity is removed -* Good, because not many tools will be effected -* Bad, because it can be seen as a functional change (not really allowed for the patch release) -* Bad, because it can break existing implementations and downstream tools -* Bad, because without a test suite it's hard to see unexpected consequences +- Good, because ambiguity is removed +- Good, because not many tools will be effected +- Bad, because it can be seen as a functional change (not really allowed for the + patch release) +- Bad, because it can break existing implementations and downstream tools +- Bad, because without a test suite it's hard to see unexpected consequences ## Links -* Issue: [Ambiguous behaviour of additionalProperties when invalid](https://github.com/json-schema-org/json-schema-spec/issues/1172) -* Discussion: [The meaning of "additionalProperties" has changed](https://github.com/json-schema-org/community/discussions/57) -* Resolving Pull Request: [Add CREF about ambiguous behaviour of additionalProperties](https://github.com/json-schema-org/json-schema-spec/pull/1203) -* Alternative solution proposal: [Resolve contradictions in the described behaviour of "additionalProperties" and "items"](https://github.com/json-schema-org/json-schema-spec/pull/1154) - -* [Result of discussing](https://github.com/json-schema-org/json-schema-spec/issues/1172#issuecomment-1063962900) on an Open Community Working Meeting call - @jdesrosiers proposed a less controversial and more agreeable solution to add a comment that both are allowable -* [Related GitHub Discussion](https://github.com/json-schema-org/community/discussions/67) on alternative behaviour for `unevaluated*` keywords +- Issue: [Ambiguous behaviour of additionalProperties when invalid](https://github.com/json-schema-org/json-schema-spec/issues/1172) +- Discussion: [The meaning of "additionalProperties" has changed](https://github.com/json-schema-org/community/discussions/57) +- Resolving Pull Request: [Add CREF about ambiguous behaviour of additionalProperties](https://github.com/json-schema-org/json-schema-spec/pull/1203) +- Alternative solution proposal: [Resolve contradictions in the described + behaviour of "additionalProperties" and "items"](https://github.com/json-schema-org/json-schema-spec/pull/1154) +- [Result of discussing](https://github.com/json-schema-org/json-schema-spec/issues/1172#issuecomment-1063962900) + on an Open Community Working Meeting call - @jdesrosiers proposed a less + controversial and more agreeable solution to add a comment that both are + allowable +- [Related GitHub Discussion](https://github.com/json-schema-org/community/discussions/67) + on alternative behaviour for `unevaluated*` keywords diff --git a/adr/2022-09-decouple-from-ietf.md b/adr/2022-09-decouple-from-ietf.md index f7a190fa..6ec72ff2 100644 --- a/adr/2022-09-decouple-from-ietf.md +++ b/adr/2022-09-decouple-from-ietf.md @@ -1,15 +1,15 @@ # Decoupling from IETF -* Status: accepted -* Deciders: @jdesrosiers @relequestual @awwright @handrews @gregsdennis -* Date: 2022-09-27 +- Status: accepted +- Deciders: @jdesrosiers @relequestual @awwright @handrews @gregsdennis +- Date: 2022-09-27 Related Issues: -* https://github.com/orgs/json-schema-org/discussions/69 - This issue is about +- - This issue is about dropping the "draft" prefix from our releases. This ADR doesn't cover that, but much of the discussion about whether or not to decouple from IETF is in that discussion. -* This topic has been discussed in many other places as well that are difficult +- This topic has been discussed in many other places as well that are difficult to link to here including Slack, Twitter, OCWMs, and conference discussions. ## Context and Problem Statement @@ -26,29 +26,29 @@ that our "drafts" are intended for use in production. ## Decision Drivers -* IETF's draft versioning system doesn't work for JSON Schema and we stopped +- IETF's draft versioning system doesn't work for JSON Schema and we stopped using it to version our releases a while ago. We now use date based versioning and even have more than one draft submission per release (the initial release and the patch release). -* The IETF process is optimized for working on a draft until it's done and then +- The IETF process is optimized for working on a draft until it's done and then disbanding. In some cases, the RFC may be revisited and revised in the future, but this is rare and generally contains little more than clarifications and reference updates. JSON Schema is not like that. JSON Schema is more like a programming language. When it stops evolving, it will lose its relevance. When we finish a release of JSON Schema, we don't disband, we start work on the next release. -* Since the project resumed activity after the gap following draft-04, every one +- Since the project resumed activity after the gap following draft-04, every one of our releases is expected to be used in production and will be depended on for many years forward. This is not consistent with normal IETF drafts. Even if we don't publicly use the term "draft", we're still using the IETF I-D system in a way that's not intended. -* Under IETF, JSON Schema fits under the category of "draft". The community has +- Under IETF, JSON Schema fits under the category of "draft". The community has repeatedly told us that they perceive this to meant that JSON Schema "incomplete" and not "not ready for production use". This is the wrong message for us to be sending as all of our releases are intended to be used in production. This ADR doesn't decide whether or not to drop the "draft" from our releases, but decoupling from IETF gives us that option. -* Several members of the JSON Schema team have interacted with JSON-related IETF +- Several members of the JSON Schema team have interacted with JSON-related IETF working groups. Some of these interactions demonstrated an indifference or hostility to JSON Schema, and a preference for projects taking a different approach. Equally important was a lack of any active interest or constructive @@ -66,12 +66,12 @@ that our "drafts" are intended for use in production. 1. Continue to submit I-Ds, while using our customized process with no intention of pursing standards track RFC status. -2. Go all-in with IETF and pursue a standards track RFC with the IETF. The +1. Go all-in with IETF and pursue a standards track RFC with the IETF. The approach would be to describe the essential characteristics of evaluating a JSON Schema: the keywords that everybody is guaranteed to support, and any extension mechanisms. -3. Join W3C and pursue a standards track with them using their process. -4. Decouple completely from any standards organization and come up with our own +1. Join W3C and pursue a standards track with them using their process. +1. Decouple completely from any standards organization and come up with our own specification development lifecycle (SDLC) model inspired by well established projects with an SDLC that more closely meets or needs. @@ -140,20 +140,20 @@ to be an exception to the rule, and not frequently used. ### Positive Consequences -* Decoupling from IETF allows us to distance ourselves from the assumptions that +- Decoupling from IETF allows us to distance ourselves from the assumptions that people make about JSON Schema because they assume it works like a typical I-D. -* Decoupling from IETF allows us to customize our SDLC model to what works best +- Decoupling from IETF allows us to customize our SDLC model to what works best for JSON Schema. ### Negative Consequences -* If we don't go the standardization route with IETF or W3C, we lose access to +- If we don't go the standardization route with IETF or W3C, we lose access to their expert review process. -* Not being associated with a recognized standards organization such as IETF, +- Not being associated with a recognized standards organization such as IETF, W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. However, we have received feedback that our membership with OpenJS/Linux Foundation provides the credibility that we need. -* One of the benefits of an RFC is other standards can normatively reference it, +- One of the benefits of an RFC is other standards can normatively reference it, and use JSON Schema to define their JSON-based syntaxes. However, we have received feedback from people involved in standards development that told us that they were comfortable referencing OpenAPI's self published specification @@ -162,7 +162,7 @@ to be an exception to the rule, and not frequently used. member of the OpenJS Foundation, which is a sub-group of the Linux Foundation, so we expect standards developers to be just as comfortable referencing JSON Schema as they are referencing OpenAPI. -* Defining our own SLDC process will be a lot of work and none of us have +- Defining our own SLDC process will be a lot of work and none of us have expertise in defining such a process. However, we can take inspiration from existing well established projects and we would have the freedom to update our process as we learn what works and what doesn't. diff --git a/adr/2022-11-stable-spec.md b/adr/2022-11-stable-spec.md index b51595cf..0fa8b47a 100644 --- a/adr/2022-11-stable-spec.md +++ b/adr/2022-11-stable-spec.md @@ -1,31 +1,35 @@ # Selecting a new specification development process -* Status: accepted -* Deciders: @jdesrosiers @relequestual @awwright @handrews @gregsdennis -* Date: 2022-11-02 +- Status: accepted +- Deciders: @jdesrosiers @relequestual @awwright @handrews @gregsdennis +- Date: 2022-11-02 ## Context and Problem Statement + We've chosen to decouple our process from IETF, so we need to choose a new specification development process to replace it. ## Decision Drivers -* Dropping the "draft" label is an important driver of this change. It's mostly + +- Dropping the "draft" label is an important driver of this change. It's mostly an artifact of the IETF process and has proven to be confusing for the community. -* The community wants a stable version of JSON Schema. -* There is a need for JSON Schema to continue to evolve to meet evolving +- The community wants a stable version of JSON Schema. +- There is a need for JSON Schema to continue to evolve to meet evolving needs. -* There is a demand for custom keywords/vocabularies/dialects and we want to +- There is a demand for custom keywords/vocabularies/dialects and we want to continue to support those use cases. -* There is a need to ease the burden of implementations supporting multiple +- There is a need to ease the burden of implementations supporting multiple versions of JSON Schema. ## Considered Options + There have been two proposals put forward. Both address the goal of a stable specification with the ability to evolve. The third option represents sticking with the status quo. ### Option 1 - TC-39 Inspired + The spec would be converted from I-D XML to Markdown, but can otherwise be structured however we choose. A system would be put in place to allow us to flag the stability level of any feature in the spec. There would be only one version @@ -43,6 +47,7 @@ unstable features to "stable" status. Releases would happen once a year and be designated by the year they were released. ### Option 2 - IETF Inspired + The spec would be reorganized into two parts: "Core Semantics" and "Standard Extensions". Changes to either spec are subject to strict backward and forward compatibility requirements and would be released as a new spec that replaces and @@ -65,6 +70,7 @@ ubiquitous that they should be considered essential for implementations to support. ### Option 3 - Minimal Change + Option 3 represents the minimal amount of change to our process from what we have been doing. The spec would need to be converted from I-D XML to a Markdown version that would be served on the website, but otherwise we would continue to @@ -73,6 +79,7 @@ patch releases mid-cycle. Each release is a distinct version of JSON Schema and has no compatibility guarantees between versions. ## Decision Outcome + The decision is to go with Option 1 while leaving discussion open for aspects of Option 2 that could be adopted within the constraints of Option 1. @@ -90,6 +97,7 @@ the spec and restructuring is allowed at any time as long as it doesn't break compatibility requirements. ## Pros and Cons of the Options + The biggest benefit is shared between Option 1 and Option 2. Both approaches result in a stable spec. This will have benefits for both implementers and users. Because of the compatibility requirements, whenever you write a schema, @@ -99,7 +107,9 @@ separate code with different semantics in different versions. They just need to code for the current release and they will automatically have support for past releases (not including "draft" releases). + ### Option 1 - TC-39 Inspired + The two things that make this option stand out are the stability model governing spec evolution and the mutability of the spec document. @@ -138,7 +148,9 @@ take two years for a feature to reach stability which could be a long time to wait for users who need to stick to the stable feature set but could benefit greatly from a new feature. + ### Option 2 - IETF Inspired + The benefit of this approach is that it's compatible with the IETF process without imposing some of the constraints and perception issues that we had with our previous process. We can pursue an RFC in the future if we choose to without @@ -159,6 +171,7 @@ compatibility requirements, so we have to go extra slow to make sure we get it right. ### Option 3 - Minimal Changes + The benefit of this solution is that we don't have the overhead of defining and/or learning a new process. In the short term, we can put more effort into improving JSON Schema if we don't have the distraction of defining a whole new @@ -167,15 +180,15 @@ with the "draft" label and doesn't provide the stability the community is looking for. ## Links -* https://github.com/jdesrosiers/json-schema-spec/blob/main/adr/2022-09-decouple-from-ietf.md - - The ADR for the decision to decouple from IETF -* https://github.com/orgs/json-schema-org/discussions/234 - Proposal submitted +- + \- The ADR for the decision to decouple from IETF +- - Proposal submitted by @jdesrosiers for a process to replace the IETF based process we'd been using. -* https://github.com/orgs/json-schema-org/discussions/257 - @awwright's vision +- - @awwright's vision for JSON Schema including how it can continue to evolve while still having a stable core. -* https://github.com/json-schema-org/community/discussions/119 - When we first +- - When we first started talking about forward compatibility and a stable spec. - * https://json-schema.org/blog/posts/future-of-json-schema - User friendly + - - User friendly comments on decoupling from the IETF. diff --git a/adr/2023-04-sva-prefix.md b/adr/2023-04-sva-prefix.md index c398bc7a..97bdca83 100644 --- a/adr/2023-04-sva-prefix.md +++ b/adr/2023-04-sva-prefix.md @@ -1,31 +1,36 @@ # Supporting Single-Value Annotations via a Defined Prefix -* Status: accepted -* Deciders: @relequestual, @gregsdennis, @jdesrosiers, @karenetheridge, @awwright, @julian -* Date: 2023-04-04 +- Status: accepted +- Deciders: @relequestual, @gregsdennis, @jdesrosiers, @karenetheridge, + @awwright, @julian +- Date: 2023-04-04 Related: - Discussions: - - Disallow Unknown Keywords - https://github.com/orgs/json-schema-org/discussions/241 - - Support SVAs - https://github.com/orgs/json-schema-org/discussions/329 + - Disallow Unknown Keywords - + - Support SVAs - - PRs: - - https://github.com/json-schema-org/json-schema-spec/pull/1387 (proposal) + - (proposal) ## Context and Problem Statement -Dropping support for unknown keywords was a necessary step toward providing stability guarantees. However, the community's reaction to this news was not encouraging. How can we still support keywords that are merely collected as annotations and provide no functionality (single-value annotations, or SVAs)? +Dropping support for unknown keywords was a necessary step toward providing +stability guarantees. However, the community's reaction to this news was not +encouraging. How can we still support keywords that are merely collected as +annotations and provide no functionality (single-value annotations, or SVAs)? ## Decision Drivers -* Future-proofing - We want to ensure that we can still add keywords to the spec without breaking existing schemas. -* Implementation supportability - Is the proposal feasible to implement? -* Community preference +- Future-proofing - We want to ensure that we can still add keywords to the spec + without breaking existing schemas. +- Implementation supportability - Is the proposal feasible to implement? +- Community preference ## Considered Options 1. A defined prefix or other convention for SVAs - 1. Optionally defined by a new `$sigil` keyword + 1. Optionally defined by a new `$sigil` keyword 1. Inlined vocabularies that can define SVAs 1. A new core keyword that lists SVAs, e.g. `$ignored` 1. A defined configuration option to allow/forbid unknown keywords @@ -35,19 +40,23 @@ Dropping support for unknown keywords was a necessary step toward providing stab Chosen option: A defined prefix or other convention. -This option was chosen because it solves the problem in a clean way that can be easily implemented. It was also the favorite solution among the team members as well as the community. +This option was chosen because it solves the problem in a clean way that can be +easily implemented. It was also the favorite solution among the team members as +well as the community. Specifically, the prefix `x-` has been selected. ### Positive Consequences -* It solves the problem by allowing users to include custom data in their schemas. -* Many developers will be familiar with using `x-` for custom data. -* It's a simple way to differentiate SVAs from other keywords. +- It solves the problem by allowing users to include custom data in their + schemas. +- Many developers will be familiar with using `x-` for custom data. +- It's a simple way to differentiate SVAs from other keywords. ### Negative Consequences -* Some people preferred a different prefix as `x-` in some other contexts denotes "experimental" behavior. +- Some people preferred a different prefix as `x-` in some other contexts + denotes "experimental" behavior. ## Pros and Cons of the Options @@ -55,17 +64,22 @@ Specifically, the prefix `x-` has been selected. [Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-4988859) -* Good, because it's simple and easy to understand. -* Good, because `x-` specifically is familiar to many developers as an identifying prefix for custom data. -* Good, because it's easily supportable by the meta-schema (i.e. `patternProperties`) -* Bad, because `x-` in some other contexts can denote "experimental" behavior, which is not our meaning. +- Good, because it's simple and easy to understand. +- Good, because `x-` specifically is familiar to many developers as an + identifying prefix for custom data. +- Good, because it's easily supportable by the meta-schema (i.e. + `patternProperties`) +- Bad, because `x-` in some other contexts can denote "experimental" behavior, + which is not our meaning. #### Option 1a - Optionally defined by a new `$sigil` keyword [Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-5357549) -* Good, because it can give users flexibility for the prefix that they want to use. -* Bad, because it cannot be supported by the meta-schema without other changes, which may be difficult to define and/or implement. +- Good, because it can give users flexibility for the prefix that they want to + use. +- Bad, because it cannot be supported by the meta-schema without other changes, + which may be difficult to define and/or implement. High level of effort @@ -73,29 +87,35 @@ High level of effort [Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-4988882) -* Good, because it defines the SVAs in a vocabulary which means they are regarded as "known." -* Bad, because we don't have any support for inlined vocabularies at the moment and would have to build that. +- Good, because it defines the SVAs in a vocabulary which means they are + regarded as "known." +- Bad, because we don't have any support for inlined vocabularies at the moment + and would have to build that. ### Option 3 - A new core keyword that lists SVAs, e.g. `$ignored` [Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-4988904) -* Good, because it provides a way to define SVAs. -* Bad, because it cannot be supported by the meta-schema without other changes, which may be difficult to define and/or implement. +- Good, because it provides a way to define SVAs. +- Bad, because it cannot be supported by the meta-schema without other changes, + which may be difficult to define and/or implement. High level of effort + ### Option 4 - A defined configuration option to allow/forbid unknown keywords [Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-4999789) -* Good, because it returns previous functionality (i.e. allowing unknown keywords) to the user. -* Bad, because that previous functionality removes/circumvents stability guarantees. +- Good, because it returns previous functionality (i.e. allowing unknown + keywords) to the user. +- Bad, because that previous functionality removes/circumvents stability + guarantees. ### Option 5 - A new core keyword designed for "extra" data [Discussion](https://github.com/orgs/json-schema-org/discussions/329#discussioncomment-5374873) -* Good, because it provides a place for users to add extra data. -* Bad, because it's an extra depth level that users need to create. -* Bad, because it can only generate a single annotation instead of multiple. +- Good, because it provides a place for users to add extra data. +- Bad, because it's an extra depth level that users need to create. +- Bad, because it can only generate a single annotation instead of multiple. diff --git a/adr/2024-02-object-contains.md b/adr/2024-02-object-contains.md index f7ba55a3..ab6d5e16 100644 --- a/adr/2024-02-object-contains.md +++ b/adr/2024-02-object-contains.md @@ -1,54 +1,68 @@ # `contains` and JSON Objects -* Status: Proposed, accepted, reconsidered, and ultimately reverted. -* Deciders: @gregsdennis, @jdesrosiers, @handrews, @awwright, @karenetheridge, @relequestual (with input from a couple non-core members) -* Date: 2023-11-14 (documented 2024-02-09) +- Status: Proposed, accepted, reconsidered, and ultimately reverted. +- Deciders: @gregsdennis, @jdesrosiers, @handrews, @awwright, @karenetheridge, + @relequestual (with input from a couple non-core members) +- Date: 2023-11-14 (documented 2024-02-09) Technical Story: -- Original proposal [#1077](https://github.com/json-schema-org/json-schema-spec/issues/1077) and [PR](https://github.com/json-schema-org/json-schema-spec/pull/1092) -- Reversion discussion [#1358](https://github.com/json-schema-org/json-schema-spec/issues/1358) and [PR](https://github.com/json-schema-org/json-schema-spec/pull/1452) +- Original proposal + [#1077](https://github.com/json-schema-org/json-schema-spec/issues/1077) and + [PR](https://github.com/json-schema-org/json-schema-spec/pull/1092) +- Reversion discussion + [#1358](https://github.com/json-schema-org/json-schema-spec/issues/1358) and + [PR](https://github.com/json-schema-org/json-schema-spec/pull/1452) ## Context and Problem Statement -[2021-02] -The original proposal was for `contains` to apply to objects as well as arrays since there was no functionality to do so. -The discussion covered the options of modifying `contains` or introducing a new `objectContains` (or similar) keyword set (also needs separate min/max). -The decision was voted on and modifying `contains` won. +\[2021-02] +The original proposal was for `contains` to apply to objects as well as arrays +since there was no functionality to do so. The discussion covered the options of +modifying `contains` or introducing a new `objectContains` (or similar) keyword +set (also needs separate min/max). The decision was voted on and modifying +`contains` won. -[2021-06] +\[2021-06] A change was applied. -[2022-12] -With the team shifting focus to stability between spec releases, the question was raised again with the argument that allowing `contains` to apply to objects is a breaking change. -It was conceded that the better approach would be to retain `contains` only for arrays and introduce a new keyword set to apply to objects. +\[2022-12] +With the team shifting focus to stability between spec releases, the question +was raised again with the argument that allowing `contains` to apply to objects +is a breaking change. It was conceded that the better approach would be to +retain `contains` only for arrays and introduce a new keyword set to apply to +objects. -[2023-11] +\[2023-11] The change was applied (reverted to previous behavior). ## Decision Drivers -* The original decision to allow `contains` to apply to objects was driven by the fact that no such functionality existed. -* The decision to revert was driven by a desire to not break current usages of `contains`. +- The original decision to allow `contains` to apply to objects was driven by + the fact that no such functionality existed. +- The decision to revert was driven by a desire to not break current usages of + `contains`. ## Considered Options -* `contains` could be modified to apply to objects. -* a new keyword set (e.g. `objectContains` along with associated min/max) could be added. +- `contains` could be modified to apply to objects. +- a new keyword set (e.g. `objectContains` along with associated min/max) could + be added. ## Decision Outcome -Ultimately, `contains` will continue to apply to only arrays. -New keywords will need to be introduced to apply to objects. -(Such a proposal has not yet been made.) +Ultimately, `contains` will continue to apply to only arrays. New keywords will +need to be introduced to apply to objects. (Such a proposal has not yet been +made.) ### Positive Consequences -* Schemas which currently use `contains` without a `type: array` specifier will not suddenly start applying to objects also. +- Schemas which currently use `contains` without a `type: array` specifier will + not suddenly start applying to objects also. ### Negative Consequences -* The functionality of `contains` as applied to objects is still unsupported. +- The functionality of `contains` as applied to objects is still unsupported. ## Pros and Cons of the Options @@ -56,7 +70,8 @@ New keywords will need to be introduced to apply to objects. (Example provided recently by a user in [Slack](https://json-schema.slack.com/archives/C5CF75URH/p1707258032879409)) -The requirement is that an object may contain any number of properties, but one and only one of them must contain an object with a `title` property. +The requirement is that an object may contain any number of properties, but one +and only one of them must contain an object with a `title` property. ✔️ valid ```json @@ -82,8 +97,9 @@ The requirement is that an object may contain any number of properties, but one } ``` -Currently, this is impossible since there is no way to conditionally count property values. -However, with `contains` applying to objects, the following is possible: +Currently, this is impossible since there is no way to conditionally count +property values. However, with `contains` applying to objects, the following is +possible: ```json { @@ -97,13 +113,14 @@ However, with `contains` applying to objects, the following is possible: } ``` -* Good, because it provides functionality that previously did not exist -* Bad, because is can potentially break some schemas -* … +- Good, because it provides functionality that previously did not exist +- Bad, because is can potentially break some schemas +- ... ### New keywords -Same examples as [changing `contains`](#change-contains), except we use new keywords instead. +Same examples as [changing `contains`](#change-contains), except we use new +keywords instead. The schema would be something like this instead: @@ -119,7 +136,7 @@ The schema would be something like this instead: } ``` -* Good, because it provides functionality that previously did not exist -* Good, because it doesn't break anyone -* Bad, because we have to introduce three new keywords -* … +- Good, because it provides functionality that previously did not exist +- Good, because it doesn't break anyone +- Bad, because we have to introduce three new keywords +- ... diff --git a/adr/2024-05-08-extract-unstable-keywords.md b/adr/2024-05-08-extract-unstable-keywords.md index 74faf4db..f4bc53bc 100644 --- a/adr/2024-05-08-extract-unstable-keywords.md +++ b/adr/2024-05-08-extract-unstable-keywords.md @@ -1,56 +1,69 @@ # Extract Unstable Features for Initial Release -* Status: accepted -* Deciders: @gregsdennis @jdesrosiers @bhutton -* Date: 2024-05-08 +- Status: accepted +- Deciders: @gregsdennis @jdesrosiers @bhutton +- Date: 2024-05-08 Technical Story: -@gregsdennis [proposed](https://github.com/json-schema-org/json-schema-spec/issues/1443#issuecomment-2099427543) that an ADR be created to document that unstable features be extracted before the stable release. +@gregsdennis [proposed](https://github.com/json-schema-org/json-schema-spec/issues/1443#issuecomment-2099427543) +that an ADR be created to document that unstable features be extracted before +the stable release. -Also the [SDLC proposal](https://github.com/orgs/json-schema-org/discussions/671) which lists features that need to be put into the proposal process. +Also the [SDLC proposal](https://github.com/orgs/json-schema-org/discussions/671) +which lists features that need to be put into the proposal process. ## Context and Problem Statement -In creating a stable spec release, it's important that all included features are well-developed and their behaviors are finalized. As such, the following features will be extracted before the stable release. +In creating a stable spec release, it's important that all included features are +well-developed and their behaviors are finalized. As such, the following +features will be extracted before the stable release. - `$vocabulary` - This feature is still in development. -- Output formats - This feature is being extracted to its own spec anyway. (See [PR](https://github.com/json-schema-org/json-schema-spec/pull/1429) for more info and link to discussion.) -- `propertyDependencies` - This feature is not technically in the spec and should go through the proposal process. +- Output formats - This feature is being extracted to its own spec anyway. (See + [PR](https://github.com/json-schema-org/json-schema-spec/pull/1429) for more + info and link to discussion.) +- `propertyDependencies` - This feature is not technically in the spec and + should go through the proposal process. ## Decision Drivers -We can't publish a stable spec that contains unstable features. Thus we need to remove them. +We can't publish a stable spec that contains unstable features. Thus we need to +remove them. ## Considered Options 1. Extract unfinished features and put them through the proposal process. -2. Complete the features before releasing the spec. +1. Complete the features before releasing the spec. ## Decision Outcome -Chosen option: Extract unfinished features and put them through the proposal process. +Chosen option: Extract unfinished features and put them through the proposal +process. -This allows us to release a stable version of the specification while continuing to develop these features. +This allows us to release a stable version of the specification while continuing +to develop these features. ### Positive Consequences -* We can release a spec earlier that fulfills our users' needs. -* We can continue to develop these features. +- We can release a spec earlier that fulfills our users' needs. +- We can continue to develop these features. ### Negative Consequences -* These feature will be considered experimental until their proposals are accepted. This may be a hindrance to adoption. +- These feature will be considered experimental until their proposals are +accepted. This may be a hindrance to adoption. ## Pros and Cons of the Options + ### Extract unfinished features and put them through the proposal process -* Good, because we can release a spec earlier that fulfills our users' needs. -* Good, because we can continue to develop these features. -* Bad, because these features are experimental now. +- Good, because we can release a spec earlier that fulfills our users' needs. +- Good, because we can continue to develop these features. +- Bad, because these features are experimental now. ### Complete the features before releasing the spec -* Good, because the features will be ready to use when the spec releases. -* Bad, because the spec may not release if we can't finalize the features. +- Good, because the features will be ready to use when the spec releases. +- Bad, because the spec may not release if we can't finalize the features. diff --git a/adr/README.md b/adr/README.md index 331cd6bf..223275a3 100644 --- a/adr/README.md +++ b/adr/README.md @@ -1,15 +1,17 @@ -# Architectural Decision Log - -This log lists the architectural decisions for the JSON Schema specification. - - - -* [ADR-2022-04-08](2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md) - Acknowledge ambiguity in additionalProperties behaviour and fix after patch release - - - -You can find the ADR for using ADRs in our [community repo ADR log](https://github.com/json-schema-org/community/tree/HEAD/docs/adr). - -For new ADRs, please use [template.md](template.md) as basis. -More information on MADR is available at . -General information about architectural decision records is available at . +# Architectural Decision Log + +This log lists the architectural decisions for the JSON Schema specification. + + + +- [ADR-2022-04-08](2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md) + \- Acknowledge ambiguity in additionalProperties behaviour and fix after patch + release + + + +You can find the ADR for using ADRs in our [community repo ADR log](https://github.com/json-schema-org/community/tree/HEAD/docs/adr). + +For new ADRs, please use [template.md](template.md) as basis. More information +on MADR is available at . General information about +architectural decision records is available at . diff --git a/adr/template.md b/adr/template.md index baf6c9d0..6da4169a 100644 --- a/adr/template.md +++ b/adr/template.md @@ -1,65 +1,70 @@ -# [short title of solved problem and solution] +# \[short title of solved problem and solution] -* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] -* Deciders: [list everyone involved in the decision] -* Date: [YYYY-MM-DD when the decision was last updated] +- Status: \[proposed | rejected | accepted | deprecated | ... | superseded by + \[ADR-0005](0005-example.md)] +- Deciders: \[list everyone involved in the decision] +- Date: \[YYYY-MM-DD when the decision was last updated] -Technical Story: [description | ticket/issue URL] +Technical Story: \[description | ticket/issue URL] ## Context and Problem Statement -[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.] +\[Describe the context and problem statement, e.g., in free form using two to +three sentences. You may want to articulate the problem in form of a question.] ## Decision Drivers -* [driver 1, e.g., a force, facing concern, …] -* [driver 2, e.g., a force, facing concern, …] -* … +- \[driver 1, e.g., a force, facing concern, ...] +- \[driver 2, e.g., a force, facing concern, ...] +- … ## Considered Options -### [option 1] +### \[option 1] -[example | description | pointer to more information | …] +\[example | description | pointer to more information | ...] -* Good, because [argument a] -* Good, because [argument b] -* Bad, because [argument c] -* … +- Good, because \[argument a] +- Good, because \[argument b] +- Bad, because \[argument c] +- … -### [option 2] +### \[option 2] -[example | description | pointer to more information | …] +\[example | description | pointer to more information | ...] -* Good, because [argument a] -* Good, because [argument b] -* Bad, because [argument c] -* … +- Good, because \[argument a] +- Good, because \[argument b] +- Bad, because \[argument c] +- … -### [option 3] +### \[option 3] -[example | description | pointer to more information | …] +\[example | description | pointer to more information | ...] -* Good, because [argument a] -* Good, because [argument b] -* Bad, because [argument c] -* … +- Good, because \[argument a] +- Good, because \[argument b] +- Bad, because \[argument c] +- … ## Decision Outcome -"[option 1]" was chosen because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)]. +"\[option 1]" was chosen because \[justification. e.g., only option, which meets +k.o. criterion decision driver | which resolves force force | ... | comes out +best (see below)]. ### Positive Consequences -* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …] -* … +- \[e.g., improvement of quality attribute satisfaction, follow-up decisions + required, ...] +- ... ### Negative Consequences -* [e.g., compromising quality attribute, follow-up decisions required, …] -* … +- \[e.g., compromising quality attribute, follow-up decisions required, ...] +- ... ## Links -* [Link type] [Link to ADR] -* … +- \[Link type] \[Link to ADR] +- ... From 13941dc75b3bb636681f9caf18f618df05c0549f Mon Sep 17 00:00:00 2001 From: Richard Gibson Date: Thu, 14 Nov 2024 08:18:46 -0500 Subject: [PATCH 694/780] use more accurate regex vocabulary --- specs/jsonschema-core.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 350e45ba..9f238db5 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -374,9 +374,9 @@ tokens: - complemented simple character classes (`[^abc]`); - complemented range character classes (`[^a-z]`); - simple quantifiers: `+` (one or more), `*` (zero or more), `?` (zero or one), - and their lazy versions (`+?`, `*?`, `??`); + and their non-greedy versions (`+?`, `*?`, `??`); - range quantifiers: `{x}` (exactly x occurrences), `{x,y}` (at least x, at most - y, occurrences), {x,} (x occurrences or more), and their lazy versions; + y, occurrences), {x,} (x occurrences or more), and their non-greedy versions; - the beginning-of-input (`^`) and end-of-input (`$`) anchors; - simple grouping (using `(` and `)`) and alternation (`|`). From c53747f8ddc4df590d35bf81fbd0f7781e5aa577 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 9 Nov 2024 11:43:34 +1300 Subject: [PATCH 695/780] clean up $dyanmic* --- specs/jsonschema-core.md | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 350e45ba..10031a27 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -1012,21 +1012,19 @@ resolution until runtime, at which point it is resolved each time it is encountered while evaluating an instance. Together with `$dynamicAnchor`, `$dynamicRef` implements a cooperative extension -mechanism that is primarily useful with recursive schemas (schemas that -reference themselves). The extension point is defined with `$dynamicAnchor` and -only exhibits runtime dynamic behavior when referenced with `$dynamicRef`. +mechanism that is primarily useful to extend recursive schemas. The extension +point is defined with `$dynamicAnchor` and only exhibits runtime dynamic +behavior when referenced with `$dynamicRef`. -The value of the `$dynamicRef` property MUST be a string which is a -IRI reference that contains a valid [plain name fragment](#anchors). Resolved -against the current IRI base, it indicates the schema resource used as the -starting point for runtime resolution. This initial resolution is safe to -perform on schema load. +The value of the `$dynamicRef` property MUST be a valid +[plain name fragment](#anchors). -The schema to apply is the outermost schema resource in the [dynamic -scope](#scopes) that defines a `$dynamicAnchor` that matches the plain name -fragment in the initially resolved IRI. +Resolution of `$dynamicRef` begins by identifying the the outermost schema +resource in the [dynamic scope](#scopes) which defines a matching +`$dynamicAnchor`. The schema to apply is the subschema of this resource which +contains the matching `$dynamicAnchor`. -For a full example using these keyword, see {{recursive-example}}.[^6] +For a full example using these keywords, see {{recursive-example}}.[^6] [^6]: The difference between the hyper-schema meta-schema in pre-2019 drafts and an this draft dramatically demonstrates the utility of these keywords. From b0ece6ea3b964eb343c7075feb7369afeac98205 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 10 Nov 2024 19:00:26 +1300 Subject: [PATCH 696/780] clarfication around $dynamicAnchor and its separation from $ref semantics --- specs/jsonschema-core.md | 34 +++++++++++++++++++--------------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 10031a27..cc664405 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -946,17 +946,18 @@ The `$anchor` and `$dynamicAnchor` keywords are used to specify such fragments. They are identifier keywords that can only be used to create plain name fragments, rather than absolute IRIs as seen with `$id`. -The base IRI to which the resulting fragment is appended is the canonical IRI of -the schema resource containing the `$anchor` or `$dynamicAnchor` in question. -As discussed in the previous section, this is either the nearest `$id` in the -same or parent schema object, or the base IRI for the document as determined -according to [RFC 3987](#rfc3987) and [RFC 3986](#rfc3986). - -Separately from the usual usage of IRIs, `$dynamicAnchor` indicates that the -fragment is an extension point when used with the `$dynamicRef` keyword. This -low-level, advanced feature makes it easier to extend recursive schemas such as -the meta-schemas, without imposing any particular semantics on that extension. -See the section on [`$dynamicRef`](#dynamic-ref) for details. +`$anchor` defines a reference target for `$ref`. The fragment defined by this +keyword is appended is the IRI of the schema resource containing it. As +discussed in {{id-keyword}}, this is either the nearest `$id` in the same or an +ancestor schema object, or the base IRI for the document as determined according +to [RFC 3987](#rfc3987) and [RFC 3986](#rfc3986). + +In contrast, `$dynamicAnchor` operates independently of resource IRIs and is +instead dependent on the dynamic scope of the evaluation. `$dynamicAnchor` +defines a reference target for the `$dynamicRef` keyword. This advanced feature +makes it easier to extend recursive schemas such as the meta-schemas, without +imposing any particular semantics on that extension. See {{dynamic-ref}} for +details. In most cases, the normal fragment behavior both suffices and is more intuitive. Therefore it is RECOMMENDED that `$anchor` be used to create plain name @@ -1012,12 +1013,15 @@ resolution until runtime, at which point it is resolved each time it is encountered while evaluating an instance. Together with `$dynamicAnchor`, `$dynamicRef` implements a cooperative extension -mechanism that is primarily useful to extend recursive schemas. The extension -point is defined with `$dynamicAnchor` and only exhibits runtime dynamic -behavior when referenced with `$dynamicRef`. +mechanism that is primarily useful to extend recursive schemas, where +`$dynamicRef` defines the extension point, and `$dynamicAnchor` defines the +target. The value of the `$dynamicRef` property MUST be a valid -[plain name fragment](#anchors). +[plain name fragment](#anchors).[^3] + +[^3]: `$dynamicAnchor` defines the anchor with plain text, e.g. `foo`; the +`$dynamicRef` that references it uses a URI fragment syntax, e.g. `#foo`. Resolution of `$dynamicRef` begins by identifying the the outermost schema resource in the [dynamic scope](#scopes) which defines a matching From dcb6ee443b32154591776fe3bde405291aaa1149 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 12 Nov 2024 06:25:36 +1300 Subject: [PATCH 697/780] Update specs/jsonschema-core.md Co-authored-by: Juan Cruz Viotti --- specs/jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index cc664405..1865c1c2 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -947,7 +947,7 @@ They are identifier keywords that can only be used to create plain name fragments, rather than absolute IRIs as seen with `$id`. `$anchor` defines a reference target for `$ref`. The fragment defined by this -keyword is appended is the IRI of the schema resource containing it. As +keyword is appended to the IRI of the schema resource containing it. As discussed in {{id-keyword}}, this is either the nearest `$id` in the same or an ancestor schema object, or the base IRI for the document as determined according to [RFC 3987](#rfc3987) and [RFC 3986](#rfc3986). From 0ab9b7ad70d079f4971ee114f8a5744b5c4e39a4 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 12 Nov 2024 06:26:01 +1300 Subject: [PATCH 698/780] Update specs/jsonschema-core.md Co-authored-by: Juan Cruz Viotti --- specs/jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 1865c1c2..9d5a7f55 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -1023,7 +1023,7 @@ The value of the `$dynamicRef` property MUST be a valid [^3]: `$dynamicAnchor` defines the anchor with plain text, e.g. `foo`; the `$dynamicRef` that references it uses a URI fragment syntax, e.g. `#foo`. -Resolution of `$dynamicRef` begins by identifying the the outermost schema +Resolution of `$dynamicRef` begins by identifying the outermost schema resource in the [dynamic scope](#scopes) which defines a matching `$dynamicAnchor`. The schema to apply is the subschema of this resource which contains the matching `$dynamicAnchor`. From 5899a3efc1d232a3c34d7069b4d52a7235f2419b Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 27 Nov 2024 19:10:13 +1300 Subject: [PATCH 699/780] Update specs/jsonschema-core.md Co-authored-by: Jason Desrosiers --- specs/jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 9d5a7f55..7b405e58 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -1018,7 +1018,7 @@ mechanism that is primarily useful to extend recursive schemas, where target. The value of the `$dynamicRef` property MUST be a valid -[plain name fragment](#anchors).[^3] +[plain name fragment](#fragments).[^3] [^3]: `$dynamicAnchor` defines the anchor with plain text, e.g. `foo`; the `$dynamicRef` that references it uses a URI fragment syntax, e.g. `#foo`. From a75cbcebdf0f23a78c50145fb3965c89e1561df4 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 27 Nov 2024 19:59:45 +1300 Subject: [PATCH 700/780] Update specs/jsonschema-core.md Co-authored-by: Jason Desrosiers --- specs/jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 7b405e58..85cfa13d 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -1014,7 +1014,7 @@ encountered while evaluating an instance. Together with `$dynamicAnchor`, `$dynamicRef` implements a cooperative extension mechanism that is primarily useful to extend recursive schemas, where -`$dynamicRef` defines the extension point, and `$dynamicAnchor` defines the +`$dynamicRef` defines the extension point and `$dynamicAnchor` defines the target. The value of the `$dynamicRef` property MUST be a valid From 8dbcd119d8bfb3b6d3a18a8fc530f1fe1087d82a Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 27 Nov 2024 20:01:05 +1300 Subject: [PATCH 701/780] update note about hyper-schema as an example --- specs/jsonschema-core.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 85cfa13d..f67bf4be 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -1030,8 +1030,8 @@ contains the matching `$dynamicAnchor`. For a full example using these keywords, see {{recursive-example}}.[^6] -[^6]: The difference between the hyper-schema meta-schema in pre-2019 drafts and -an this draft dramatically demonstrates the utility of these keywords. +[^6]: The differences in the hyper-schema meta-schemas from draft-07 and draft +2019-09 dramatically demonstrates the utility of these keywords. #### Schema Re-Use With `$defs` {#defs} From 5cddc41f0bbae4e298090ca90c4c81b55c85e645 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 27 Nov 2024 20:08:15 +1300 Subject: [PATCH 702/780] update format adr --- adr/2024-11-2-assertion-format.md | 105 ++++++++++++++++++------------ 1 file changed, 63 insertions(+), 42 deletions(-) diff --git a/adr/2024-11-2-assertion-format.md b/adr/2024-11-2-assertion-format.md index 22a36010..a73f2f67 100644 --- a/adr/2024-11-2-assertion-format.md +++ b/adr/2024-11-2-assertion-format.md @@ -1,78 +1,99 @@ # [short title of solved problem and solution] -* Status: proposed +- Status: proposed -* Deciders: @gregsdennis @jdesrosiers @julian @jviotti @mwadams @karenetheridge @relequestual -* Date: 2024-11-02 -* Technical Story: https://github.com/json-schema-org/json-schema-spec/issues/1520 -* Voting issue: https://github.com/json-schema-org/TSC/issues/19 - For - @gregsdennis @jdesrosiers @jviotti @mwadams @karenetheridge - Neutral - @relequestual - Against - @julian +- Deciders: @gregsdennis @jdesrosiers @julian @jviotti @mwadams @karenetheridge + @relequestual +- Date: 2024-11-02 +- Technical Story: https://github.com/json-schema-org/json-schema-spec/issues/1520 +- Voting issue: https://github.com/json-schema-org/TSC/issues/19 + - For - @gregsdennis @jdesrosiers @jviotti @mwadams @karenetheridge + - Neutral - @relequestual + - Against - @julian ## Context and Problem Statement There's a long and sticky history around format. 1. Going back all the way to Draft 01, format has never required validation. -2. Whether to support format validation has always been the decision of the implementation. -3. The extent to which formats are validated has also been the decision of the implementation. - -The result of all of this is that implementation support for validation has been spotty at best. Despite the JSON Schema specs referencing very concretely defined formats (by referencing other specs), implementations that do support validation don't all support each format equally. This has been the primary driving force behind keeping format as an opt-in validation. - -With 2019-09, we decided that it was time to give the option of format validation to the schema author. They could enable validation by using a meta-schema which listed the Format Vocabulary with a true value, which meant, "format validation is required to process this schema." - -In 2020-12, we further refined this by offering two separate vocabularies, one that treats the keyword as an annotation and one that treats it as an assertion. The argument was that the behavior of a keyword shouldn't change based on whether the vocabulary was required or not. - -However, the fact remains that our users consistently report (via questions in Slack, GitHub, and StackOverflow) that they expect format to validate. (The most recent case I can think of was only last week, in .Net's effort to build a short-term solution for schema generation from types.) +2. Whether to support format validation has always been the decision of the + implementation. +3. The extent to which formats are validated has also been the decision of the + implementation. + +The result of all of this is that implementation support for validation has been +spotty at best. Despite the JSON Schema specs referencing very concretely +defined formats (by referencing other specs), implementations that do support +validation don't all support each format equally. This has been the primary +driving force behind keeping format as an opt-in validation. + +With 2019-09, we decided that it was time to give the option of format +validation to the schema author. They could enable validation by using a +meta-schema which listed the Format Vocabulary with a true value, which meant, +"format validation is required to process this schema." + +In 2020-12, we further refined this by offering two separate vocabularies, one +that treats the keyword as an annotation and one that treats it as an assertion. +The argument was that the behavior of a keyword shouldn't change based on +whether the vocabulary was required or not. + +However, the fact remains that our users consistently report (via questions in +Slack, GitHub, and StackOverflow) that they expect format to validate. (The most +recent case I can think of was only last week, in .Net's effort to build a +short-term solution for schema generation from types.) Due to this consistency in user expectations, we have decided to: 1. make format an assertion keyword, and -2. strictly enforce it by moving the appropriate tests into the required section of the Test Suite and building them more completely. +2. strictly enforce it by moving the appropriate tests into the required section + of the Test Suite and building them more completely. ## Decision Drivers -* User expectation -* Current behavior -* Historical context -* Disparity of current implementation support vs the proposed requirements +- User expectation +- Current behavior +- Historical context +- Disparity of current implementation support vs the proposed requirements ## Considered Options ### `format` remains an annotation keyword by default -This is the current state. The primary benefit is that we don't need to make a breaking change. +This is the current state. The primary benefit is that we don't need to make a +breaking change. -The primary downside is that the current system of (1) configuring the tool or (2) incluing the `format-assertion` vocab[^1] is confusing for many and doesn't align with user expectations. +The primary downside is that the current system of (1) configuring the tool or +(2) incluing the `format-assertion` vocab[^1] is confusing for many and doesn't +align with user expectations. -[^1] The `format-assertion` vocabulary will no longer be an option since we have demoted vocabularies to a proposal for the stable release. This leaves tool configuration as the only option to enable `format` validation. +[^1] The `format-assertion` vocabulary will no longer be an option since we have +demoted vocabularies to a proposal for the stable release. This leaves tool +configuration as the only option to enable `format` validation. ### `format` becomes an assertion keyword by default -We change the spec to require `format` validation. Furthermore: +We change the spec to require `format` validation. Furthermore: -* Implementations SHOULD support `format` with the defined values -* Implementations MAY support others, but only by explicit config -* Implementations MUST refuse to process a schema that contains an unsupported format +- Implementations SHOULD support `format` with the defined values +- Implementations MAY support others, but only by explicit config +- Implementations MUST refuse to process a schema that contains an unsupported format ## Decision Outcome -The TSC has decided via vote (see voting issue above) that we should change `format` to act as an assertion by default, in line with option (2). +The TSC has decided via vote (see voting issue above) that we should change +`format` to act as an assertion by default, in line with option (2). ### Positive Consequences -* Aligns with user expectations. -* Users are still able to have purely annotative behavior through use of something like `x-format`. -* Increased consistency for `format` validation across implementations. +- Aligns with user expectations. +- Users are still able to have purely annotative behavior through use of something like `x-format`. +- Increased consistency for `format` validation across implementations. ### Negative Consequences -* This is a breaking change, which means that we will likely have to re-educate the users who correctly treat it as an annotation. -* Older schemas which do not specify a version (`$schema`) may change their validation outcome. -* The burden on implementations will be greater since format validation was previously optional. - -## Links - -* [Link type] [Link to ADR] -* … +- This is a breaking change, which means that we will likely have to re-educate + the users who correctly treat it as an annotation. +- Older schemas which do not specify a version (`$schema`) may change their + validation outcome. +- The burden on implementations will be greater since format validation was + previously optional. From f2c98cb4bb59e87f078be74f4099e4c9a8cf2e77 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 27 Nov 2024 20:12:41 +1300 Subject: [PATCH 703/780] update adr formatting again --- adr/2024-11-2-assertion-format.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/adr/2024-11-2-assertion-format.md b/adr/2024-11-2-assertion-format.md index a73f2f67..7f45c23c 100644 --- a/adr/2024-11-2-assertion-format.md +++ b/adr/2024-11-2-assertion-format.md @@ -1,12 +1,12 @@ -# [short title of solved problem and solution] +# `format` as an assertion - Status: proposed - Deciders: @gregsdennis @jdesrosiers @julian @jviotti @mwadams @karenetheridge @relequestual - Date: 2024-11-02 -- Technical Story: https://github.com/json-schema-org/json-schema-spec/issues/1520 -- Voting issue: https://github.com/json-schema-org/TSC/issues/19 +- Technical Story: +- Voting issue: - For - @gregsdennis @jdesrosiers @jviotti @mwadams @karenetheridge - Neutral - @relequestual - Against - @julian @@ -16,9 +16,9 @@ There's a long and sticky history around format. 1. Going back all the way to Draft 01, format has never required validation. -2. Whether to support format validation has always been the decision of the +1. Whether to support format validation has always been the decision of the implementation. -3. The extent to which formats are validated has also been the decision of the +1. The extent to which formats are validated has also been the decision of the implementation. The result of all of this is that implementation support for validation has been @@ -45,7 +45,7 @@ short-term solution for schema generation from types.) Due to this consistency in user expectations, we have decided to: 1. make format an assertion keyword, and -2. strictly enforce it by moving the appropriate tests into the required section +1. strictly enforce it by moving the appropriate tests into the required section of the Test Suite and building them more completely. ## Decision Drivers @@ -63,8 +63,8 @@ This is the current state. The primary benefit is that we don't need to make a breaking change. The primary downside is that the current system of (1) configuring the tool or -(2) incluing the `format-assertion` vocab[^1] is confusing for many and doesn't -align with user expectations. +(2) incluing the `format-assertion` vocab is confusing for many and doesn't +align with user expectations.[^1] [^1] The `format-assertion` vocabulary will no longer be an option since we have demoted vocabularies to a proposal for the stable release. This leaves tool @@ -76,7 +76,8 @@ We change the spec to require `format` validation. Furthermore: - Implementations SHOULD support `format` with the defined values - Implementations MAY support others, but only by explicit config -- Implementations MUST refuse to process a schema that contains an unsupported format +- Implementations MUST refuse to process a schema that contains an unsupported + format ## Decision Outcome @@ -86,7 +87,8 @@ The TSC has decided via vote (see voting issue above) that we should change ### Positive Consequences - Aligns with user expectations. -- Users are still able to have purely annotative behavior through use of something like `x-format`. +- Users are still able to have purely annotative behavior through use of + something like `x-format`. - Increased consistency for `format` validation across implementations. ### Negative Consequences From 54f15de77aab80ee9a7fdd527afcf386cb58e7b8 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 27 Nov 2024 20:14:45 +1300 Subject: [PATCH 704/780] footnotes need a colon --- adr/2024-11-2-assertion-format.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/adr/2024-11-2-assertion-format.md b/adr/2024-11-2-assertion-format.md index 7f45c23c..9941de2a 100644 --- a/adr/2024-11-2-assertion-format.md +++ b/adr/2024-11-2-assertion-format.md @@ -63,10 +63,10 @@ This is the current state. The primary benefit is that we don't need to make a breaking change. The primary downside is that the current system of (1) configuring the tool or -(2) incluing the `format-assertion` vocab is confusing for many and doesn't -align with user expectations.[^1] +(2) incluing the `format-assertion` vocab[^1] is confusing for many and doesn't +align with user expectations. -[^1] The `format-assertion` vocabulary will no longer be an option since we have +[^1]: The `format-assertion` vocabulary will no longer be an option since we have demoted vocabularies to a proposal for the stable release. This leaves tool configuration as the only option to enable `format` validation. From 48b346be8603aa064f814d9f7fc01b83aac6175e Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 27 Nov 2024 20:17:24 +1300 Subject: [PATCH 705/780] apparently the footnote needs to be at the end for this file --- adr/2024-11-2-assertion-format.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/adr/2024-11-2-assertion-format.md b/adr/2024-11-2-assertion-format.md index 9941de2a..9546197d 100644 --- a/adr/2024-11-2-assertion-format.md +++ b/adr/2024-11-2-assertion-format.md @@ -66,10 +66,6 @@ The primary downside is that the current system of (1) configuring the tool or (2) incluing the `format-assertion` vocab[^1] is confusing for many and doesn't align with user expectations. -[^1]: The `format-assertion` vocabulary will no longer be an option since we have -demoted vocabularies to a proposal for the stable release. This leaves tool -configuration as the only option to enable `format` validation. - ### `format` becomes an assertion keyword by default We change the spec to require `format` validation. Furthermore: @@ -99,3 +95,7 @@ The TSC has decided via vote (see voting issue above) that we should change validation outcome. - The burden on implementations will be greater since format validation was previously optional. + +[^1]: The `format-assertion` vocabulary will no longer be an option since we +have demoted vocabularies to a proposal for the stable release. This leaves tool +configuration as the only option to enable `format` validation. From 1edbad0f903328b61581a58189407abe47031945 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 3 Jan 2025 12:18:02 +1300 Subject: [PATCH 706/780] removed IRI language from $dynamicRef passages --- specs/jsonschema-core.md | 35 ++++++++++++++++------------------- 1 file changed, 16 insertions(+), 19 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index f67bf4be..c3ac02b7 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -547,8 +547,8 @@ determined at runtime. While custom identifier keywords are possible, extension designers should take care not to disrupt the functioning of core keywords. For example, the -`$dynamicAnchor` keyword in this specification limits its IRI resolution effects -to the matching `$dynamicRef` keyword, leaving the behavior of `$ref` +`$dynamicAnchor` keyword in this specification limits its resolution behavior +to matching `$dynamicRef` keywords, leaving the behavior of `$ref` undisturbed. ### Applicators {#applicators} @@ -980,18 +980,9 @@ result is undefined, and even if documented will not be interoperable. #### Schema References {#references} -Several keywords can be used to reference a schema which is to be applied to the -current instance location. `$ref` and `$dynamicRef` are applicator keywords, -applying the referenced schema to the instance. - -As the values of `$ref` and `$dynamicRef` are IRI References, this allows the -possibility to externalise or divide a schema across multiple files, and -provides the ability to validate recursive structures through self-reference. - -The resolved IRI produced by these keywords is not necessarily a network -locator, only an identifier. A schema need not be downloadable from the address -if it is a network-addressable URL. Implementations which can access the network -SHOULD default to operating offline. +`$ref` and `$dynamicRef` can be used to reference a schema which is to be +applied to the current instance location. As such, they are considered +applicators, applying the referenced schema to the instance. ##### Direct References with `$ref` {#ref} @@ -1006,6 +997,11 @@ Resolved against the current IRI base, it produces the IRI of the schema to apply. This resolution is safe to perform on schema load, as the process of evaluating an instance cannot change how the reference resolves. +The resolved IRI produced by `$ref` is not necessarily a network +locator, only an identifier. A schema need not be downloadable from the address +if it is a network-addressable URL. Implementations which can access the network +SHOULD default to operating offline. + ##### Dynamic References with `$dynamicRef` {#dynamic-ref} The `$dynamicRef` keyword is an applicator that allows for deferring the full @@ -1013,15 +1009,16 @@ resolution until runtime, at which point it is resolved each time it is encountered while evaluating an instance. Together with `$dynamicAnchor`, `$dynamicRef` implements a cooperative extension -mechanism that is primarily useful to extend recursive schemas, where +mechanism that is primarily useful to to create open schemas, where `$dynamicRef` defines the extension point and `$dynamicAnchor` defines the target. -The value of the `$dynamicRef` property MUST be a valid -[plain name fragment](#fragments).[^3] +The value of the `$dynamicRef` property MUST be formatted as a valid +[IRI plain name fragment](#fragments).[^3] -[^3]: `$dynamicAnchor` defines the anchor with plain text, e.g. `foo`; the -`$dynamicRef` that references it uses a URI fragment syntax, e.g. `#foo`. +[^3]: `$dynamicAnchor` defines the anchor with plain text, e.g. `foo`. Although +the value of `$dynamicRef` is not an IRI fragment, for historical reasons, the +value still uses an IRI fragment syntax, e.g. `#foo`. Resolution of `$dynamicRef` begins by identifying the outermost schema resource in the [dynamic scope](#scopes) which defines a matching From eec2c4c56daec0bf61c9ddf509073fe78f3b4c95 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 3 Jan 2025 12:20:43 +1300 Subject: [PATCH 707/780] update year on ietf specs --- specs/jsonschema-use-cases.xml | 2 +- specs/relative-json-pointer.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/jsonschema-use-cases.xml b/specs/jsonschema-use-cases.xml index ce2dc1fe..7269533d 100644 --- a/specs/jsonschema-use-cases.xml +++ b/specs/jsonschema-use-cases.xml @@ -23,7 +23,7 @@ - + JSON Schema JSON Schema diff --git a/specs/relative-json-pointer.xml b/specs/relative-json-pointer.xml index 5d3d7b20..f00cb1ee 100644 --- a/specs/relative-json-pointer.xml +++ b/specs/relative-json-pointer.xml @@ -40,7 +40,7 @@ - + Internet Engineering Task Force JSON JavaScript From 824fee7346e2ef266882746af033ffde0f7ec6df Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 5 Jan 2025 16:19:01 +1300 Subject: [PATCH 708/780] replace all external document references with links to document; remove appendices --- specs/jsonschema-core.md | 181 ++++-------------- specs/jsonschema-validation.md | 102 +++++----- .../jsonschema-validation-output-machines.md | 45 +---- 3 files changed, 89 insertions(+), 239 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 0670e2a7..40ab9af6 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -39,11 +39,11 @@ such as output formats. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be -interpreted as described in [RFC 2119](#rfc2119). +interpreted as described in [RFC 2119](https://www.rfc-editor.org/info/rfc2119). The terms "JSON", "JSON text", "JSON value", "member", "element", "object", "array", "number", "string", "boolean", "true", "false", and "null" in this -document are to be interpreted as defined in [RFC 8259](#rfc8259). +document are to be interpreted as defined in [RFC 8259](https://www.rfc-editor.org/info/rfc8259). ## Overview @@ -242,10 +242,10 @@ are using. #### Root Schema and Subschemas and Resources {#root} -A JSON Schema resource is a schema which is [canonically](#rfc6596) identified -by an [absolute IRI](#rfc3987). Schema resources MAY also be identified by IRIs, +A JSON Schema resource is a schema which is [canonically](https://www.rfc-editor.org/info/rfc6596) identified +by an [absolute IRI](https://www.rfc-editor.org/info/rfc3987). Schema resources MAY also be identified by IRIs, including IRIs with fragments, if the resulting secondary resource (as defined -by [section 3.5 of RFC 3986](#rfc3986)) is identical to the primary resource. +by [section 3.5 of RFC 3986](https://www.rfc-editor.org/info/rfc3986)) is identical to the primary resource. This can occur with the empty fragment, or when one schema resource is embedded in another. Any such IRIs with fragments are considered to be non-canonical. @@ -285,7 +285,7 @@ are processed in the same way, with the same available behaviors. ## Fragment Identifiers {#fragments} -In accordance with section 3.1 of [RFC 6839](#rfc6839), the syntax and semantics +In accordance with section 3.1 of [RFC 6839](https://www.rfc-editor.org/info/rfc6839), the syntax and semantics of fragment identifiers specified for any +json media type SHOULD be as specified for `application/json`. (At publication of this document, there is no fragment identification syntax defined for `application/json`.) @@ -296,7 +296,7 @@ identifier structures: plain names and JSON Pointers. The structure: JSON Pointers. The use of JSON Pointers as IRI fragment identifiers is described in [RFC -6901](#rfc6901). For `application/schema+json`, which supports two fragment +6901](https://www.rfc-editor.org/info/rfc6901). For `application/schema+json`, which supports two fragment identifier syntaxes, fragment identifiers matching the JSON Pointer syntax, including the empty string, MUST be interpreted as JSON Pointer fragment identifiers. @@ -306,9 +306,9 @@ identifiers](#w3cwd-fragid-best-practices-20121025), plain name fragment identifiers in `application/schema+json` are reserved for referencing locally named schemas. -Plain name fragments MUST follow XML's [`NCName` production](#xml-names), which +Plain name fragments MUST follow XML's [`NCName` production](http://www.w3.org/TR/2006/REC-xml-names11-20060816), which allows for compatibility with the recommended plain name -[syntax](#w3crec-xptr-framework-20030325) for XML-based media types. For +[syntax](https://www.w3.org/TR/2003/REC-xptr-framework-20030325/) for XML-based media types. For convenience, the `NCName` syntax is reproduced here in ABNF form, using a minimal set of rules: @@ -336,7 +336,7 @@ keyword](#anchors) section. ### Range of JSON Values -An instance may be any valid JSON value as defined by [JSON](#rfc8259). JSON +An instance may be any valid JSON value as defined by [JSON](https://www.rfc-editor.org/info/rfc8259). JSON Schema imposes no restrictions on type: JSON Schema can describe any JSON value, including, for example, null. @@ -352,7 +352,7 @@ describable by JSON. Keywords MAY use regular expressions to express constraints, or constrain the instance value to be a regular expression. These regular expressions SHOULD be valid according to the regular expression dialect described in [ECMA-262, -section 21.2.1](#ecma262). +section 21.2.1](https://www.ecma-international.org/ecma-262/11.0/index.html). Unless otherwise specified by a keyword, regular expressions MUST NOT be considered to be implicitly anchored at either end. All regular expression @@ -367,7 +367,7 @@ schema authors SHOULD limit themselves to the following regular expression tokens: - individual Unicode characters, as defined by the [JSON - specification](#rfc8259); + specification](https://www.rfc-editor.org/info/rfc8259); - simple atoms: `.` (any character except line terminator); - simple character classes (`[abc]`), range character classes (`[a-z]`); - complemented simple character classes (`[^abc]`); @@ -653,7 +653,7 @@ behalf of applications. Unless otherwise specified, the value of an annotation keyword is the keyword's value. However, other behaviors are possible. For example, [JSON -Hyper-Schema's](#json-hyper-schema) `links` keyword is a complex annotation that +Hyper-Schema's](https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-hyperschema-02) `links` keyword is a complex annotation that produces a value based in part on the instance data. While "short-circuit" evaluation is possible for assertions, collecting @@ -685,7 +685,7 @@ based on the schema location that contributed the value. This is intended to allow flexible usage. Collecting the schema location facilitates such usage. For example, consider this schema, which uses annotations and assertions from -the [Validation specification](#json-schema-validation): +the [Validation specification](./jsonschema-validation): Note that some lines are wrapped for clarity. @@ -880,7 +880,7 @@ applies to the resource in which it is declared as well as any embedded schema resources, unless such a resource itself declares a different dialect by including the `$schema` keyword with a different value. -The value of this keyword MUST be an [IRI](#rfc3987) (containing a scheme) and +The value of this keyword MUST be an [IRI](https://www.rfc-editor.org/info/rfc3987) (containing a scheme) and this IRI MUST be normalized. If this IRI identifies a retrievable resource, that resource SHOULD be of media @@ -896,12 +896,12 @@ by other parties. ### Base IRI, Anchors, and Dereferencing To differentiate between schemas in a vast ecosystem, schema resources are -identified by [absolute IRIs](#rfc3987) (without fragments). These identifiers +identified by [absolute IRIs](https://www.rfc-editor.org/info/rfc3987) (without fragments). These identifiers are used to create references between schema resources. When comparing IRIs for the purposes of resource identification, implementations SHOULD first follow the -IRI normalization procedures defined in [RFC 3987](#rfc3987), section 5.3. +IRI normalization procedures defined in [RFC 3987](https://www.rfc-editor.org/info/rfc3987), section 5.3. -Several keywords can accept a relative [IRI reference](#rfc3987), or a value +Several keywords can accept a relative [IRI reference](https://www.rfc-editor.org/info/rfc3987), or a value used to construct a relative IRI reference. For these keywords, it is necessary to establish a base IRI in order to resolve the reference. @@ -909,13 +909,13 @@ to establish a base IRI in order to resolve the reference. An `$id` keyword in a schema or subschema identifies that schema or subschema as a distinct schema resource. The value for this keyword MUST be a string, and -MUST represent a valid [IRI reference](#rfc3987) without a fragment. +MUST represent a valid [IRI reference](https://www.rfc-editor.org/info/rfc3987) without a fragment. When the value of this keyword is resolved against the current base IRI, the resulting absolute IRI then serves as the identifier for the schema resource and as a base IRI for relative IRI references in keywords within that schema resource and for embedded schema resources, in accordance with [RFC 3987 section -6.5](#rfc3987) and [RFC 3986 section 5.1.1](#rfc3986) regarding base IRIs +6.5](https://www.rfc-editor.org/info/rfc3987) and [RFC 3986 section 5.1.1](https://www.rfc-editor.org/info/rfc3986) regarding base IRIs embedded in content and RFC 3986 section 5.1.2 regarding encapsulating entities. Note that this IRI is an identifier and not necessarily a network locator. In @@ -933,7 +933,7 @@ given in {{initial-base}}. ##### Identifying the root schema The root schema of a JSON Schema document SHOULD contain an `$id` keyword with -an [absolute IRI](#rfc3987) (containing a scheme, but no fragment). +an [absolute IRI](https://www.rfc-editor.org/info/rfc3987) (containing a scheme, but no fragment). #### Defining location-independent identifiers {#anchors} @@ -951,7 +951,8 @@ fragments, rather than absolute IRIs as seen with `$id`. keyword is appended to the IRI of the schema resource containing it. As discussed in {{id-keyword}}, this is either the nearest `$id` in the same or an ancestor schema object, or the base IRI for the document as determined according -to [RFC 3987](#rfc3987) and [RFC 3986](#rfc3986). +to [RFC 3987](https://www.rfc-editor.org/info/rfc3987) and +[RFC 3986](https://www.rfc-editor.org/info/rfc3986). In contrast, `$dynamicAnchor` operates independently of resource IRIs and is instead dependent on the dynamic scope of the evaluation. `$dynamicAnchor` @@ -1086,7 +1087,7 @@ MUST NOT be collected as an annotation result. #### Initial Base IRI {#initial-base} -[RFC 3987 Section 6.5](#rfc3987) and [RFC 3986 Section 5.1](#rfc3986) defines +[RFC 3987 Section 6.5](https://www.rfc-editor.org/info/rfc3987) and [RFC 3986 Section 5.1](https://www.rfc-editor.org/info/rfc3986) defines how to determine the default base IRI of a document. Informatively, the initial base IRI of a schema is the IRI at which it was @@ -1094,12 +1095,12 @@ found, whether that was a network location, a local filesystem, or any other situation identifiable by a IRI of any known scheme. If a schema document defines no explicit base IRI with `$id` (embedded in -content), the base IRI is that determined per [RFC 3987 Section 6.5](#rfc3987) -and [RFC 3986 section 5](#rfc3986). +content), the base IRI is that determined per [RFC 3987 Section 6.5](https://www.rfc-editor.org/info/rfc3987) +and [RFC 3986 section 5](https://www.rfc-editor.org/info/rfc3986). If no source is known, or no IRI scheme is known for the source, a suitable implementation-specific default IRI MAY be used as described in [RFC 3987 -Section 6.5](#rfc3987) and [RFC 3986 Section 5.1.4](#rfc3986). It is RECOMMENDED +Section 6.5](https://www.rfc-editor.org/info/rfc3987) and [RFC 3986 Section 5.1.4](https://www.rfc-editor.org/info/rfc3986). It is RECOMMENDED that implementations document any default base IRI that they assume. If a schema object is embedded in a document of another media type, then the @@ -1151,7 +1152,7 @@ expect such features to be interoperable across implementations. Schemas can be identified by any IRI that has been given to them, including a JSON Pointer or their IRI given directly by `$id`. In all cases, dereferencing a `$ref` reference involves first resolving its value as a IRI reference against -the current base IRI per [RFC 3986](#rfc3986). +the current base IRI per [RFC 3986](https://www.rfc-editor.org/info/rfc3986). If the resulting IRI identifies a schema within the current document, or within another schema document that has been made available to the implementation, then @@ -1423,16 +1424,16 @@ all annotation results), would result in a resolution failure. JSON has been adopted widely by HTTP servers for automated APIs and robots. This section describes how to enhance processing of JSON documents in a more RESTful manner when used with protocols that support media types and [Web -linking](#rfc8288). +linking](https://www.rfc-editor.org/info/rfc8288). ##### Linking to a Schema It is RECOMMENDED that instances described by a schema provide a link to a downloadable JSON Schema using the link relation "describedby", as defined by -[Linked Data Protocol 1.0, section 8.1](#w3crec-ldp-20150226). +[Linked Data Protocol 1.0, section 8.1](https://www.w3.org/TR/2015/REC-ldp-20150226). In HTTP, such links can be attached to any response using the [Link -header](#rfc8288). An example of such a header would be: +header](https://www.rfc-editor.org/info/rfc8288). An example of such a header would be: ``` Link: ; rel="describedby" @@ -1440,7 +1441,7 @@ Link: ; rel="describedby" ##### Usage Over HTTP -When used for hypermedia systems over a network, [HTTP](#rfc7231) is frequently +When used for hypermedia systems over a network, [HTTP](https://www.rfc-editor.org/info/rfc7231) is frequently the protocol of choice for distributing schemas. Misbehaving clients can pose problems for server maintainers if they pull a schema over the network more frequently than necessary, when it's instead possible to cache a schema for a @@ -1954,7 +1955,7 @@ SHOULD use the terms defined by this document to do so. ## Security Considerations {#security} Both schemas and instances are JSON values. As such, all security considerations -defined in [RFC 8259](#rfc8259) apply. +defined in [RFC 8259](https://www.rfc-editor.org/info/rfc8259) apply. Instances and schemas are both frequently written by untrusted third parties, to be deployed on public Internet servers. Implementations should take care that @@ -1993,7 +1994,7 @@ Subtype name:: schema+json Required parameters:: N/A Encoding considerations:: Encoding considerations are identical to those -specified for the `application/json` media type. See [JSON](#rfc8259). +specified for the `application/json` media type. See [JSON](https://www.rfc-editor.org/info/rfc8259). Security considerations:: See {{security}} above. @@ -2014,7 +2015,7 @@ Subtype name:: schema-instance+json Required parameters:: N/A Encoding considerations:: Encoding considerations are identical to those -specified for the `application/json` media type. See [JSON](#rfc8259). +specified for the `application/json` media type. See [JSON](https://www.rfc-editor.org/info/rfc8259). Security considerations:: See {{security}} above. @@ -2023,116 +2024,6 @@ Interoperability considerations:: See Sections [6.2](#language), Fragment identifier considerations:: See {{fragments}} -## References - -### Normative References - -#### [RFC2119] {#rfc2119} - -Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, -RFC 2119, DOI 10.17487/RFC2119, March 1997, -<>. - -#### [RFC3986] {#rfc3986} - -Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier -(URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, -<>. - -#### [RFC3987] {#rfc3987} - -Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC -3987, DOI 10.17487/RFC3987, January 2005, -<>. - -#### [RFC6839] {#rfc6839} - -Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", -RFC 6839, DOI 10.17487/RFC6839, January 2013, -<>. - -#### [RFC6901] {#rfc6901} - -Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation -(JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, -<>. - -#### [RFC8259] {#rfc8259} - -Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", -STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, -<>. - -#### [W3C.REC-ldp-20150226] {#w3crec-ldp-20150226} - -Malhotra, A., Ed., Arwe, J., Ed., and S. Speicher, Ed., "Linked Data Platform -1.0", W3C REC REC-ldp-20150226, W3C REC-ldp-20150226, 26 February 2015, -<>. - -#### [ecma262] {#ecma262} - -"ECMA-262, 11th edition specification", June 2020, -<>. - -### Informative References - -#### [RFC6596] {#rfc6596} - -Ohye, M. and J. Kupke, "The Canonical Link Relation", RFC 6596, DOI -10.17487/RFC6596, April 2012, <>. - -#### [RFC7049] {#rfc7049} - -Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC -7049, DOI 10.17487/RFC7049, October 2013, -<>. - -#### [RFC7231] {#rfc7231} - -Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): -Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, -<>. - -#### [RFC8288] {#rfc8288} - -Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, -<>. - -#### [W3C.WD-fragid-best-practices-20121025] -{#w3cwd-fragid-best-practices-20121025} - -Tennison, J., Ed., "Best Practices for Fragment Identifiers and Media Type -Definitions", W3C WD WD-fragid-best-practices-20121025, W3C -WD-fragid-best-practices-20121025, 25 October 2012, -<>. - -#### [W3C.REC-xptr-framework-20030325] {#w3crec-xptr-framework-20030325} - -Maler, E., Ed., Marsh, J., Ed., Walsh, N., Ed., and P. Grosso, Ed., "XPointer -Framework", W3C REC REC-xptr-framework-20030325, W3C -REC-xptr-framework-20030325, 25 March 2003, -<>. - -#### [json-schema-validation] {#json-schema-validation} - -Wright, A., Andrews, H., and B. Hutton, "JSON Schema Validation: A Vocabulary -for Structural Validation of JSON", Work in Progress, Internet-Draft, -draft-bhutton-json-schema-validation-01, June 2022, -<>. - -#### [json-hyper-schema] {#json-hyper-schema} - -Andrews, H. and A. Wright, "JSON Hyper-Schema: A Vocabulary for Hypermedia -Annotation of JSON", Work in Progress, Internet-Draft, -draft-handrews-json-schema-hyperschema-02, November 2017, -<>. - -#### [xml-names] {#xml-names} - -Bray, T., Ed., Hollander, D., Ed., Layman, A., Ed., and R. Tobin, Ed., -"Namespaces in XML 1.1 (Second Edition)", August 2006, -<>. - ## %appendix% Schema identification examples {#idexamples} Consider the following schema, which shows `$id` being used to identify both the @@ -2162,7 +2053,7 @@ name fragment identifiers. ``` The schemas at the following locations (indicated by plain -[JSON Pointers](#rfc6901) relative to the root document) have the following base +[JSON Pointers](https://www.rfc-editor.org/info/rfc6901) relative to the root document) have the following base IRIs, and are identifiable by any listed IRI in accordance with {{fragments}} and {{embedded}} above. diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index f20f64b2..8af76d89 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -29,19 +29,19 @@ keywords described in this specification. In addition, a set of keywords is also defined to assist in interactive user interface instance generation. This specification will use the concepts, syntax, and terminology defined by the -[JSON Schema core](#json-schema) specification. +[JSON Schema core](./jsonschema-core) specification. ## Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be -interpreted as described in [RFC 2119](#rfc2119). +interpreted as described in [RFC 2119](https://www.rfc-editor.org/info/rfc2119). This specification uses the term "container instance" to refer to both array and object instances. It uses the term "children instances" to refer to array elements or object member values. Elements in an array value are said to be unique if no two elements of this -array are [equal](#json-schema). +array are [equal](./jsonschema-core). ## Overview @@ -82,7 +82,7 @@ with such data. Keywords that use regular expressions, or constrain the instance value to be a regular expression, are subject to the interoperability considerations for -regular expressions in the [JSON Schema Core](#json-schema) specification. +regular expressions in the [JSON Schema Core](./jsonschema-core) specification. ## Meta-Schema {#meta-schema} @@ -192,7 +192,7 @@ A string instance is valid against this keyword if its length is less than, or equal to, the value of this keyword. The length of a string instance is defined as the number of its characters as -defined by [RFC 8259](#rfc8259). +defined by [RFC 8259](https://www.rfc-editor.org/info/rfc8259). #### `minLength` @@ -202,7 +202,7 @@ A string instance is valid against this keyword if its length is greater than, or equal to, the value of this keyword. The length of a string instance is defined as the number of its characters as -defined by [RFC 8259](#rfc8259). +defined by [RFC 8259](https://www.rfc-editor.org/info/rfc8259). Omitting this keyword has the same behavior as a value of 0. @@ -303,7 +303,7 @@ type, each distinct value will generally only validate a given set of instance types. If the type of the instance to validate is not in this set, validation for this keyword SHOULD succeed. All format values defined in this section apply to strings, but a format value can be specified to apply to any instance types -defined in the data model defined in the [core JSON Schema](#json-schema) specification[^1]. +defined in the data model defined in the [core JSON Schema](./jsonschema-core) specification[^1]. [^1]: Note that the `type` keyword in this specification defines an "integer" type which is not part of the data model. Therefore a format attribute can be @@ -354,7 +354,7 @@ custom format values. These attributes apply to string instances. -Date and time format names are derived from [RFC 3339, section 5.6](#rfc3339). +Date and time format names are derived from [RFC 3339, section 5.6](https://www.rfc-editor.org/info/rfc3339). The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339. @@ -386,9 +386,9 @@ A string instance is valid against these format values if it is a valid Internet email address as follows: - *email:* As defined by the "Mailbox" ABNF rule in [RFC 5321, section - 4.1.2](#rfc5321). + 4.1.2](https://www.rfc-editor.org/info/rfc5321). - *idn-email:* As defined by the extended "Mailbox" ABNF rule in [RFC 6531, - section 3.3](#rfc6531). Note that all strings valid against the "email" + section 3.3](https://www.rfc-editor.org/info/rfc6531). Note that all strings valid against the "email" attribute are also valid against the "idn-email" attribute. #### Hostnames @@ -398,12 +398,12 @@ These attributes apply to string instances. A string instance is valid against these attributes if it is a valid representation for an Internet hostname as follows: -- *hostname:* As defined by [RFC 1123, section 2.1](#rfc1123), including host +- *hostname:* As defined by [RFC 1123, section 2.1](https://www.rfc-editor.org/info/rfc1123), including host names produced using the Punycode algorithm specified in [RFC 5891, section - 4.4](#rfc5891). + 4.4](https://www.rfc-editor.org/info/rfc5891). - *idn-hostname:* As defined by either RFC 1123 as for hostname, or an internationalized hostname as defined by [RFC 5890, section - 2.3.2.3](#rfc5890). Note that all strings valid against the "hostname" + 2.3.2.3](https://www.rfc-editor.org/info/rfc5890). Note that all strings valid against the "hostname" attribute are also valid against the "idn-hostname" attribute. #### IP Addresses @@ -414,23 +414,23 @@ A string instance is valid against these attributes if it is a valid representation of an IP address as follows: - *ipv4:* An IPv4 address according to the "dotted-quad" ABNF syntax as defined - in [RFC 2673, section 3.2](#rfc2673). -- *ipv6:* An IPv6 address as defined in [RFC 4291, section 2.2](#rfc4291). + in [RFC 2673, section 3.2](https://www.rfc-editor.org/info/rfc2673). +- *ipv6:* An IPv6 address as defined in [RFC 4291, section 2.2](https://www.rfc-editor.org/info/rfc4291). #### Resource Identifiers These attributes apply to string instances. - *uri:* A string instance is valid against this attribute if it is a valid IRI, - according to [RFC3987](#rfc3987). + according to [RFC3987](https://www.rfc-editor.org/info/rfc3987). - *uri-reference:* A string instance is valid against this attribute if it is a valid URI Reference (either a URI or a relative-reference), according to - [RFC3986](#rfc3986). + [RFC3986](https://www.rfc-editor.org/info/rfc3986). - *iri:* A string instance is valid against this attribute if it is a valid IRI, - according to [RFC3987](#rfc3987). + according to [RFC3987](https://www.rfc-editor.org/info/rfc3987). - *iri-reference:* A string instance is valid against this attribute if it is a valid IRI Reference (either an IRI or a relative-reference), according to - [RFC3987](#rfc3987). + [RFC3987](https://www.rfc-editor.org/info/rfc3987). - *uuid:* A string instance is valid against this attribute if it is a valid - string representation of a UUID, according to [RFC4122](#rfc4122). + string representation of a UUID, according to [RFC4122](https://www.rfc-editor.org/info/rfc4122). Note that all valid URIs are valid IRIs, and all valid URI References are also valid IRI References. @@ -445,7 +445,7 @@ the URI scheme and URN namespace. This attribute applies to string instances. A string instance is valid against this attribute if it is a valid URI Template -(of any level), according to [RFC6570](#rfc6570). +(of any level), according to [RFC6570](https://www.rfc-editor.org/info/rfc6570). Note that URI Templates may be used for IRIs; there is no separate IRI Template specification. @@ -456,9 +456,9 @@ These attributes apply to string instances. - *json-pointer:* A string instance is valid against this attribute if it is a valid JSON string representation of a JSON Pointer, according to [RFC 6901, - section 5](#rfc6901). + section 5](https://www.rfc-editor.org/info/rfc6901). - *relative-json-pointer:* A string instance is valid against this attribute if - it is a valid [Relative JSON Pointer](#relative-json-pointer). To allow for + it is a valid [Relative JSON Pointer](https://datatracker.ietf.org/doc/html/draft-handrews-relative-json-pointer-01). To allow for both absolute and relative JSON Pointers, use `anyOf` or `oneOf` to indicate support for either format. @@ -467,7 +467,7 @@ These attributes apply to string instances. This attribute applies to string instances. A regular expression, which SHOULD be valid according to the -[ECMA-262](#ecma262) regular expression dialect. +[ECMA-262](https://www.ecma-international.org/ecma-262/11.0/index.html) regular expression dialect. Implementations that validate formats MUST accept at least the subset of ECMA-262 defined in {{regexinterop}}, and SHOULD accept all valid ECMA-262 @@ -503,8 +503,8 @@ be interpreted as encoded binary data and applications wishing to decode it SHOULD do so using the encoding named by this property. Possible values indicating base 16, 32, and 64 encodings with several variations -are listed in [RFC 4648](#rfc4648). Additionally, sections 6.7 and 6.8 of [RFC -2045](#rfc2045) provide encodings used in MIME. This keyword is derived from +are listed in [RFC 4648](https://www.rfc-editor.org/info/rfc4648). Additionally, sections 6.7 and 6.8 of [RFC +2045](https://www.rfc-editor.org/info/rfc2045) provide encodings used in MIME. This keyword is derived from MIME's Content-Transfer-Encoding header, which was designed to map binary data into ASCII characters. It is not related to HTTP's Content-Encoding header, which is used to encode (e.g. compress or encrypt) the content of HTTP request @@ -529,7 +529,7 @@ contents of the string. If `contentEncoding` is present, this property describes the decoded string. The value of this property MUST be a string, which MUST be a media type, as -defined by [RFC 2046](#rfc2046). +defined by [RFC 2046](https://www.rfc-editor.org/info/rfc2046). ### `contentSchema` @@ -574,7 +574,7 @@ Another example: Instances described by this schema are expected to be strings containing HTML, using whatever character set the JSON string was decoded into. Per section 8.1 -of [RFC 8259](#rfc8259), outside of an entirely closed system, this MUST be +of [RFC 8259](https://www.rfc-editor.org/info/rfc8259), outside of an entirely closed system, this MUST be UTF-8. This example describes a JWT that is MACed using the HMAC SHA-256 algorithm, and @@ -732,128 +732,128 @@ authority). Processing a media type or encoding is subject to the security considerations of that media type or encoding. For example, the security considerations of [RFC -4329 Scripting Media Types](#rfc4329) apply when processing JavaScript or +4329 Scripting Media Types](https://www.rfc-editor.org/info/rfc4329) apply when processing JavaScript or ECMAScript encoded within a JSON string. ## References ### Normative References -#### [RFC2119] {#rfc2119} +#### [RFC2119] {https://www.rfc-editor.org/info/rfc2119} Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>. -#### [RFC1123] {#rfc1123} +#### [RFC1123] {https://www.rfc-editor.org/info/rfc1123} Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <>. -#### [RFC2045] {#rfc2045} +#### [RFC2045] {https://www.rfc-editor.org/info/rfc2045} Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <>. -#### [RFC2046] {#rfc2046} +#### [RFC2046] {https://www.rfc-editor.org/info/rfc2046} Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <>. -#### [RFC2673] {#rfc2673} +#### [RFC2673] {https://www.rfc-editor.org/info/rfc2673} Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, DOI 10.17487/RFC2673, August 1999, <>. -#### [RFC3339] {#rfc3339} +#### [RFC3339] {https://www.rfc-editor.org/info/rfc3339} Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <>. -#### [RFC3986] {#rfc3986} +#### [RFC3986] {https://www.rfc-editor.org/info/rfc3986} Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <>. -#### [RFC3987] {#rfc3987} +#### [RFC3987] {https://www.rfc-editor.org/info/rfc3987} Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <>. -#### [RFC4122] {#rfc4122} +#### [RFC4122] {https://www.rfc-editor.org/info/rfc4122} Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <>. -#### [RFC4291] {#rfc4291} +#### [RFC4291] {https://www.rfc-editor.org/info/rfc4291} Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <>. -#### [RFC4648] {#rfc4648} +#### [RFC4648] {https://www.rfc-editor.org/info/rfc4648} Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <>. -#### [RFC5321] {#rfc5321} +#### [RFC5321] {https://www.rfc-editor.org/info/rfc5321} Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <>. -#### [RFC5890] {#rfc5890} +#### [RFC5890] {https://www.rfc-editor.org/info/rfc5890} Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <>. -#### [RFC5891] {#rfc5891} +#### [RFC5891] {https://www.rfc-editor.org/info/rfc5891} Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <>. -#### [RFC6570] {#rfc6570} +#### [RFC6570] {https://www.rfc-editor.org/info/rfc6570} Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <>. -#### [RFC6531] {#rfc6531} +#### [RFC6531] {https://www.rfc-editor.org/info/rfc6531} Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, <>. -#### [RFC6901] {#rfc6901} +#### [RFC6901] {https://www.rfc-editor.org/info/rfc6901} Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <>. -#### [RFC8259] {#rfc8259} +#### [RFC8259] {https://www.rfc-editor.org/info/rfc8259} Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <>. -#### [ecma262] {#ecma262} +#### [ecma262] {https://www.ecma-international.org/ecma-262/11.0/index.html} ECMA-262, 11th edition specification", June 2020, <>. -#### [relative-json-pointer] {#relative-json-pointer} +#### [relative-json-pointer] {https://datatracker.ietf.org/doc/html/draft-handrews-relative-json-pointer-01} Luff, G., Andrews, H., and B. Hutton, Ed., "Relative JSON Pointers", Work in Progress, Internet-Draft, draft-handrews-relative-json-pointer-01, December 2020, <>. -#### [json-schema] {#json-schema} +#### [json-schema] {./jsonschema-core} Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON Schema: A Media Type for Describing JSON Documents", Work in Progress, Internet-Draft, @@ -862,7 +862,7 @@ draft-bhutton-json-schema-01, June 2022, ### Informative References -#### \[RFC4329\] {#rfc4329} +#### \[RFC4329\] {https://www.rfc-editor.org/info/rfc4329} Hoehrmann, B., "Scripting Media Types", RFC 4329, DOI 10.17487/RFC4329, April 2006, <>. diff --git a/specs/output/jsonschema-validation-output-machines.md b/specs/output/jsonschema-validation-output-machines.md index b9d1787d..db97e048 100644 --- a/specs/output/jsonschema-validation-output-machines.md +++ b/specs/output/jsonschema-validation-output-machines.md @@ -20,7 +20,7 @@ absolute. ## Textual Format and Encoding JSON Schema output is defined using the JSON Schema data instance model as -described in [JSON Schema](#json-schema) "Instance Data Model". Implementations +described in [JSON Schema](./jsonschema-core) "Instance Data Model". Implementations MAY deviate from this in their internal modelling, as supported by their specific languages and platforms, however it is RECOMMENDED that the output be convertible to the JSON format defined herein via serialization or other means. @@ -35,7 +35,7 @@ contents of each output unit is specified by this section. Each output unit MUST contain the [validation result](#validation-result) for the associated subschema as well as the following information defined by -[JSON Schema](#json-schema) "Output Formatting": +[JSON Schema](./jsonschema-core) "Output Formatting": - Evaluation Path - Schema Location @@ -617,44 +617,3 @@ Output units which include annotations MUST NOT be pruned. Implementations which provide this behavior SHOULD provide configuration mechanisms appropriate for their users' needs. - -## References - -### Normative References - -#### \[RFC2119\] {#rfc2119} - -Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, -RFC 2119, DOI 10.17487/RFC2119, March 1997, -<>. - -#### \[RFC3986\] {#rfc3986} - -Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier -(URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, -<>. - -#### \[RFC3987\] {#rfc3987} - -Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC -3987, DOI 10.17487/RFC3987, January 2005, -<>. - -#### \[RFC6901\] {#rfc6901} - -Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation -(JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, -<>. - -#### \[RFC8259\] {#rfc8259} - -Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", -STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, -<>. - -#### \[json-schema\] {#json-schema} - -Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON Schema: A Media Type -for Describing JSON Documents", Work in Progress, Internet-Draft, -draft-bhutton-json-schema-01, June 2022, -<>. From eb10496ca2f121794fc27d1731edffe342db4ea7 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 5 Jan 2025 16:53:16 +1300 Subject: [PATCH 709/780] link more directly to the specific sections --- specs/jsonschema-core.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 40ab9af6..cb19cb03 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -243,9 +243,9 @@ are using. #### Root Schema and Subschemas and Resources {#root} A JSON Schema resource is a schema which is [canonically](https://www.rfc-editor.org/info/rfc6596) identified -by an [absolute IRI](https://www.rfc-editor.org/info/rfc3987). Schema resources MAY also be identified by IRIs, +by an [absolute IRI](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2). Schema resources MAY also be identified by IRIs, including IRIs with fragments, if the resulting secondary resource (as defined -by [section 3.5 of RFC 3986](https://www.rfc-editor.org/info/rfc3986)) is identical to the primary resource. +by [section 3.5 of RFC 3986](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.5)) is identical to the primary resource. This can occur with the empty fragment, or when one schema resource is embedded in another. Any such IRIs with fragments are considered to be non-canonical. @@ -285,7 +285,7 @@ are processed in the same way, with the same available behaviors. ## Fragment Identifiers {#fragments} -In accordance with section 3.1 of [RFC 6839](https://www.rfc-editor.org/info/rfc6839), the syntax and semantics +In accordance with [section 3.1 of RFC 6839](https://www.rfc-editor.org/rfc/rfc6839.html#section-3.1), the syntax and semantics of fragment identifiers specified for any +json media type SHOULD be as specified for `application/json`. (At publication of this document, there is no fragment identification syntax defined for `application/json`.) @@ -306,9 +306,9 @@ identifiers](#w3cwd-fragid-best-practices-20121025), plain name fragment identifiers in `application/schema+json` are reserved for referencing locally named schemas. -Plain name fragments MUST follow XML's [`NCName` production](http://www.w3.org/TR/2006/REC-xml-names11-20060816), which -allows for compatibility with the recommended plain name -[syntax](https://www.w3.org/TR/2003/REC-xptr-framework-20030325/) for XML-based media types. For +Plain name fragments MUST follow XML's [`NCName` production](https://www.w3.org/TR/2006/REC-xml-names11-20060816/#NT-NCName), which +allows for compatibility with the recommended [plain name +syntax](https://www.w3.org/TR/2003/REC-xptr-framework-20030325/) for XML-based media types. For convenience, the `NCName` syntax is reproduced here in ABNF form, using a minimal set of rules: @@ -896,12 +896,12 @@ by other parties. ### Base IRI, Anchors, and Dereferencing To differentiate between schemas in a vast ecosystem, schema resources are -identified by [absolute IRIs](https://www.rfc-editor.org/info/rfc3987) (without fragments). These identifiers +identified by [absolute IRIs](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2) (without fragments). These identifiers are used to create references between schema resources. When comparing IRIs for the purposes of resource identification, implementations SHOULD first follow the IRI normalization procedures defined in [RFC 3987](https://www.rfc-editor.org/info/rfc3987), section 5.3. -Several keywords can accept a relative [IRI reference](https://www.rfc-editor.org/info/rfc3987), or a value +Several keywords can accept a relative [IRI reference](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2), or a value used to construct a relative IRI reference. For these keywords, it is necessary to establish a base IRI in order to resolve the reference. @@ -909,13 +909,13 @@ to establish a base IRI in order to resolve the reference. An `$id` keyword in a schema or subschema identifies that schema or subschema as a distinct schema resource. The value for this keyword MUST be a string, and -MUST represent a valid [IRI reference](https://www.rfc-editor.org/info/rfc3987) without a fragment. +MUST represent a valid [IRI reference](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2) without a fragment. When the value of this keyword is resolved against the current base IRI, the resulting absolute IRI then serves as the identifier for the schema resource and as a base IRI for relative IRI references in keywords within that schema resource and for embedded schema resources, in accordance with [RFC 3987 section -6.5](https://www.rfc-editor.org/info/rfc3987) and [RFC 3986 section 5.1.1](https://www.rfc-editor.org/info/rfc3986) regarding base IRIs +6.5](https://www.rfc-editor.org/rfc/rfc3987.html#section-6.5) and [RFC 3986 section 5.1.1](https://www.rfc-editor.org/rfc/rfc3986.html#section-5.1.1) regarding base IRIs embedded in content and RFC 3986 section 5.1.2 regarding encapsulating entities. Note that this IRI is an identifier and not necessarily a network locator. In @@ -933,7 +933,7 @@ given in {{initial-base}}. ##### Identifying the root schema The root schema of a JSON Schema document SHOULD contain an `$id` keyword with -an [absolute IRI](https://www.rfc-editor.org/info/rfc3987) (containing a scheme, but no fragment). +an [absolute IRI](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2) (containing a scheme, but no fragment). #### Defining location-independent identifiers {#anchors} @@ -1087,7 +1087,7 @@ MUST NOT be collected as an annotation result. #### Initial Base IRI {#initial-base} -[RFC 3987 Section 6.5](https://www.rfc-editor.org/info/rfc3987) and [RFC 3986 Section 5.1](https://www.rfc-editor.org/info/rfc3986) defines +[RFC 3987 Section 6.5](https://www.rfc-editor.org/rfc/rfc3987.html#section-6.5) and [RFC 3986 Section 5.1](https://www.rfc-editor.org/rfc/rfc3986.html#section-5.1) defines how to determine the default base IRI of a document. Informatively, the initial base IRI of a schema is the IRI at which it was @@ -1095,12 +1095,12 @@ found, whether that was a network location, a local filesystem, or any other situation identifiable by a IRI of any known scheme. If a schema document defines no explicit base IRI with `$id` (embedded in -content), the base IRI is that determined per [RFC 3987 Section 6.5](https://www.rfc-editor.org/info/rfc3987) -and [RFC 3986 section 5](https://www.rfc-editor.org/info/rfc3986). +content), the base IRI is that determined per [RFC 3987 Section 6.5](https://www.rfc-editor.org/rfc/rfc3987.html#section-6.5) +and [RFC 3986 section 5](https://www.rfc-editor.org/rfc/rfc3986.html#section-5). If no source is known, or no IRI scheme is known for the source, a suitable implementation-specific default IRI MAY be used as described in [RFC 3987 -Section 6.5](https://www.rfc-editor.org/info/rfc3987) and [RFC 3986 Section 5.1.4](https://www.rfc-editor.org/info/rfc3986). It is RECOMMENDED +Section 6.5](https://www.rfc-editor.org/rfc/rfc3987.html#section-6.5) and [RFC 3986 Section 5.1.4](https://www.rfc-editor.org/rfc/rfc3986.html#section-5.1.4). It is RECOMMENDED that implementations document any default base IRI that they assume. If a schema object is embedded in a document of another media type, then the @@ -1430,7 +1430,7 @@ linking](https://www.rfc-editor.org/info/rfc8288). It is RECOMMENDED that instances described by a schema provide a link to a downloadable JSON Schema using the link relation "describedby", as defined by -[Linked Data Protocol 1.0, section 8.1](https://www.w3.org/TR/2015/REC-ldp-20150226). +[Linked Data Protocol 1.0, section 8.1](https://www.w3.org/TR/2015/REC-ldp-20150226/#link-relation-describedby). In HTTP, such links can be attached to any response using the [Link header](https://www.rfc-editor.org/info/rfc8288). An example of such a header would be: From a3ba78a8086c05ad9c04e8b09459000e18be454b Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 10 Jan 2025 17:56:09 +1300 Subject: [PATCH 710/780] use reference style links for repeated urls --- specs/jsonschema-core.md | 48 ++++++++++++++++++++++------------------ 1 file changed, 27 insertions(+), 21 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index cb19cb03..83bcf59f 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -43,7 +43,7 @@ interpreted as described in [RFC 2119](https://www.rfc-editor.org/info/rfc2119). The terms "JSON", "JSON text", "JSON value", "member", "element", "object", "array", "number", "string", "boolean", "true", "false", and "null" in this -document are to be interpreted as defined in [RFC 8259](https://www.rfc-editor.org/info/rfc8259). +document are to be interpreted as defined in [RFC 8259][RFC8259]. ## Overview @@ -296,7 +296,7 @@ identifier structures: plain names and JSON Pointers. The structure: JSON Pointers. The use of JSON Pointers as IRI fragment identifiers is described in [RFC -6901](https://www.rfc-editor.org/info/rfc6901). For `application/schema+json`, which supports two fragment +6901][RFC6901]. For `application/schema+json`, which supports two fragment identifier syntaxes, fragment identifiers matching the JSON Pointer syntax, including the empty string, MUST be interpreted as JSON Pointer fragment identifiers. @@ -336,7 +336,7 @@ keyword](#anchors) section. ### Range of JSON Values -An instance may be any valid JSON value as defined by [JSON](https://www.rfc-editor.org/info/rfc8259). JSON +An instance may be any valid JSON value as defined by [JSON][RFC8259]. JSON Schema imposes no restrictions on type: JSON Schema can describe any JSON value, including, for example, null. @@ -367,7 +367,7 @@ schema authors SHOULD limit themselves to the following regular expression tokens: - individual Unicode characters, as defined by the [JSON - specification](https://www.rfc-editor.org/info/rfc8259); + specification][RFC8259]; - simple atoms: `.` (any character except line terminator); - simple character classes (`[abc]`), range character classes (`[a-z]`); - complemented simple character classes (`[^abc]`); @@ -899,9 +899,9 @@ To differentiate between schemas in a vast ecosystem, schema resources are identified by [absolute IRIs](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2) (without fragments). These identifiers are used to create references between schema resources. When comparing IRIs for the purposes of resource identification, implementations SHOULD first follow the -IRI normalization procedures defined in [RFC 3987](https://www.rfc-editor.org/info/rfc3987), section 5.3. +IRI normalization procedures defined in [RFC 3987][RFC3987], section 5.3. -Several keywords can accept a relative [IRI reference](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2), or a value +Several keywords can accept a relative IRI reference, or a value used to construct a relative IRI reference. For these keywords, it is necessary to establish a base IRI in order to resolve the reference. @@ -909,7 +909,7 @@ to establish a base IRI in order to resolve the reference. An `$id` keyword in a schema or subschema identifies that schema or subschema as a distinct schema resource. The value for this keyword MUST be a string, and -MUST represent a valid [IRI reference](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2) without a fragment. +MUST represent a valid IRI reference without a fragment. When the value of this keyword is resolved against the current base IRI, the resulting absolute IRI then serves as the identifier for the schema resource and @@ -951,8 +951,8 @@ fragments, rather than absolute IRIs as seen with `$id`. keyword is appended to the IRI of the schema resource containing it. As discussed in {{id-keyword}}, this is either the nearest `$id` in the same or an ancestor schema object, or the base IRI for the document as determined according -to [RFC 3987](https://www.rfc-editor.org/info/rfc3987) and -[RFC 3986](https://www.rfc-editor.org/info/rfc3986). +to [RFC 3987][RFC3987] and +[RFC 3986][RFC3986]. In contrast, `$dynamicAnchor` operates independently of resource IRIs and is instead dependent on the dynamic scope of the evaluation. `$dynamicAnchor` @@ -1095,13 +1095,13 @@ found, whether that was a network location, a local filesystem, or any other situation identifiable by a IRI of any known scheme. If a schema document defines no explicit base IRI with `$id` (embedded in -content), the base IRI is that determined per [RFC 3987 Section 6.5](https://www.rfc-editor.org/rfc/rfc3987.html#section-6.5) -and [RFC 3986 section 5](https://www.rfc-editor.org/rfc/rfc3986.html#section-5). +content), the base IRI is that determined per RFC 3987 Section 6.5 +and RFC 3986 section 5. If no source is known, or no IRI scheme is known for the source, a suitable -implementation-specific default IRI MAY be used as described in [RFC 3987 -Section 6.5](https://www.rfc-editor.org/rfc/rfc3987.html#section-6.5) and [RFC 3986 Section 5.1.4](https://www.rfc-editor.org/rfc/rfc3986.html#section-5.1.4). It is RECOMMENDED -that implementations document any default base IRI that they assume. +implementation-specific default IRI MAY be used as described in RFC 3987 Section +6.5 and RFC 3986 Section 5.1.4. It is RECOMMENDED that implementations document +any default base IRI that they assume. If a schema object is embedded in a document of another media type, then the initial base IRI is determined according to the rules of that media type. @@ -1152,7 +1152,7 @@ expect such features to be interoperable across implementations. Schemas can be identified by any IRI that has been given to them, including a JSON Pointer or their IRI given directly by `$id`. In all cases, dereferencing a `$ref` reference involves first resolving its value as a IRI reference against -the current base IRI per [RFC 3986](https://www.rfc-editor.org/info/rfc3986). +the current base IRI per [RFC 3986][RFC3986]. If the resulting IRI identifies a schema within the current document, or within another schema document that has been made available to the implementation, then @@ -1424,7 +1424,7 @@ all annotation results), would result in a resolution failure. JSON has been adopted widely by HTTP servers for automated APIs and robots. This section describes how to enhance processing of JSON documents in a more RESTful manner when used with protocols that support media types and [Web -linking](https://www.rfc-editor.org/info/rfc8288). +linking][RFC8288]. ##### Linking to a Schema @@ -1433,7 +1433,7 @@ downloadable JSON Schema using the link relation "describedby", as defined by [Linked Data Protocol 1.0, section 8.1](https://www.w3.org/TR/2015/REC-ldp-20150226/#link-relation-describedby). In HTTP, such links can be attached to any response using the [Link -header](https://www.rfc-editor.org/info/rfc8288). An example of such a header would be: +header][RFC8288]. An example of such a header would be: ``` Link: ; rel="describedby" @@ -1955,7 +1955,7 @@ SHOULD use the terms defined by this document to do so. ## Security Considerations {#security} Both schemas and instances are JSON values. As such, all security considerations -defined in [RFC 8259](https://www.rfc-editor.org/info/rfc8259) apply. +defined in [RFC 8259][RFC8259] apply. Instances and schemas are both frequently written by untrusted third parties, to be deployed on public Internet servers. Implementations should take care that @@ -1994,7 +1994,7 @@ Subtype name:: schema+json Required parameters:: N/A Encoding considerations:: Encoding considerations are identical to those -specified for the `application/json` media type. See [JSON](https://www.rfc-editor.org/info/rfc8259). +specified for the `application/json` media type. See [JSON][RFC8259]. Security considerations:: See {{security}} above. @@ -2015,7 +2015,7 @@ Subtype name:: schema-instance+json Required parameters:: N/A Encoding considerations:: Encoding considerations are identical to those -specified for the `application/json` media type. See [JSON](https://www.rfc-editor.org/info/rfc8259). +specified for the `application/json` media type. See [JSON][RFC8259]. Security considerations:: See {{security}} above. @@ -2053,7 +2053,7 @@ name fragment identifiers. ``` The schemas at the following locations (indicated by plain -[JSON Pointers](https://www.rfc-editor.org/info/rfc6901) relative to the root document) have the following base +[JSON Pointers][RFC6901] relative to the root document) have the following base IRIs, and are identifiable by any listed IRI in accordance with {{fragments}} and {{embedded}} above. @@ -2491,3 +2491,9 @@ to the document. | Greg Dennis | | | | [^19]: This section to be removed before leaving Internet-Draft status. + +[RFC3986]: https://www.rfc-editor.org/info/rfc3986 +[RFC3987]: https://www.rfc-editor.org/info/rfc3987 +[RFC6901]: https://www.rfc-editor.org/info/rfc6901 +[RFC8259]: https://www.rfc-editor.org/info/rfc8259 +[RFC8288]: https://www.rfc-editor.org/info/rfc8288 From f548fbaf2b8a4ec142d63b8dd9f3a367daece60c Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 11 Jan 2025 08:16:39 +1300 Subject: [PATCH 711/780] use internal links on validation; markdown line length cleanup --- specs/jsonschema-core.md | 104 +++++++++-------- specs/jsonschema-validation.md | 198 +++++++-------------------------- 2 files changed, 99 insertions(+), 203 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 83bcf59f..57dc376e 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -242,12 +242,15 @@ are using. #### Root Schema and Subschemas and Resources {#root} -A JSON Schema resource is a schema which is [canonically](https://www.rfc-editor.org/info/rfc6596) identified -by an [absolute IRI](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2). Schema resources MAY also be identified by IRIs, -including IRIs with fragments, if the resulting secondary resource (as defined -by [section 3.5 of RFC 3986](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.5)) is identical to the primary resource. -This can occur with the empty fragment, or when one schema resource is embedded -in another. Any such IRIs with fragments are considered to be non-canonical. +A JSON Schema resource is a schema which is +[canonically](https://www.rfc-editor.org/info/rfc6596) identified by an +[absolute IRI](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2). Schema +resources MAY also be identified by IRIs, including IRIs with fragments, if the +resulting secondary resource (as defined by +[section 3.5 of RFC 3986](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.5)) +is identical to the primary resource. This can occur with the empty fragment, or +when one schema resource is embedded in another. Any such IRIs with fragments +are considered to be non-canonical. The root schema is the schema that comprises the entire JSON document in question. The root schema is always a schema resource, where the IRI is @@ -285,10 +288,12 @@ are processed in the same way, with the same available behaviors. ## Fragment Identifiers {#fragments} -In accordance with [section 3.1 of RFC 6839](https://www.rfc-editor.org/rfc/rfc6839.html#section-3.1), the syntax and semantics -of fragment identifiers specified for any +json media type SHOULD be as -specified for `application/json`. (At publication of this document, there is no -fragment identification syntax defined for `application/json`.) +In accordance with +[section 3.1 of RFC 6839](https://www.rfc-editor.org/rfc/rfc6839.html#section-3.1), +the syntax and semantics of fragment identifiers specified for any +json media +type SHOULD be as specified for `application/json`. (At publication of this +document, there is no fragment identification syntax defined for +`application/json`.) Additionally, the `application/schema+json` media type supports two fragment identifier structures: plain names and JSON Pointers. The @@ -301,16 +306,17 @@ identifier syntaxes, fragment identifiers matching the JSON Pointer syntax, including the empty string, MUST be interpreted as JSON Pointer fragment identifiers. -Per the W3C's [best practices for fragment -identifiers](#w3cwd-fragid-best-practices-20121025), plain name fragment -identifiers in `application/schema+json` are reserved for referencing locally -named schemas. +Per the W3C's +[best practices for fragment identifiers](https://www.w3.org/TR/2012/WD-fragid-best-practices-20121025), +plain name fragment identifiers in `application/schema+json` are reserved for +referencing locally named schemas. -Plain name fragments MUST follow XML's [`NCName` production](https://www.w3.org/TR/2006/REC-xml-names11-20060816/#NT-NCName), which -allows for compatibility with the recommended [plain name -syntax](https://www.w3.org/TR/2003/REC-xptr-framework-20030325/) for XML-based media types. For -convenience, the `NCName` syntax is reproduced here in ABNF form, using -a minimal set of rules: +Plain name fragments MUST follow XML's +[`NCName` production](https://www.w3.org/TR/2006/REC-xml-names11-20060816/#NT-NCName), +which allows for compatibility with the recommended [plain name +syntax](https://www.w3.org/TR/2003/REC-xptr-framework-20030325/) for XML-based +media types. For convenience, the `NCName` syntax is reproduced here in ABNF +form, using a minimal set of rules: ```abnf NCName = NCNameStartChar *NCNameChar @@ -653,8 +659,9 @@ behalf of applications. Unless otherwise specified, the value of an annotation keyword is the keyword's value. However, other behaviors are possible. For example, [JSON -Hyper-Schema's](https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-hyperschema-02) `links` keyword is a complex annotation that -produces a value based in part on the instance data. +Hyper-Schema's](https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-hyperschema-02) +`links` keyword is a complex annotation that produces a value based in part on +the instance data. While "short-circuit" evaluation is possible for assertions, collecting annotations requires examining all schemas that apply to an instance location, @@ -880,8 +887,9 @@ applies to the resource in which it is declared as well as any embedded schema resources, unless such a resource itself declares a different dialect by including the `$schema` keyword with a different value. -The value of this keyword MUST be an [IRI](https://www.rfc-editor.org/info/rfc3987) (containing a scheme) and -this IRI MUST be normalized. +The value of this keyword MUST be an +[IRI](https://www.rfc-editor.org/info/rfc3987) (containing a scheme) and this +IRI MUST be normalized. If this IRI identifies a retrievable resource, that resource SHOULD be of media type `application/schema+json`. @@ -896,10 +904,12 @@ by other parties. ### Base IRI, Anchors, and Dereferencing To differentiate between schemas in a vast ecosystem, schema resources are -identified by [absolute IRIs](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2) (without fragments). These identifiers -are used to create references between schema resources. When comparing IRIs for -the purposes of resource identification, implementations SHOULD first follow the -IRI normalization procedures defined in [RFC 3987][RFC3987], section 5.3. +identified by +[absolute IRIs](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2) +(without fragments). These identifiers are used to create references between +schema resources. When comparing IRIs for the purposes of resource +identification, implementations SHOULD first follow the IRI normalization +procedures defined in [RFC 3987][RFC3987], section 5.3. Several keywords can accept a relative IRI reference, or a value used to construct a relative IRI reference. For these keywords, it is necessary @@ -915,8 +925,10 @@ When the value of this keyword is resolved against the current base IRI, the resulting absolute IRI then serves as the identifier for the schema resource and as a base IRI for relative IRI references in keywords within that schema resource and for embedded schema resources, in accordance with [RFC 3987 section -6.5](https://www.rfc-editor.org/rfc/rfc3987.html#section-6.5) and [RFC 3986 section 5.1.1](https://www.rfc-editor.org/rfc/rfc3986.html#section-5.1.1) regarding base IRIs -embedded in content and RFC 3986 section 5.1.2 regarding encapsulating entities. +6.5](https://www.rfc-editor.org/rfc/rfc3987.html#section-6.5) and +[RFC 3986 section 5.1.1](https://www.rfc-editor.org/rfc/rfc3986.html#section-5.1.1) +regarding base IRIs embedded in content and RFC 3986 section 5.1.2 regarding +encapsulating entities. Note that this IRI is an identifier and not necessarily a network locator. In the case of a network-addressable URL, a schema need not be downloadable from @@ -933,7 +945,8 @@ given in {{initial-base}}. ##### Identifying the root schema The root schema of a JSON Schema document SHOULD contain an `$id` keyword with -an [absolute IRI](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2) (containing a scheme, but no fragment). +an [absolute IRI](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2) +(containing a scheme, but no fragment). #### Defining location-independent identifiers {#anchors} @@ -999,10 +1012,10 @@ Resolved against the current IRI base, it produces the IRI of the schema to apply. This resolution is safe to perform on schema load, as the process of evaluating an instance cannot change how the reference resolves. -The resolved IRI produced by `$ref` is not necessarily a network -locator, only an identifier. A schema need not be downloadable from the address -if it is a network-addressable URL. Implementations which can access the network -SHOULD default to operating offline. +The resolved IRI produced by `$ref` is not necessarily a network locator, only +an identifier. A schema need not be downloadable from the address if it is a +network-addressable URL. Implementations which can access the network SHOULD +default to operating offline. ##### Dynamic References with `$dynamicRef` {#dynamic-ref} @@ -1087,8 +1100,10 @@ MUST NOT be collected as an annotation result. #### Initial Base IRI {#initial-base} -[RFC 3987 Section 6.5](https://www.rfc-editor.org/rfc/rfc3987.html#section-6.5) and [RFC 3986 Section 5.1](https://www.rfc-editor.org/rfc/rfc3986.html#section-5.1) defines -how to determine the default base IRI of a document. +[RFC 3987 Section 6.5](https://www.rfc-editor.org/rfc/rfc3987.html#section-6.5) +and +[RFC 3986 Section 5.1](https://www.rfc-editor.org/rfc/rfc3986.html#section-5.1) +defines how to determine the default base IRI of a document. Informatively, the initial base IRI of a schema is the IRI at which it was found, whether that was a network location, a local filesystem, or any other @@ -1441,11 +1456,12 @@ Link: ; rel="describedby" ##### Usage Over HTTP -When used for hypermedia systems over a network, [HTTP](https://www.rfc-editor.org/info/rfc7231) is frequently -the protocol of choice for distributing schemas. Misbehaving clients can pose -problems for server maintainers if they pull a schema over the network more -frequently than necessary, when it's instead possible to cache a schema for a -long period of time. +When used for hypermedia systems over a network, +[HTTP](https://www.rfc-editor.org/info/rfc7231) is frequently the protocol of +choice for distributing schemas. Misbehaving clients can pose problems for +server maintainers if they pull a schema over the network more frequently than +necessary, when it's instead possible to cache a schema for a long period of +time. HTTP servers SHOULD set long-lived caching headers on JSON Schemas. HTTP clients SHOULD observe caching headers and not re-request documents within their @@ -1846,9 +1862,9 @@ property values. The behavior of this keyword depends on all adjacent keywords as well as keywords in successfully validated subschemas that apply to the same instance -location by evaluating the instance's property values. This includes, but is not limited -to, `properties`, `patternProperties`, and `additionalProperties`, itself, and -all [in-place applicators](#in-place) defined in this document. +location by evaluating the instance's property values. This includes, but is not +limited to, `properties`, `patternProperties`, and `additionalProperties`, +itself, and all [in-place applicators](#in-place) defined in this document. This keyword applies its subschema to any property values which have not been deemed "evaluated" per {{unevaluated}}. Validation passes if the keyword's diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 8af76d89..6cca48e1 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -192,7 +192,7 @@ A string instance is valid against this keyword if its length is less than, or equal to, the value of this keyword. The length of a string instance is defined as the number of its characters as -defined by [RFC 8259](https://www.rfc-editor.org/info/rfc8259). +defined by [RFC 8259][RFC 8259]. #### `minLength` @@ -202,7 +202,7 @@ A string instance is valid against this keyword if its length is greater than, or equal to, the value of this keyword. The length of a string instance is defined as the number of its characters as -defined by [RFC 8259](https://www.rfc-editor.org/info/rfc8259). +defined by [RFC 8259][RFC 8259]. Omitting this keyword has the same behavior as a value of 0. @@ -388,8 +388,9 @@ email address as follows: - *email:* As defined by the "Mailbox" ABNF rule in [RFC 5321, section 4.1.2](https://www.rfc-editor.org/info/rfc5321). - *idn-email:* As defined by the extended "Mailbox" ABNF rule in [RFC 6531, - section 3.3](https://www.rfc-editor.org/info/rfc6531). Note that all strings valid against the "email" - attribute are also valid against the "idn-email" attribute. + section 3.3](https://www.rfc-editor.org/info/rfc6531). Note that all strings + valid against the "email" attribute are also valid against the "idn-email" + attribute. #### Hostnames @@ -398,13 +399,15 @@ These attributes apply to string instances. A string instance is valid against these attributes if it is a valid representation for an Internet hostname as follows: -- *hostname:* As defined by [RFC 1123, section 2.1](https://www.rfc-editor.org/info/rfc1123), including host - names produced using the Punycode algorithm specified in [RFC 5891, section - 4.4](https://www.rfc-editor.org/info/rfc5891). +- *hostname:* As defined by + [RFC 1123, section 2.1](https://www.rfc-editor.org/info/rfc1123), including + host names produced using the Punycode algorithm specified in [RFC 5891, + section 4.4](https://www.rfc-editor.org/info/rfc5891). - *idn-hostname:* As defined by either RFC 1123 as for hostname, or an internationalized hostname as defined by [RFC 5890, section - 2.3.2.3](https://www.rfc-editor.org/info/rfc5890). Note that all strings valid against the "hostname" - attribute are also valid against the "idn-hostname" attribute. + 2.3.2.3](https://www.rfc-editor.org/info/rfc5890). Note that all strings valid + against the "hostname" attribute are also valid against the "idn-hostname" + attribute. #### IP Addresses @@ -415,22 +418,24 @@ representation of an IP address as follows: - *ipv4:* An IPv4 address according to the "dotted-quad" ABNF syntax as defined in [RFC 2673, section 3.2](https://www.rfc-editor.org/info/rfc2673). -- *ipv6:* An IPv6 address as defined in [RFC 4291, section 2.2](https://www.rfc-editor.org/info/rfc4291). +- *ipv6:* An IPv6 address as defined in + [RFC 4291, section 2.2](https://www.rfc-editor.org/info/rfc4291). #### Resource Identifiers These attributes apply to string instances. - *uri:* A string instance is valid against this attribute if it is a valid IRI, - according to [RFC3987](https://www.rfc-editor.org/info/rfc3987). + according to [RFC 3987][RFC3987]. - *uri-reference:* A string instance is valid against this attribute if it is a valid URI Reference (either a URI or a relative-reference), according to - [RFC3986](https://www.rfc-editor.org/info/rfc3986). + [RFC 3986](https://www.rfc-editor.org/info/rfc3986). - *iri:* A string instance is valid against this attribute if it is a valid IRI, - according to [RFC3987](https://www.rfc-editor.org/info/rfc3987). + according to [RFC 3987][RFC3987]. - *iri-reference:* A string instance is valid against this attribute if it is a valid IRI Reference (either an IRI or a relative-reference), according to - [RFC3987](https://www.rfc-editor.org/info/rfc3987). + [RFC 3987][RFC3987]. - *uuid:* A string instance is valid against this attribute if it is a valid - string representation of a UUID, according to [RFC4122](https://www.rfc-editor.org/info/rfc4122). + string representation of a UUID, according to + [RFC 4122](https://www.rfc-editor.org/info/rfc4122). Note that all valid URIs are valid IRIs, and all valid URI References are also valid IRI References. @@ -445,7 +450,8 @@ the URI scheme and URN namespace. This attribute applies to string instances. A string instance is valid against this attribute if it is a valid URI Template -(of any level), according to [RFC6570](https://www.rfc-editor.org/info/rfc6570). +(of any level), according to +[RFC 6570](https://www.rfc-editor.org/info/rfc6570). Note that URI Templates may be used for IRIs; there is no separate IRI Template specification. @@ -458,16 +464,18 @@ These attributes apply to string instances. valid JSON string representation of a JSON Pointer, according to [RFC 6901, section 5](https://www.rfc-editor.org/info/rfc6901). - *relative-json-pointer:* A string instance is valid against this attribute if - it is a valid [Relative JSON Pointer](https://datatracker.ietf.org/doc/html/draft-handrews-relative-json-pointer-01). To allow for - both absolute and relative JSON Pointers, use `anyOf` or `oneOf` to indicate - support for either format. + it is a valid + [Relative JSON Pointer](https://datatracker.ietf.org/doc/html/draft-handrews-relative-json-pointer-01). + To allow for both absolute and relative JSON Pointers, use `anyOf` or `oneOf` + to indicate support for either format. #### regex This attribute applies to string instances. A regular expression, which SHOULD be valid according to the -[ECMA-262](https://www.ecma-international.org/ecma-262/11.0/index.html) regular expression dialect. +[ECMA-262](https://www.ecma-international.org/ecma-262/11.0/index.html) regular +expression dialect. Implementations that validate formats MUST accept at least the subset of ECMA-262 defined in {{regexinterop}}, and SHOULD accept all valid ECMA-262 @@ -503,12 +511,13 @@ be interpreted as encoded binary data and applications wishing to decode it SHOULD do so using the encoding named by this property. Possible values indicating base 16, 32, and 64 encodings with several variations -are listed in [RFC 4648](https://www.rfc-editor.org/info/rfc4648). Additionally, sections 6.7 and 6.8 of [RFC -2045](https://www.rfc-editor.org/info/rfc2045) provide encodings used in MIME. This keyword is derived from -MIME's Content-Transfer-Encoding header, which was designed to map binary data -into ASCII characters. It is not related to HTTP's Content-Encoding header, -which is used to encode (e.g. compress or encrypt) the content of HTTP request -and responses. +are listed in [RFC 4648](https://www.rfc-editor.org/info/rfc4648). Additionally, +sections 6.7 and 6.8 of [RFC 2045](https://www.rfc-editor.org/info/rfc2045) +provide encodings used in MIME. This keyword is derived from MIME's +Content-Transfer-Encoding header, which was designed to map binary data into +ASCII characters. It is not related to HTTP's Content-Encoding header, which is +used to encode (e.g. compress or encrypt) the content of HTTP request and +responses. As "base64" is defined in both RFCs, the definition from RFC 4648 SHOULD be assumed unless the string is specifically intended for use in a MIME context. @@ -574,7 +583,7 @@ Another example: Instances described by this schema are expected to be strings containing HTML, using whatever character set the JSON string was decoded into. Per section 8.1 -of [RFC 8259](https://www.rfc-editor.org/info/rfc8259), outside of an entirely closed system, this MUST be +of [RFC 8259][RFC 8259], outside of an entirely closed system, this MUST be UTF-8. This example describes a JWT that is MACed using the HMAC SHA-256 algorithm, and @@ -735,138 +744,6 @@ that media type or encoding. For example, the security considerations of [RFC 4329 Scripting Media Types](https://www.rfc-editor.org/info/rfc4329) apply when processing JavaScript or ECMAScript encoded within a JSON string. -## References - -### Normative References - -#### [RFC2119] {https://www.rfc-editor.org/info/rfc2119} - -Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, -RFC 2119, DOI 10.17487/RFC2119, March 1997, -<>. - -#### [RFC1123] {https://www.rfc-editor.org/info/rfc1123} - -Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", -STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, -<>. - -#### [RFC2045] {https://www.rfc-editor.org/info/rfc2045} - -Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part -One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, -November 1996, <>. - -#### [RFC2046] {https://www.rfc-editor.org/info/rfc2046} - -Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part -Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, -<>. - -#### [RFC2673] {https://www.rfc-editor.org/info/rfc2673} - -Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, DOI -10.17487/RFC2673, August 1999, <>. - -#### [RFC3339] {https://www.rfc-editor.org/info/rfc3339} - -Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, -DOI 10.17487/RFC3339, July 2002, <>. - -#### [RFC3986] {https://www.rfc-editor.org/info/rfc3986} - -Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier -(URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, -<>. - -#### [RFC3987] {https://www.rfc-editor.org/info/rfc3987} - -Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC -3987, DOI 10.17487/RFC3987, January 2005, -<>. - -#### [RFC4122] {https://www.rfc-editor.org/info/rfc4122} - -Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) -URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, -<>. - -#### [RFC4291] {https://www.rfc-editor.org/info/rfc4291} - -Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI -10.17487/RFC4291, February 2006, <>. - -#### [RFC4648] {https://www.rfc-editor.org/info/rfc4648} - -Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI -10.17487/RFC4648, October 2006, <>. - -#### [RFC5321] {https://www.rfc-editor.org/info/rfc5321} - -Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, -October 2008, <>. - -#### [RFC5890] {https://www.rfc-editor.org/info/rfc5890} - -Klensin, J., "Internationalized Domain Names for Applications (IDNA): -Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August -2010, <>. - -#### [RFC5891] {https://www.rfc-editor.org/info/rfc5891} - -Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", -RFC 5891, DOI 10.17487/RFC5891, August 2010, -<>. - -#### [RFC6570] {https://www.rfc-editor.org/info/rfc6570} - -Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI -Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, -<>. - -#### [RFC6531] {https://www.rfc-editor.org/info/rfc6531} - -Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI -10.17487/RFC6531, February 2012, <>. - -#### [RFC6901] {https://www.rfc-editor.org/info/rfc6901} - -Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation -(JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, -<>. - -#### [RFC8259] {https://www.rfc-editor.org/info/rfc8259} - -Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", -STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, -<>. - -#### [ecma262] {https://www.ecma-international.org/ecma-262/11.0/index.html} - -ECMA-262, 11th edition specification", June 2020, -<>. - -#### [relative-json-pointer] {https://datatracker.ietf.org/doc/html/draft-handrews-relative-json-pointer-01} - -Luff, G., Andrews, H., and B. Hutton, Ed., "Relative JSON Pointers", Work in -Progress, Internet-Draft, draft-handrews-relative-json-pointer-01, December -2020, -<>. - -#### [json-schema] {./jsonschema-core} - -Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON Schema: A Media Type -for Describing JSON Documents", Work in Progress, Internet-Draft, -draft-bhutton-json-schema-01, June 2022, -<>. - -### Informative References - -#### \[RFC4329\] {https://www.rfc-editor.org/info/rfc4329} - -Hoehrmann, B., "Scripting Media Types", RFC 4329, DOI 10.17487/RFC4329, April -2006, <>. - ## %appendix% Acknowledgments Thanks to Gary Court, Francis Galiegue, Kris Zyp, Geraint Luff, and Henry @@ -981,3 +858,6 @@ to the document. | Ben Hutton (*editor*) | Postman | | | [^6]: This section to be removed before leaving Internet-Draft status. + +[RFC3987]: https://www.rfc-editor.org/info/rfc3987 +[RFC8259]: https://www.rfc-editor.org/info/rfc8259 \ No newline at end of file From f8c323ed9d931d28f2c28f07d96bfa90f50b7ce9 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 11 Jan 2025 08:23:33 +1300 Subject: [PATCH 712/780] use lowercase labels --- specs/jsonschema-core.md | 38 +++++++++++++++++----------------- specs/jsonschema-validation.md | 20 +++++++++--------- 2 files changed, 29 insertions(+), 29 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 57dc376e..d07bae2d 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -43,7 +43,7 @@ interpreted as described in [RFC 2119](https://www.rfc-editor.org/info/rfc2119). The terms "JSON", "JSON text", "JSON value", "member", "element", "object", "array", "number", "string", "boolean", "true", "false", and "null" in this -document are to be interpreted as defined in [RFC 8259][RFC8259]. +document are to be interpreted as defined in [RFC 8259][rfc8259]. ## Overview @@ -301,7 +301,7 @@ identifier structures: plain names and JSON Pointers. The structure: JSON Pointers. The use of JSON Pointers as IRI fragment identifiers is described in [RFC -6901][RFC6901]. For `application/schema+json`, which supports two fragment +6901][rfc6901]. For `application/schema+json`, which supports two fragment identifier syntaxes, fragment identifiers matching the JSON Pointer syntax, including the empty string, MUST be interpreted as JSON Pointer fragment identifiers. @@ -342,7 +342,7 @@ keyword](#anchors) section. ### Range of JSON Values -An instance may be any valid JSON value as defined by [JSON][RFC8259]. JSON +An instance may be any valid JSON value as defined by [JSON][rfc8259]. JSON Schema imposes no restrictions on type: JSON Schema can describe any JSON value, including, for example, null. @@ -373,7 +373,7 @@ schema authors SHOULD limit themselves to the following regular expression tokens: - individual Unicode characters, as defined by the [JSON - specification][RFC8259]; + specification][rfc8259]; - simple atoms: `.` (any character except line terminator); - simple character classes (`[abc]`), range character classes (`[a-z]`); - complemented simple character classes (`[^abc]`); @@ -909,7 +909,7 @@ identified by (without fragments). These identifiers are used to create references between schema resources. When comparing IRIs for the purposes of resource identification, implementations SHOULD first follow the IRI normalization -procedures defined in [RFC 3987][RFC3987], section 5.3. +procedures defined in [RFC 3987][rfc3987], section 5.3. Several keywords can accept a relative IRI reference, or a value used to construct a relative IRI reference. For these keywords, it is necessary @@ -964,8 +964,8 @@ fragments, rather than absolute IRIs as seen with `$id`. keyword is appended to the IRI of the schema resource containing it. As discussed in {{id-keyword}}, this is either the nearest `$id` in the same or an ancestor schema object, or the base IRI for the document as determined according -to [RFC 3987][RFC3987] and -[RFC 3986][RFC3986]. +to [RFC 3987][rfc3987] and +[RFC 3986][rfc3986]. In contrast, `$dynamicAnchor` operates independently of resource IRIs and is instead dependent on the dynamic scope of the evaluation. `$dynamicAnchor` @@ -1167,7 +1167,7 @@ expect such features to be interoperable across implementations. Schemas can be identified by any IRI that has been given to them, including a JSON Pointer or their IRI given directly by `$id`. In all cases, dereferencing a `$ref` reference involves first resolving its value as a IRI reference against -the current base IRI per [RFC 3986][RFC3986]. +the current base IRI per [RFC 3986][rfc3986]. If the resulting IRI identifies a schema within the current document, or within another schema document that has been made available to the implementation, then @@ -1439,7 +1439,7 @@ all annotation results), would result in a resolution failure. JSON has been adopted widely by HTTP servers for automated APIs and robots. This section describes how to enhance processing of JSON documents in a more RESTful manner when used with protocols that support media types and [Web -linking][RFC8288]. +linking][rfc8288]. ##### Linking to a Schema @@ -1448,7 +1448,7 @@ downloadable JSON Schema using the link relation "describedby", as defined by [Linked Data Protocol 1.0, section 8.1](https://www.w3.org/TR/2015/REC-ldp-20150226/#link-relation-describedby). In HTTP, such links can be attached to any response using the [Link -header][RFC8288]. An example of such a header would be: +header][rfc8288]. An example of such a header would be: ``` Link: ; rel="describedby" @@ -1971,7 +1971,7 @@ SHOULD use the terms defined by this document to do so. ## Security Considerations {#security} Both schemas and instances are JSON values. As such, all security considerations -defined in [RFC 8259][RFC8259] apply. +defined in [RFC 8259][rfc8259] apply. Instances and schemas are both frequently written by untrusted third parties, to be deployed on public Internet servers. Implementations should take care that @@ -2010,7 +2010,7 @@ Subtype name:: schema+json Required parameters:: N/A Encoding considerations:: Encoding considerations are identical to those -specified for the `application/json` media type. See [JSON][RFC8259]. +specified for the `application/json` media type. See [JSON][rfc8259]. Security considerations:: See {{security}} above. @@ -2031,7 +2031,7 @@ Subtype name:: schema-instance+json Required parameters:: N/A Encoding considerations:: Encoding considerations are identical to those -specified for the `application/json` media type. See [JSON][RFC8259]. +specified for the `application/json` media type. See [JSON][rfc8259]. Security considerations:: See {{security}} above. @@ -2069,7 +2069,7 @@ name fragment identifiers. ``` The schemas at the following locations (indicated by plain -[JSON Pointers][RFC6901] relative to the root document) have the following base +[JSON Pointers][rfc6901] relative to the root document) have the following base IRIs, and are identifiable by any listed IRI in accordance with {{fragments}} and {{embedded}} above. @@ -2508,8 +2508,8 @@ to the document. [^19]: This section to be removed before leaving Internet-Draft status. -[RFC3986]: https://www.rfc-editor.org/info/rfc3986 -[RFC3987]: https://www.rfc-editor.org/info/rfc3987 -[RFC6901]: https://www.rfc-editor.org/info/rfc6901 -[RFC8259]: https://www.rfc-editor.org/info/rfc8259 -[RFC8288]: https://www.rfc-editor.org/info/rfc8288 +[rfc3986]: https://www.rfc-editor.org/info/rfc3986 +[rfc3987]: https://www.rfc-editor.org/info/rfc3987 +[rfc6901]: https://www.rfc-editor.org/info/rfc6901 +[rfc8259]: https://www.rfc-editor.org/info/rfc8259 +[rfc8288]: https://www.rfc-editor.org/info/rfc8288 diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 6cca48e1..82a99228 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -354,9 +354,9 @@ custom format values. These attributes apply to string instances. -Date and time format names are derived from [RFC 3339, section 5.6](https://www.rfc-editor.org/info/rfc3339). -The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC -3339. +Date and time format names are derived from +[RFC 3339, section 5.6](https://www.rfc-editor.org/info/rfc3339). The duration +format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339. - *date-time*: A string instance is valid against this attribute if it is a valid representation according to the "date-time" ABNF rule (referenced above) @@ -424,15 +424,15 @@ representation of an IP address as follows: #### Resource Identifiers These attributes apply to string instances. - *uri:* A string instance is valid against this attribute if it is a valid IRI, - according to [RFC 3987][RFC3987]. + according to [RFC 3987][rfc3987]. - *uri-reference:* A string instance is valid against this attribute if it is a valid URI Reference (either a URI or a relative-reference), according to [RFC 3986](https://www.rfc-editor.org/info/rfc3986). - *iri:* A string instance is valid against this attribute if it is a valid IRI, - according to [RFC 3987][RFC3987]. + according to [RFC 3987][rfc3987]. - *iri-reference:* A string instance is valid against this attribute if it is a valid IRI Reference (either an IRI or a relative-reference), according to - [RFC 3987][RFC3987]. + [RFC 3987][rfc3987]. - *uuid:* A string instance is valid against this attribute if it is a valid string representation of a UUID, according to [RFC 4122](https://www.rfc-editor.org/info/rfc4122). @@ -741,8 +741,8 @@ authority). Processing a media type or encoding is subject to the security considerations of that media type or encoding. For example, the security considerations of [RFC -4329 Scripting Media Types](https://www.rfc-editor.org/info/rfc4329) apply when processing JavaScript or -ECMAScript encoded within a JSON string. +4329 Scripting Media Types](https://www.rfc-editor.org/info/rfc4329) apply when +processing JavaScript or ECMAScript encoded within a JSON string. ## %appendix% Acknowledgments @@ -859,5 +859,5 @@ to the document. [^6]: This section to be removed before leaving Internet-Draft status. -[RFC3987]: https://www.rfc-editor.org/info/rfc3987 -[RFC8259]: https://www.rfc-editor.org/info/rfc8259 \ No newline at end of file +[rfc3987]: https://www.rfc-editor.org/info/rfc3987 +[rfc8259]: https://www.rfc-editor.org/info/rfc8259 \ No newline at end of file From fb6198a75cb8f4745b5375f2e87002a6a5895a97 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 11 Jan 2025 08:28:19 +1300 Subject: [PATCH 713/780] find/replace overuse --- specs/jsonschema-validation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 82a99228..56fb0dbf 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -192,7 +192,7 @@ A string instance is valid against this keyword if its length is less than, or equal to, the value of this keyword. The length of a string instance is defined as the number of its characters as -defined by [RFC 8259][RFC 8259]. +defined by [RFC 8259][rfc8259]. #### `minLength` @@ -202,7 +202,7 @@ A string instance is valid against this keyword if its length is greater than, or equal to, the value of this keyword. The length of a string instance is defined as the number of its characters as -defined by [RFC 8259][RFC 8259]. +defined by [RFC 8259][rfc8259]. Omitting this keyword has the same behavior as a value of 0. @@ -583,7 +583,7 @@ Another example: Instances described by this schema are expected to be strings containing HTML, using whatever character set the JSON string was decoded into. Per section 8.1 -of [RFC 8259][RFC 8259], outside of an entirely closed system, this MUST be +of [RFC 8259][rfc8259], outside of an entirely closed system, this MUST be UTF-8. This example describes a JWT that is MACed using the HMAC SHA-256 algorithm, and From 19637d6bdeb5dffeb24f15ea44061dc199f0f62f Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 11 Jan 2025 08:45:27 +1300 Subject: [PATCH 714/780] end with a blank line --- specs/jsonschema-validation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 56fb0dbf..b78f521a 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -860,4 +860,4 @@ to the document. [^6]: This section to be removed before leaving Internet-Draft status. [rfc3987]: https://www.rfc-editor.org/info/rfc3987 -[rfc8259]: https://www.rfc-editor.org/info/rfc8259 \ No newline at end of file +[rfc8259]: https://www.rfc-editor.org/info/rfc8259 From 23780de87935bc2defc7543f51031b5057a89282 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Mon, 13 Jan 2025 21:36:10 -0800 Subject: [PATCH 715/780] Transform links to .md to .html --- remark/rehype-link-transformer.js | 18 ++++++++++++++++++ specs/.remarkrc-build.js | 2 ++ 2 files changed, 20 insertions(+) create mode 100644 remark/rehype-link-transformer.js diff --git a/remark/rehype-link-transformer.js b/remark/rehype-link-transformer.js new file mode 100644 index 00000000..224667d1 --- /dev/null +++ b/remark/rehype-link-transformer.js @@ -0,0 +1,18 @@ +import { existsSync } from "fs"; +import { visit } from "unist-util-visit"; +import url from "url"; + + +const rehypeLinkTransformer = () => (tree, vfile) => { + visit(tree, "element", (node) => { + if (node.tagName === "a") { + const href = url.parse(node.properties.href); + if (href.hostname === null && href.pathname?.endsWith(".md") && existsSync(vfile.history[0])) { + href.pathname = href.pathname.replace(/.md$/, ".html"); + node.properties.href = url.format(href); + } + } + }); +}; + +export default rehypeLinkTransformer; diff --git a/specs/.remarkrc-build.js b/specs/.remarkrc-build.js index 89ca8695..e73b10ad 100644 --- a/specs/.remarkrc-build.js +++ b/specs/.remarkrc-build.js @@ -6,6 +6,7 @@ import remarkRehype from "remark-rehype"; import rehypeStringify from "rehype-stringify"; import rehypeDocument from "rehype-document"; import specsPreset from "./.remarkrc-specs.js"; +import rehypeLinkTransformer from "../remark/rehype-link-transformer.js"; dotenv.config(); @@ -15,6 +16,7 @@ export default { specsPreset, remarkTorchLight, remarkRehype, + rehypeLinkTransformer, [rehypeDocument, { css: ["https://cdn.jsdelivr.net/npm/water.css@2/out/dark.css"], style: readFileSync(resolve(import.meta.dirname, "spec.css"), "utf8") From 0a5c8159dd6862b543984a3e42a23f3f91396df9 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Mon, 13 Jan 2025 21:37:25 -0800 Subject: [PATCH 716/780] Fix links --- specs/jsonschema-core.md | 2 +- specs/jsonschema-validation.md | 14 +++++++++----- .../jsonschema-validation-output-machines.md | 11 ++++++----- 3 files changed, 16 insertions(+), 11 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index d07bae2d..f50726d3 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -692,7 +692,7 @@ based on the schema location that contributed the value. This is intended to allow flexible usage. Collecting the schema location facilitates such usage. For example, consider this schema, which uses annotations and assertions from -the [Validation specification](./jsonschema-validation): +the [Validation specification](./jsonschema-validation.md): Note that some lines are wrapped for clarity. diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index b78f521a..0151a2ad 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -29,7 +29,7 @@ keywords described in this specification. In addition, a set of keywords is also defined to assist in interactive user interface instance generation. This specification will use the concepts, syntax, and terminology defined by the -[JSON Schema core](./jsonschema-core) specification. +[JSON Schema core](./jsonschema-core.md) specification. ## Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", @@ -41,7 +41,7 @@ object instances. It uses the term "children instances" to refer to array elements or object member values. Elements in an array value are said to be unique if no two elements of this -array are [equal](./jsonschema-core). +array are [equal](./jsonschema-core.md). ## Overview @@ -82,7 +82,8 @@ with such data. Keywords that use regular expressions, or constrain the instance value to be a regular expression, are subject to the interoperability considerations for -regular expressions in the [JSON Schema Core](./jsonschema-core) specification. +regular expressions in the [JSON Schema Core](./jsonschema-core.md) +specification. ## Meta-Schema {#meta-schema} @@ -303,7 +304,8 @@ type, each distinct value will generally only validate a given set of instance types. If the type of the instance to validate is not in this set, validation for this keyword SHOULD succeed. All format values defined in this section apply to strings, but a format value can be specified to apply to any instance types -defined in the data model defined in the [core JSON Schema](./jsonschema-core) specification[^1]. +defined in the data model defined in the [core JSON +Schema](./jsonschema-core.md) specification[^1]. [^1]: Note that the `type` keyword in this specification defines an "integer" type which is not part of the data model. Therefore a format attribute can be @@ -321,7 +323,9 @@ from previous iterations of this specification. Previously, `format` was an annotation-only keyword by default and implementations that supported assertion were required to offer some configuration that allowed users to explicitly enable assertion. Assertion is now a requirement in order to meet user -expectations. See [json-schema-org/json-schema-spec #1520](https://github.com/json-schema-org/json-schema-spec/issues/1520) for more. +expectations. See [json-schema-org/json-schema-spec +#1520](https://github.com/json-schema-org/json-schema-spec/issues/1520) for +more. In addition to the assertion behavior, this keyword also produces its value as an annotation. diff --git a/specs/output/jsonschema-validation-output-machines.md b/specs/output/jsonschema-validation-output-machines.md index db97e048..2043b7a4 100644 --- a/specs/output/jsonschema-validation-output-machines.md +++ b/specs/output/jsonschema-validation-output-machines.md @@ -20,10 +20,11 @@ absolute. ## Textual Format and Encoding JSON Schema output is defined using the JSON Schema data instance model as -described in [JSON Schema](./jsonschema-core) "Instance Data Model". Implementations -MAY deviate from this in their internal modelling, as supported by their -specific languages and platforms, however it is RECOMMENDED that the output be -convertible to the JSON format defined herein via serialization or other means. +described in [JSON Schema](../jsonschema-core.md) "Instance Data Model". +Implementations MAY deviate from this in their internal modelling, as supported +by their specific languages and platforms, however it is RECOMMENDED that the +output be convertible to the JSON format defined herein via serialization or +other means. ## Minimum Information @@ -35,7 +36,7 @@ contents of each output unit is specified by this section. Each output unit MUST contain the [validation result](#validation-result) for the associated subschema as well as the following information defined by -[JSON Schema](./jsonschema-core) "Output Formatting": +[JSON Schema](../jsonschema-core.md) "Output Formatting": - Evaluation Path - Schema Location From 11216df70232e90c33c045f6464a5ae6f4cc007a Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 22 Nov 2024 10:25:08 +1300 Subject: [PATCH 717/780] clarify that contentSchema holds a subschema and when/how it applies --- specs/jsonschema-validation.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index f20f64b2..819ab664 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -533,19 +533,24 @@ defined by [RFC 2046](#rfc2046). ### `contentSchema` -If the instance is a string, and if `contentMediaType` is present, this property -contains a schema which describes the structure of the string. +If the instance is a string, and if `contentMediaType` is present, this +property's subschema describes the structure of the string. This keyword MAY be used with any media type that can be mapped into JSON Schema's data model. Specifying such mappings is outside of the scope of this specification. -The value of this property MUST be a valid JSON schema. It SHOULD be ignored if -`contentMediaType` is not present. Accessing the schema through the schema -location IRI included as part of the annotation will ensure that it is correctly -processed as a subschema. Using the extracted annotation value directly is only -safe if the schema is an embedded resource with both `$schema` and an -absolute IRI `$id`. +The value of this property MUST be a valid JSON schema. The subschema is +produced as an annotation. + +Since `contentMediaType` is required to provide instruction on how to interpret +the string content, the annotation schema produced by this keyword has no +meaning if `contentMediaType` is not present. + +Accessing the schema through the schema location IRI included as part of the +annotation will ensure that it is correctly processed as a subschema. Using the +extracted annotation value directly is only safe if the subschema is an embedded +resource with both `$schema` and an absolute IRI `$id`. ### Example From 8e0466f58435ed52a52852aa37be70740d3a31e4 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 22 Nov 2024 10:41:00 +1300 Subject: [PATCH 718/780] apply text wrap --- specs/jsonschema-validation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 819ab664..23c16860 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -544,8 +544,8 @@ The value of this property MUST be a valid JSON schema. The subschema is produced as an annotation. Since `contentMediaType` is required to provide instruction on how to interpret -the string content, the annotation schema produced by this keyword has no -meaning if `contentMediaType` is not present. +string content, the annotation schema produced by this keyword has no meaning if +`contentMediaType` is not present. Accessing the schema through the schema location IRI included as part of the annotation will ensure that it is correctly processed as a subschema. Using the From 6342ec3754eed4ba4dfbf8585e71a70dba034cb6 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 24 Nov 2024 11:48:06 +1300 Subject: [PATCH 719/780] update note about processing contentSchema subschema in context --- specs/jsonschema-validation.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 23c16860..e8442158 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -547,10 +547,18 @@ Since `contentMediaType` is required to provide instruction on how to interpret string content, the annotation schema produced by this keyword has no meaning if `contentMediaType` is not present. -Accessing the schema through the schema location IRI included as part of the -annotation will ensure that it is correctly processed as a subschema. Using the -extracted annotation value directly is only safe if the subschema is an embedded -resource with both `$schema` and an absolute IRI `$id`. +Note that evaluating the `contentSchema` subschema in-place (i.e. as part of its +parent schema) will ensure that it is correctly processed. Independent use of +the extracted subschema (as returned in an annotation) is only safe if the +subschema is an embedded reource which defines both a `$schema` and an absolute +IRI `$id`.[^7] + +[^7] Processing a non-resource subschema in place will ensure that any +references (e.g. `$ref`) are always resolved properly. This isn't a problem when +the subschema is itself a resource. See +https://github.com/json-schema-org/json-schema-spec/issues/1381 for several +examples where processing this subschema independently can cause `$ref` +resolution failure. ### Example From a90049e01ac8c6d0f0247c0bc05583fa40cd1679 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 28 Nov 2024 21:13:51 +1300 Subject: [PATCH 720/780] Update specs/jsonschema-validation.md Co-authored-by: Jason Desrosiers --- specs/jsonschema-validation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index e8442158..5f488977 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -534,7 +534,7 @@ defined by [RFC 2046](#rfc2046). ### `contentSchema` If the instance is a string, and if `contentMediaType` is present, this -property's subschema describes the structure of the string. +keyword's subschema describes the structure of the string. This keyword MAY be used with any media type that can be mapped into JSON Schema's data model. Specifying such mappings is outside of the scope of this From f6276dc8819c6c7d4f517e63b7ddd3ada8aa6fe9 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 28 Nov 2024 21:18:41 +1300 Subject: [PATCH 721/780] contentSchema should not produce an annotation --- specs/jsonschema-validation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 5f488977..4dd653d6 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -544,7 +544,7 @@ The value of this property MUST be a valid JSON schema. The subschema is produced as an annotation. Since `contentMediaType` is required to provide instruction on how to interpret -string content, the annotation schema produced by this keyword has no meaning if +string content, `contentSchema` SHOULD NOT produce an annotation if `contentMediaType` is not present. Note that evaluating the `contentSchema` subschema in-place (i.e. as part of its From 87f6201e8cf9ade76d5d7eabeb7afe1f90aab136 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 25 Jan 2025 11:54:53 +1300 Subject: [PATCH 722/780] Update specs/jsonschema-validation.md Co-authored-by: Jason Desrosiers --- specs/jsonschema-validation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 4dd653d6..dd36b268 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -550,7 +550,7 @@ string content, `contentSchema` SHOULD NOT produce an annotation if Note that evaluating the `contentSchema` subschema in-place (i.e. as part of its parent schema) will ensure that it is correctly processed. Independent use of the extracted subschema (as returned in an annotation) is only safe if the -subschema is an embedded reource which defines both a `$schema` and an absolute +subschema is an embedded resource which defines both a `$schema` and an absolute IRI `$id`.[^7] [^7] Processing a non-resource subschema in place will ensure that any From a1d596f46e327f2599dd69631c9aaeac4d2af3dc Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 20 Oct 2024 19:57:44 +1300 Subject: [PATCH 723/780] refer to core regex section from patternProperties and pattern --- specs/jsonschema-core.md | 5 ++--- specs/jsonschema-validation.md | 3 ++- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index f50726d3..746a8813 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -1686,9 +1686,8 @@ The presence of this keyword affects the behaviors of ##### `patternProperties` The value of `patternProperties` MUST be an object. Each property name of this -object SHOULD be a valid regular expression, according to the ECMA-262 regular -expression dialect. Each property value of this object MUST be a valid JSON -Schema. +object SHOULD be a valid regular expression as indicated in {{regex}}. Each +property value of this object MUST be a valid JSON Schema. Validation succeeds if, for each instance name that matches any regular expressions that appear as a property name in this keyword's value, the child diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 0151a2ad..07b983a2 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -210,7 +210,8 @@ Omitting this keyword has the same behavior as a value of 0. #### `pattern` {#pattern} The value of this keyword MUST be a string. This string SHOULD be a valid -regular expression, according to the ECMA-262 regular expression dialect. +regular expression as indicated in {{jsonschema-core#regex}}. + A string instance is considered valid if the regular expression matches the instance successfully. Recall: regular expressions are not implicitly anchored. From 85e38043189d6f3bc9c3c5d88a9150ff90d258cf Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 22 Oct 2024 21:11:33 +1300 Subject: [PATCH 724/780] use standard link syntax for cross-file references --- specs/jsonschema-validation.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 07b983a2..4fc3b3c4 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -210,8 +210,7 @@ Omitting this keyword has the same behavior as a value of 0. #### `pattern` {#pattern} The value of this keyword MUST be a string. This string SHOULD be a valid -regular expression as indicated in {{jsonschema-core#regex}}. - +regular expression as indicated in [JSON Schema Core, section 6.3](./jsonschema-core.md#regex). A string instance is considered valid if the regular expression matches the instance successfully. Recall: regular expressions are not implicitly anchored. From a98a84d12d225873641895eb05ea7a0c9236c816 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 22 Oct 2024 21:12:11 +1300 Subject: [PATCH 725/780] lint these lines --- specs/jsonschema-validation.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 4fc3b3c4..3d2e21f2 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -210,7 +210,8 @@ Omitting this keyword has the same behavior as a value of 0. #### `pattern` {#pattern} The value of this keyword MUST be a string. This string SHOULD be a valid -regular expression as indicated in [JSON Schema Core, section 6.3](./jsonschema-core.md#regex). +regular expression as indicated in +[JSON Schema Core, section 6.3](./jsonschema-core.md#regex). A string instance is considered valid if the regular expression matches the instance successfully. Recall: regular expressions are not implicitly anchored. From 1cf5783da61c338c89acbc2cf4b54be03d52198c Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 30 Nov 2024 18:24:05 +1300 Subject: [PATCH 726/780] edit cross-doc link; add comment --- specs/jsonschema-validation.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 3d2e21f2..49489024 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -211,7 +211,8 @@ Omitting this keyword has the same behavior as a value of 0. The value of this keyword MUST be a string. This string SHOULD be a valid regular expression as indicated in -[JSON Schema Core, section 6.3](./jsonschema-core.md#regex). +[JSON Schema Core, section 6.3](./jsonschema-core.html#regex). + A string instance is considered valid if the regular expression matches the instance successfully. Recall: regular expressions are not implicitly anchored. From 5b217f181ecddb1b59bbe41caba964999a61111f Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 2 Feb 2025 13:26:24 +1300 Subject: [PATCH 727/780] use .md extension --- specs/jsonschema-validation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 49489024..44196e22 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -211,7 +211,7 @@ Omitting this keyword has the same behavior as a value of 0. The value of this keyword MUST be a string. This string SHOULD be a valid regular expression as indicated in -[JSON Schema Core, section 6.3](./jsonschema-core.html#regex). +[JSON Schema Core, section 6.3](./jsonschema-core.md#regex). A string instance is considered valid if the regular expression matches the From b5f2cae748c59cff589123af738d9c1bf1b755f8 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 2 Feb 2025 13:51:08 +1300 Subject: [PATCH 728/780] lowercase unnecessary MAY usage --- specs/jsonschema-validation.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 0151a2ad..318dd63a 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -661,11 +661,11 @@ the instance location to be deprecated if any occurrence specifies a `true` value. If `deprecated` has a value of boolean `true`, it indicates that applications -SHOULD refrain from usage of the declared property. It MAY mean the property is +SHOULD refrain from usage of the declared property. It may mean the property is going to be removed in the future. A root schema containing `deprecated` with a value of `true` indicates that the -entire resource being described MAY be removed in the future. +entire resource being described may be removed in the future. The `deprecated` keyword applies to each instance location to which the schema object containing the keyword successfully applies. This can result in scenarios @@ -687,8 +687,8 @@ managed exclusively by the owning authority, and attempts by an application to modify the value are expected to be ignored or rejected by that owning authority. -An instance document that is marked as `readOnly` for the entire document MAY be -ignored if sent to the owning authority, or MAY result in an error, at the +An instance document that is marked as `readOnly` for the entire document may be +ignored if sent to the owning authority, or may result in an error, at the authority's discretion. If `writeOnly` has a value of boolean `true`, it indicates that the value is @@ -697,8 +697,8 @@ be present when sent to the owning authority to update or create the document (or the resource it represents), but it will not be included in any updated or newly created version of the instance. -An instance document that is marked as `writeOnly` for the entire document MAY -be returned as a blank document of some sort, or MAY produce an error upon +An instance document that is marked as `writeOnly` for the entire document may +be returned as a blank document of some sort, or may produce an error upon retrieval, or have the retrieval request ignored, at the authority's discretion. For example, `readOnly` would be used to mark a database-generated serial number From 4cc993f5e2f7b5ccbda872836eca6d2e6e9e5e2c Mon Sep 17 00:00:00 2001 From: Richard Gibson Date: Sun, 2 Feb 2025 13:02:16 -0500 Subject: [PATCH 729/780] fix typo --- specs/jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 9f238db5..e86c4c9f 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -376,7 +376,7 @@ tokens: - simple quantifiers: `+` (one or more), `*` (zero or more), `?` (zero or one), and their non-greedy versions (`+?`, `*?`, `??`); - range quantifiers: `{x}` (exactly x occurrences), `{x,y}` (at least x, at most - y, occurrences), {x,} (x occurrences or more), and their non-greedy versions; + y, occurrences), `{x,}` (x occurrences or more), and their non-greedy versions; - the beginning-of-input (`^`) and end-of-input (`$`) anchors; - simple grouping (using `(` and `)`) and alternation (`|`). From a0e4a56e3ba7e442c839a1a74632ca19bf993e66 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 19 Jan 2025 21:40:02 +1300 Subject: [PATCH 730/780] clarify what a keyword's annotation value is --- specs/jsonschema-core.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 39beedae..d6131e7d 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -657,8 +657,8 @@ which are provided to applications to use as they see fit. JSON Schema implementations are not expected to make use of the collected information on behalf of applications. -Unless otherwise specified, the value of an annotation keyword is the keyword's -value. However, other behaviors are possible. For example, [JSON +Unless otherwise specified, a keyword's annotation value is value of the +keyword itself. However, other behaviors are possible. For example, [JSON Hyper-Schema's](https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-hyperschema-02) `links` keyword is a complex annotation that produces a value based in part on the instance data. From 2bff2fd4372e3235168f5fd09913fdbfb71a84e9 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Tue, 25 Feb 2025 09:54:31 -0800 Subject: [PATCH 731/780] Additional cleanup for dynamic references Co-authored-by: Greg Dennis --- specs/jsonschema-core.md | 189 +++++++++++++++++++-------------------- 1 file changed, 92 insertions(+), 97 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index d6131e7d..3154ae5e 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -240,7 +240,7 @@ A schema that itself describes a schema is called a meta-schema. Meta-schemas are used to validate JSON Schemas and specify the set of keywords those schemas are using. -#### Root Schema and Subschemas and Resources {#root} +#### Root Schema, Subschemas, and Resources {#root} A JSON Schema resource is a schema which is [canonically](https://www.rfc-editor.org/info/rfc6596) identified by an @@ -334,9 +334,8 @@ NCNameChar = NCNameStartChar / "-" / "." / DIGIT All fragment identifiers that do not match the JSON Pointer syntax MUST be interpreted as plain name fragment identifiers. -Defining and referencing a plain name fragment identifier within an -`application/schema+json` document are specified in the [`$anchor` -keyword](#anchors) section. +Defining a plain name fragment identifier within an `application/schema+json` +document is specified in the [`$anchor` keyword](#anchors) section. ## General Considerations @@ -950,40 +949,35 @@ an [absolute IRI](https://www.rfc-editor.org/rfc/rfc3987.html#section-2.2) #### Defining location-independent identifiers {#anchors} -Using JSON Pointer fragments requires knowledge of the structure of the schema. -When writing schema documents with the intention to provide re-usable schemas, -it may be preferable to use a plain name fragment that is not tied to any -particular structural location. This allows a subschema to be relocated without -requiring JSON Pointer references to be updated. - -The `$anchor` and `$dynamicAnchor` keywords are used to specify such fragments. -They are identifier keywords that can only be used to create plain name -fragments, rather than absolute IRIs as seen with `$id`. - -`$anchor` defines a reference target for `$ref`. The fragment defined by this -keyword is appended to the IRI of the schema resource containing it. As -discussed in {{id-keyword}}, this is either the nearest `$id` in the same or an -ancestor schema object, or the base IRI for the document as determined according -to [RFC 3987][rfc3987] and -[RFC 3986][rfc3986]. - -In contrast, `$dynamicAnchor` operates independently of resource IRIs and is -instead dependent on the dynamic scope of the evaluation. `$dynamicAnchor` -defines a reference target for the `$dynamicRef` keyword. This advanced feature -makes it easier to extend recursive schemas such as the meta-schemas, without -imposing any particular semantics on that extension. See {{dynamic-ref}} for -details. +Using JSON Pointers in IRI fragments to reference subschemas couples the IRI to +the structure of the schema. Using plain name fragment identifiers in IRI +fragments to identify subschemas is sometimes preferable because it is not tied +to a particular structural location. This allows a subschema to be relocated +without requiring references to be updated. -In most cases, the normal fragment behavior both suffices and is more intuitive. -Therefore it is RECOMMENDED that `$anchor` be used to create plain name -fragments unless there is a clear need for `$dynamicAnchor`. +The `$anchor` and `$dynamicAnchor` keywords are used to define +location-independent identifiers for subschemas within a schema resource. -If present, the value of these keywords MUST be a string and MUST conform to the -plain name fragment identifier syntax defined in {{fragments}}.[^4] +`$anchor` defines a plain name fragment identifier that can be used in IRI +fragments as an alternative to JSON Pointers.[^4] See {{fragments}}. [^4]: Note that the anchor string does not include the "#" character, as it is -not a IRI reference. An `$anchor`: "foo" becomes the fragment `#foo` when used -in a IRI. See below for full examples. +just a fragment identifier not an IRI reference. To reference the "foo" +`$anchor` from the same schema resource, you would use the fragment-only IRI +`#foo`. See below for full examples. + +`$dynamicAnchor` defines a different kind of fragment identifier that only has +meaning when used with `$dynamicRef`. It's not a normal fragment identifier and +therefore can't be used anywhere other than `$dynamicRef`. Normal [fragment +identifiers](https://www.rfc-editor.org/rfc/rfc3986#section-3.5) identify the +secondary resource (the subschema) while the rest of the IRI identifies the +primary resource (the schema resource). The fragment identifiers defined by +`$dynamicAnchor` are not normal fragment identifies because they identify both +the primary resource and the secondary resource. See {{dynamic-ref}} for +details. + +If present, the value of these keywords MUST be a string and MUST conform to the +plain name fragment identifier syntax defined in {{fragments}}. #### Duplicate schema identifiers {#duplicate-iris} @@ -1007,7 +1001,7 @@ identified schema. Its results are the results of the referenced schema.[^5] [^5]: Note that this definition of how the results are determined means that other keywords can appear alongside of `$ref` in the same schema object. -The value of the `$ref` keyword MUST be a string which is a IRI reference. +The value of the `$ref` keyword MUST be a string which is an IRI reference. Resolved against the current IRI base, it produces the IRI of the schema to apply. This resolution is safe to perform on schema load, as the process of evaluating an instance cannot change how the reference resolves. @@ -1019,28 +1013,25 @@ default to operating offline. ##### Dynamic References with `$dynamicRef` {#dynamic-ref} -The `$dynamicRef` keyword is an applicator that allows for deferring the full -resolution until runtime, at which point it is resolved each time it is -encountered while evaluating an instance. - -Together with `$dynamicAnchor`, `$dynamicRef` implements a cooperative extension -mechanism that is primarily useful to to create open schemas, where -`$dynamicRef` defines the extension point and `$dynamicAnchor` defines the -target. +The `$dynamicRef` keyword is an applicator that is used when the referencing +schema might need to override where a reference in the referenced schema will +resolve. This is useful for cases such as authoring a recursive schema that can +be extended or a generic schema such as a list whose items are defined by the +referencing schema. The value of the `$dynamicRef` property MUST be formatted as a valid -[IRI plain name fragment](#fragments).[^3] +[fragment-only IRI](#fragments).[^3] -[^3]: `$dynamicAnchor` defines the anchor with plain text, e.g. `foo`. Although -the value of `$dynamicRef` is not an IRI fragment, for historical reasons, the -value still uses an IRI fragment syntax, e.g. `#foo`. +[^3]: `$dynamicAnchor` defines the anchor with plain text, e.g. `foo`. Although, +for historical reasons, the value of `$dynamicRef` still uses a fragment-only +IRI syntax, e.g. `#foo`. -Resolution of `$dynamicRef` begins by identifying the outermost schema -resource in the [dynamic scope](#scopes) which defines a matching -`$dynamicAnchor`. The schema to apply is the subschema of this resource which -contains the matching `$dynamicAnchor`. +Resolution of `$dynamicRef` begins by identifying the outermost schema resource +in the [dynamic scope](#scopes) which defines a matching `$dynamicAnchor`. The +schema to apply is the subschema of this resource which contains the matching +`$dynamicAnchor`. If no matching `$dynamicAnchor` is found, see {{failed-refs}}. -For a full example using these keywords, see {{recursive-example}}.[^6] +For a full example using these keywords, see {{dynamic-example}}.[^6] [^6]: The differences in the hyper-schema meta-schemas from draft-07 and draft 2019-09 dramatically demonstrates the utility of these keywords. @@ -1205,22 +1196,23 @@ If an implementation has been configured to resolve that identifier to a schema via pre-loading or other means, it can be used automatically; otherwise, the behavior described in {{failed-refs}} MUST be used. -#### JSON Pointer fragments and embedded schema resources {#embedded} +#### JSON Pointer fragment identifiers and embedded schema resources {#embedded} -Since JSON Pointer IRI fragments are constructed based on the structure of the -schema document, an embedded schema resource and its subschemas can be -identified by JSON Pointer fragments relative to either its own canonical IRI, -or relative to any containing resource's IRI. +Since JSON Pointer fragment identifiers are based on the structure of the schema +document, an embedded schema resource and its subschemas can be identified using +JSON Pointer IRI fragments relative to either its own IRI, or relative to any +containing resource's IRI. Conceptually, a set of linked schema resources should behave identically whether each resource is a separate document connected with [schema references](#referenced), or is structured as a single document with one or more schema resources embedded as subschemas. -Since IRIs involving JSON Pointer fragments relative to the parent schema -resource's IRI cease to be valid when the embedded schema is moved to a separate -document and referenced, applications and schemas SHOULD NOT use such IRIs to -identify embedded schema resources or locations within them. +Since IRIs with JSON Pointer fragments are relative to the parent schema +resource's IRI, they cease to be valid when the embedded schema is moved to a +separate document and referenced. Because of this, applications and schemas +SHOULD NOT use such IRIs to identify embedded schema resources or locations +within them. Consider the following schema document that contains another schema resource embedded within it: @@ -1244,7 +1236,7 @@ For the `additionalProperties` schema within that embedded resource, the IRI object, but that object's IRI relative to its resource's canonical IRI is `https://example.com/bar#/additionalProperties`. -Now consider the following two schema resources linked by reference using a IRI +Now consider the following two schema resources linked by reference using an IRI value for `$ref`: ```jsonschema @@ -1264,10 +1256,11 @@ value for `$ref`: ``` Here we see that `https://example.com/bar#/additionalProperties`, using a JSON -Pointer fragment appended to the canonical IRI of the "bar" schema resource, is -still valid, while `https://example.com/foo#/items/additionalProperties`, which -relied on a JSON Pointer fragment appended to the canonical IRI of the "foo" -schema resource, no longer resolves to anything. +Pointer fragment identifier appended to the canonical IRI of the "bar" schema +resource, is still valid, while +`https://example.com/foo#/items/additionalProperties`, which relied on a JSON +Pointer fragment identifier appended to the canonical IRI of the "foo" schema +resource, no longer resolves to anything. Note also that `https://example.com/foo#/items` is valid in both arrangements, but resolves to a different value. This IRI ends up functioning similarly to a @@ -1282,14 +1275,15 @@ undefined. Schema authors SHOULD NOT rely on such IRIs, as using them may reduce interoperability.[^8] [^8]: This is to avoid requiring implementations to keep track of a whole stack -of possible base IRIs and JSON Pointer fragments for each, given that all but -one will be fragile if the schema resources are reorganized. Some have argued -that this is easy so there is no point in forbidding it, while others have -argued that it complicates schema identification and should be forbidden. -Feedback on this topic is encouraged. After some discussion, we feel that we -need to remove the use of "canonical" in favour of talking about JSON Pointers -which reference across schema resource boundaries as undefined or even forbidden -behavior (, + of possible base IRIs and JSON Pointer fragment identifiers for each, given +that all but one will be fragile if the schema resources are reorganized. Some +have argued that this is easy so there is no point in forbidding it, while +others have argued that it complicates schema identification and should be +forbidden. Feedback on this topic is encouraged. After some discussion, we feel +that we need to remove the use of "canonical" in favour of talking about JSON +Pointers which reference across schema resource boundaries as undefined or even +forbidden behavior +(, ) Further examples of such non-canonical IRI construction, as well as the @@ -1578,9 +1572,9 @@ subschema, then validation succeeds against this keyword if the instance also successfully validates against this keyword's subschema. This keyword has no effect when `if` is absent, or when the instance fails to -validate against the `if` subschema. Implementations MUST NOT evaluate the instance -against this keyword, for either validation or annotation collection purposes, -in such cases. +validate against the `if` subschema. Implementations MUST NOT evaluate the +instance against this keyword, for either validation or annotation collection +purposes, in such cases. ##### `else` @@ -1591,8 +1585,8 @@ then validation succeeds against this keyword if the instance successfully validates against this keyword's subschema. This keyword has no effect when `if` is absent, or when the instance -successfully validates against the `if` subschema. Implementations MUST NOT evaluate -the instance against this keyword, for either validation or annotation +successfully validates against the `if` subschema. Implementations MUST NOT +evaluate the instance against this keyword, for either validation or annotation collection purposes, in such cases. ##### `dependentSchemas` {#dependent-schemas} @@ -1856,8 +1850,8 @@ Omitting this keyword has the same assertion behavior as an empty schema. The value of `unevaluatedProperties` MUST be a valid JSON Schema. -This keyword applies to object instances by applying its subschema to the object's -property values. +This keyword applies to object instances by applying its subschema to the +object's property values. The behavior of this keyword depends on all adjacent keywords as well as keywords in successfully validated subschemas that apply to the same instance @@ -1872,9 +1866,9 @@ subschema validates against all applicable property values. The annotation result of this keyword is the set of instance property names validated by this keyword's subschema. -The presence of this keyword affects the behavior of other `unevaluatedProperties` -keywords found earlier in the dynamic scope that apply to the same instance -location. +The presence of this keyword affects the behavior of other +`unevaluatedProperties` keywords found earlier in the dynamic scope that apply +to the same instance location. Omitting this keyword has the same assertion behavior as an empty schema. @@ -2115,7 +2109,8 @@ determines the canonical nature of the resulting full IRI.[^18] and direct you to read the CREF located in {{embedded}} for further comments. While the following IRIs do correctly indicate specific schemas, per the reasons -outlined in {{embedded}}, they are to be avoided as they may not work in all implementations: +outlined in {{embedded}}, they are to be avoided as they may not work in all +implementations: Document location `/$defs/B`: - canonical (and base) `IRI: https://example.com/other.json` @@ -2183,7 +2178,7 @@ scope of this specification to determine or provide a set of safe `$ref` removal transformations, as they depend not only on the schema structure but also on the intended usage. -## %appendix% Example of recursive schema extension {#recursive-example} +## %appendix% Example of recursive schema extension {#dynamic-example} Consider the following two schemas describing a simple recursive tree structure, where each node in the tree can have a "data" field of any type. The first @@ -2235,7 +2230,7 @@ the following full schema IRIs: - `https://example.com/strict-tree#node` In addition, JSON Schema implementations keep track of the fact that these -fragments were created with `$dynamicAnchor`. +fragment identifiers were created with `$dynamicAnchor`. If we apply the "strict-tree" schema to the instance, we will follow the `$ref` to the "tree" schema, examine its "children" subschema, and find the @@ -2253,25 +2248,25 @@ At this point, the evaluation path is 1. `https://example.com/tree#/properties/children` 1. `https://example.com/tree#/properties/children/items` -Since we are looking for a plain name fragment, which can be defined anywhere -within a schema resource, the JSON Pointer fragments are irrelevant to this -check. That means that we can remove those fragments and eliminate consecutive -duplicates, producing: +Since we are looking for a plain name fragment identifier, which can be defined +anywhere within a schema resource, the JSON Pointer IRI fragments are irrelevant +to this check. That means that we can remove the fragments and eliminate +consecutive duplicates, producing: 1. `https://example.com/strict-tree` 1. `https://example.com/tree` -In this case, the outermost resource also has a "node" fragment defined by -`$dynamicAnchor`. Therefore instead of resolving the `$dynamicRef` to +In this case, the outermost resource also has a "node" fragment identifier +defined by `$dynamicAnchor`. Therefore instead of resolving the `$dynamicRef` to `https://example.com/tree#node`, we resolve it to `https://example.com/strict-tree#node`. -This way, the recursion in the "tree" schema recurses to the root of -"strict-tree", instead of only applying "strict-tree" to the instance root, but -applying "tree" to instance children. +The reference in the "tree" schema resolves to the root of "strict-tree", so +"strict-tree" is applied not only to the tree instance's root, but also its +children. This example shows both `$dynamicAnchor`s in the same place in each schema, -specifically the resource root schema. Since plain-name fragments are +specifically the resource root schema. Since plain-name fragment identifiers are independent of the JSON structure, this would work just as well if one or both of the node schema objects were moved under `$defs`. It is the matching `$dynamicAnchor` values which tell us how to resolve the dynamic reference, not From 55ad2952246ddd07cf0afefd630a7418d1ccca3c Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Tue, 18 Mar 2025 14:35:16 -0700 Subject: [PATCH 732/780] Replace torchlight with remark-highlight --- README.md | 15 +- package-lock.json | 4147 ++++++++++++++++---------------------- package.json | 4 +- specs/.remarkrc-build.js | 15 +- specs/spec.css | 27 + 5 files changed, 1732 insertions(+), 2476 deletions(-) diff --git a/README.md b/README.md index 981d9445..0f2c950d 100644 --- a/README.md +++ b/README.md @@ -63,7 +63,7 @@ features they make available to you. - [remark-heading-id](https://github.com/imcuttle/remark-heading-id) -- Adds support for `{#my-anchor}` syntax to add an `id` to an element so it can be referenced using URI fragment syntax. -- [remark-headings](/json-schema-org/json-schema-spec/blob/main/remark/remark-headings.js) +- [remark-headings](./remark/remark-headings.js) -- A collection of enhancements for headings. - Adds hierarchical section numbers to headings. - Use the `%appendix%` prefix on headings that should be numbered as an @@ -72,7 +72,7 @@ features they make available to you. - Example: `#section-2-13` - Example: `#appendix-a` - Makes the heading a link utilizing its anchor -- [remark-reference-links](/json-schema-org/json-schema-spec/blob/main/remark/remark-reference-links.js) +- [remark-reference-links](./remark/remark-reference-links.js) -- Adds new syntax for referencing a section of the spec using the section number as the link text. - Example: @@ -82,10 +82,10 @@ features they make available to you. This is covered in {{foo}} // --> Renders to "This is covered in [Section 2.3](#foo)" - Link text will use "Section" or "Appendix" as needed ``` -- [remark-table-of-contents](/json-schema-org/json-schema-spec/blob/main/remark/remark-table-of-contents.js) +- [remark-table-of-contents](./remark/remark-table-of-contents.js) -- Adds a table of contents in a section with a header called "Table of Contents". -- [remark-code-titles](/json-schema-org/json-schema-spec/blob/main/remark/remark-code-titles.js) +- [remark-code-titles](./remark/remark-code-titles.js) -- Add titles to code blocks - Example: ```markdown @@ -97,9 +97,10 @@ features they make available to you. - The title will be parsed as a JSON string, but you have to double escape escaped characters. So, to get `My "quoted" title`, you would need to be `"My \\\\"quoted\\\\" title"`. -- [remark-torchlight](https://github.com/torchlight-api/remark-torchlight) -- - Syntax highlighting and more using . Features include - line numbers and line highlighting. +- [rehype-highlight](https://github.com/rehypejs/rehype-highlight) -- + Syntax highlighting. +- [rehype-highlight-code-lines](https://github.com/ipikuka/rehype-highlight-code-lines) + -- Adds line numbers to code blocks. Supports ranges. - [remark-flexible-containers](https://github.com/ipikuka/remark-flexible-containers) -- Add a callout box using the following syntax. Supported container types are `warning`, `note`, and `experimental`. diff --git a/package-lock.json b/package-lock.json index fe249cf3..0047608d 100644 --- a/package-lock.json +++ b/package-lock.json @@ -10,7 +10,6 @@ "license": "MIT", "devDependencies": { "@stylistic/eslint-plugin": "^2.9.0", - "dotenv": "^16.4.5", "eslint": "^9.13.0", "eslint-import-resolver-node": "^0.3.9", "eslint-plugin-import": "^2.31.0", @@ -18,6 +17,8 @@ "mdast-util-find-and-replace": "^3.0.1", "mdast-util-to-string": "^4.0.0", "rehype-document": "^7.0.3", + "rehype-highlight": "^7.0.2", + "rehype-highlight-code-lines": "^1.1.3", "rehype-stringify": "^10.0.1", "remark-cli": "^12.0.1", "remark-flexible-containers": "^1.2.1", @@ -27,18 +28,18 @@ "remark-preset-lint-markdown-style-guide": "^6.0.0", "remark-preset-lint-recommended": "^7.0.0", "remark-rehype": "^11.1.1", - "remark-torchlight": "^0.0.5", "remark-validate-links": "^13.0.1" } }, "node_modules/@babel/code-frame": { - "version": "7.25.7", - "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.25.7.tgz", - "integrity": "sha512-0xZJFNE5XMpENsgfHYTw8FbX4kv53mFLn2i3XPoq69LyhYSCBJtitaHx9QnsVTrsogI4Z3+HtEfZ2/GFPOtf5g==", + "version": "7.26.2", + "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.26.2.tgz", + "integrity": "sha512-RJlIHRueQgwWitWgF8OdFYGZX328Ax5BCemNGlqHfplnRT9ESi8JkFlvaVYbS+UubVY6dpv87Fs2u5M29iNFVQ==", "dev": true, "license": "MIT", "dependencies": { - "@babel/highlight": "^7.25.7", + "@babel/helper-validator-identifier": "^7.25.9", + "js-tokens": "^4.0.0", "picocolors": "^1.0.0" }, "engines": { @@ -46,121 +47,30 @@ } }, "node_modules/@babel/helper-validator-identifier": { - "version": "7.25.7", - "resolved": "https://registry.npmjs.org/@babel/helper-validator-identifier/-/helper-validator-identifier-7.25.7.tgz", - "integrity": "sha512-AM6TzwYqGChO45oiuPqwL2t20/HdMC1rTPAesnBCgPCSF1x3oN9MVUwQV2iyz4xqWrctwK5RNC8LV22kaQCNYg==", + "version": "7.25.9", + "resolved": "https://registry.npmjs.org/@babel/helper-validator-identifier/-/helper-validator-identifier-7.25.9.tgz", + "integrity": "sha512-Ed61U6XJc3CVRfkERJWDz4dJwKe7iLmmJsbOGu9wSloNSFttHV0I8g6UAgb7qnK5ly5bGLPd4oXZlxCdANBOWQ==", "dev": true, "license": "MIT", "engines": { "node": ">=6.9.0" } }, - "node_modules/@babel/highlight": { - "version": "7.25.7", - "resolved": "https://registry.npmjs.org/@babel/highlight/-/highlight-7.25.7.tgz", - "integrity": "sha512-iYyACpW3iW8Fw+ZybQK+drQre+ns/tKpXbNESfrhNnPLIklLbXr7MYJ6gPEd0iETGLOK+SxMjVvKb/ffmk+FEw==", - "dev": true, - "license": "MIT", - "dependencies": { - "@babel/helper-validator-identifier": "^7.25.7", - "chalk": "^2.4.2", - "js-tokens": "^4.0.0", - "picocolors": "^1.0.0" - }, - "engines": { - "node": ">=6.9.0" - } - }, - "node_modules/@babel/highlight/node_modules/ansi-styles": { - "version": "3.2.1", - "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-3.2.1.tgz", - "integrity": "sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA==", - "dev": true, - "license": "MIT", - "dependencies": { - "color-convert": "^1.9.0" - }, - "engines": { - "node": ">=4" - } - }, - "node_modules/@babel/highlight/node_modules/chalk": { - "version": "2.4.2", - "resolved": "https://registry.npmjs.org/chalk/-/chalk-2.4.2.tgz", - "integrity": "sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==", - "dev": true, - "license": "MIT", - "dependencies": { - "ansi-styles": "^3.2.1", - "escape-string-regexp": "^1.0.5", - "supports-color": "^5.3.0" - }, - "engines": { - "node": ">=4" - } - }, - "node_modules/@babel/highlight/node_modules/color-convert": { - "version": "1.9.3", - "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-1.9.3.tgz", - "integrity": "sha512-QfAUtd+vFdAtFQcC8CCyYt1fYWxSqAiK2cSD6zDB8N3cpsEBAvRxp9zOGg6G/SHHJYAT88/az/IuDGALsNVbGg==", - "dev": true, - "license": "MIT", - "dependencies": { - "color-name": "1.1.3" - } - }, - "node_modules/@babel/highlight/node_modules/color-name": { - "version": "1.1.3", - "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.3.tgz", - "integrity": "sha512-72fSenhMw2HZMTVHeCA9KCmpEIbzWiQsjN+BHcBbS9vr1mtt+vJjPdksIBNUmKAW8TFUDPJK5SUU3QhE9NEXDw==", - "dev": true, - "license": "MIT" - }, - "node_modules/@babel/highlight/node_modules/escape-string-regexp": { - "version": "1.0.5", - "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz", - "integrity": "sha512-vbRorB5FUQWvla16U8R/qgaFIya2qGzwDrNmCZuYKrbdSUMG6I1ZCGQRefkRVhuOkIGVne7BQ35DSfo1qvJqFg==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=0.8.0" - } - }, - "node_modules/@babel/highlight/node_modules/has-flag": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-3.0.0.tgz", - "integrity": "sha512-sKJf1+ceQBr4SMkvQnBDNDtf4TXpVhVGateu0t918bl30FnbE2m4vNLX+VWe/dpjlb+HugGYzW7uQXH98HPEYw==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=4" - } - }, - "node_modules/@babel/highlight/node_modules/supports-color": { - "version": "5.5.0", - "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-5.5.0.tgz", - "integrity": "sha512-QjVjwdXIt408MIiAqCX4oUKsgU2EqAGzs2Ppkm4aQYbjm+ZEWEcW4SfFNTr4uMNZma0ey4f5lgLrkB0aX0QMow==", - "dev": true, - "license": "MIT", - "dependencies": { - "has-flag": "^3.0.0" - }, - "engines": { - "node": ">=4" - } - }, "node_modules/@eslint-community/eslint-utils": { - "version": "4.4.0", - "resolved": "https://registry.npmjs.org/@eslint-community/eslint-utils/-/eslint-utils-4.4.0.tgz", - "integrity": "sha512-1/sA4dwrzBAyeUoQ6oxahHKmrZvsnLCg4RfxW3ZFGGmQkSNQPFNLV9CUEFQP1x9EYXHTo5p6xdhZM1Ne9p/AfA==", + "version": "4.5.1", + "resolved": "https://registry.npmjs.org/@eslint-community/eslint-utils/-/eslint-utils-4.5.1.tgz", + "integrity": "sha512-soEIOALTfTK6EjmKMMoLugwaP0rzkad90iIWd1hMO9ARkSAyjfMfkRRhLvD5qH7vvM0Cg72pieUfR6yh6XxC4w==", "dev": true, "license": "MIT", "dependencies": { - "eslint-visitor-keys": "^3.3.0" + "eslint-visitor-keys": "^3.4.3" }, "engines": { "node": "^12.22.0 || ^14.17.0 || >=16.0.0" }, + "funding": { + "url": "https://opencollective.com/eslint" + }, "peerDependencies": { "eslint": "^6.0.0 || ^7.0.0 || >=8.0.0" } @@ -179,9 +89,9 @@ } }, "node_modules/@eslint-community/regexpp": { - "version": "4.11.1", - "resolved": "https://registry.npmjs.org/@eslint-community/regexpp/-/regexpp-4.11.1.tgz", - "integrity": "sha512-m4DVN9ZqskZoLU5GlWZadwDnYo3vAEydiUayB9widCl9ffWx2IvPnp6n3on5rJmziJSw9Bv+Z3ChDVdMwXCY8Q==", + "version": "4.12.1", + "resolved": "https://registry.npmjs.org/@eslint-community/regexpp/-/regexpp-4.12.1.tgz", + "integrity": "sha512-CCZCDJuduB9OUkFkY2IgppNZMi2lBQgD2qzwXkEia16cge2pijY/aXi96CJMquDMn3nJdlPV1A5KrJEXwfLNzQ==", "dev": true, "license": "MIT", "engines": { @@ -189,13 +99,13 @@ } }, "node_modules/@eslint/config-array": { - "version": "0.18.0", - "resolved": "https://registry.npmjs.org/@eslint/config-array/-/config-array-0.18.0.tgz", - "integrity": "sha512-fTxvnS1sRMu3+JjXwJG0j/i4RT9u4qJ+lqS/yCGap4lH4zZGzQ7tu+xZqQmcMZq5OBZDL4QRxQzRjkWcGt8IVw==", + "version": "0.19.2", + "resolved": "https://registry.npmjs.org/@eslint/config-array/-/config-array-0.19.2.tgz", + "integrity": "sha512-GNKqxfHG2ySmJOBSHg7LxeUx4xpuCoFjacmlCoYWEbaPXLwvfIjixRI12xCQZeULksQb23uiA8F40w5TojpV7w==", "dev": true, "license": "Apache-2.0", "dependencies": { - "@eslint/object-schema": "^2.1.4", + "@eslint/object-schema": "^2.1.6", "debug": "^4.3.1", "minimatch": "^3.1.2" }, @@ -203,20 +113,57 @@ "node": "^18.18.0 || ^20.9.0 || >=21.1.0" } }, + "node_modules/@eslint/config-array/node_modules/brace-expansion": { + "version": "1.1.11", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz", + "integrity": "sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==", + "dev": true, + "license": "MIT", + "dependencies": { + "balanced-match": "^1.0.0", + "concat-map": "0.0.1" + } + }, + "node_modules/@eslint/config-array/node_modules/minimatch": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz", + "integrity": "sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==", + "dev": true, + "license": "ISC", + "dependencies": { + "brace-expansion": "^1.1.7" + }, + "engines": { + "node": "*" + } + }, + "node_modules/@eslint/config-helpers": { + "version": "0.1.0", + "resolved": "https://registry.npmjs.org/@eslint/config-helpers/-/config-helpers-0.1.0.tgz", + "integrity": "sha512-kLrdPDJE1ckPo94kmPPf9Hfd0DU0Jw6oKYrhe+pwSC0iTUInmTa+w6fw8sGgcfkFJGNdWOUeOaDM4quW4a7OkA==", + "dev": true, + "license": "Apache-2.0", + "engines": { + "node": "^18.18.0 || ^20.9.0 || >=21.1.0" + } + }, "node_modules/@eslint/core": { - "version": "0.7.0", - "resolved": "https://registry.npmjs.org/@eslint/core/-/core-0.7.0.tgz", - "integrity": "sha512-xp5Jirz5DyPYlPiKat8jaq0EmYvDXKKpzTbxXMpT9eqlRJkRKIz9AGMdlvYjih+im+QlhWrpvVjl8IPC/lHlUw==", + "version": "0.12.0", + "resolved": "https://registry.npmjs.org/@eslint/core/-/core-0.12.0.tgz", + "integrity": "sha512-cmrR6pytBuSMTaBweKoGMwu3EiHiEC+DoyupPmlZ0HxBJBtIxwe+j/E4XPIKNx+Q74c8lXKPwYawBf5glsTkHg==", "dev": true, "license": "Apache-2.0", + "dependencies": { + "@types/json-schema": "^7.0.15" + }, "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" } }, "node_modules/@eslint/eslintrc": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/@eslint/eslintrc/-/eslintrc-3.1.0.tgz", - "integrity": "sha512-4Bfj15dVJdoy3RfZmmo86RK1Fwzn6SstsvK9JS+BaVKqC6QQQQyXekNaC+g+LKNgkQ+2VhGAzm6hO40AhMR3zQ==", + "version": "3.3.0", + "resolved": "https://registry.npmjs.org/@eslint/eslintrc/-/eslintrc-3.3.0.tgz", + "integrity": "sha512-yaVPAiNAalnCZedKLdR21GOGILMLKPyqSLWaAjQFvYA2i/ciDi8ArYVr69Anohb6cH2Ukhqti4aFnYyPm8wdwQ==", "dev": true, "license": "MIT", "dependencies": { @@ -237,10 +184,34 @@ "url": "https://opencollective.com/eslint" } }, + "node_modules/@eslint/eslintrc/node_modules/brace-expansion": { + "version": "1.1.11", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz", + "integrity": "sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==", + "dev": true, + "license": "MIT", + "dependencies": { + "balanced-match": "^1.0.0", + "concat-map": "0.0.1" + } + }, + "node_modules/@eslint/eslintrc/node_modules/minimatch": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz", + "integrity": "sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==", + "dev": true, + "license": "ISC", + "dependencies": { + "brace-expansion": "^1.1.7" + }, + "engines": { + "node": "*" + } + }, "node_modules/@eslint/js": { - "version": "9.13.0", - "resolved": "https://registry.npmjs.org/@eslint/js/-/js-9.13.0.tgz", - "integrity": "sha512-IFLyoY4d72Z5y/6o/BazFBezupzI/taV8sGumxTAVw3lXG9A6md1Dc34T9s1FoD/an9pJH8RHbAxsaEbBed9lA==", + "version": "9.22.0", + "resolved": "https://registry.npmjs.org/@eslint/js/-/js-9.22.0.tgz", + "integrity": "sha512-vLFajx9o8d1/oL2ZkpMYbkLv8nDB6yaIwFNt7nI4+I80U/z03SxmfOMsLbvWr3p7C+Wnoh//aOu2pQW8cS0HCQ==", "dev": true, "license": "MIT", "engines": { @@ -248,9 +219,9 @@ } }, "node_modules/@eslint/object-schema": { - "version": "2.1.4", - "resolved": "https://registry.npmjs.org/@eslint/object-schema/-/object-schema-2.1.4.tgz", - "integrity": "sha512-BsWiH1yFGjXXS2yvrf5LyuoSIIbPrGUWob917o+BTKuZ7qJdxX8aJLRxs1fS9n6r7vESrq1OUqb68dANcFXuQQ==", + "version": "2.1.6", + "resolved": "https://registry.npmjs.org/@eslint/object-schema/-/object-schema-2.1.6.tgz", + "integrity": "sha512-RBMg5FRL0I0gs51M/guSAj5/e14VQ4tpZnQNWwuDT66P14I43ItmPfIZRhO9fUVIPOAQXU47atlywZ/czoqFPA==", "dev": true, "license": "Apache-2.0", "engines": { @@ -258,12 +229,13 @@ } }, "node_modules/@eslint/plugin-kit": { - "version": "0.2.0", - "resolved": "https://registry.npmjs.org/@eslint/plugin-kit/-/plugin-kit-0.2.0.tgz", - "integrity": "sha512-vH9PiIMMwvhCx31Af3HiGzsVNULDbyVkHXwlemn/B0TFj/00ho3y55efXrUZTfQipxoHC5u4xq6zblww1zm1Ig==", + "version": "0.2.7", + "resolved": "https://registry.npmjs.org/@eslint/plugin-kit/-/plugin-kit-0.2.7.tgz", + "integrity": "sha512-JubJ5B2pJ4k4yGxaNLdbjrnk9d/iDz6/q8wOilpIowd6PJPgaxCuHBnBszq7Ce2TyMrywm5r4PnKm6V3iiZF+g==", "dev": true, "license": "Apache-2.0", "dependencies": { + "@eslint/core": "^0.12.0", "levn": "^0.4.1" }, "engines": { @@ -271,9 +243,9 @@ } }, "node_modules/@humanfs/core": { - "version": "0.19.0", - "resolved": "https://registry.npmjs.org/@humanfs/core/-/core-0.19.0.tgz", - "integrity": "sha512-2cbWIHbZVEweE853g8jymffCA+NCMiuqeECeBBLm8dg2oFdjuGJhgN4UAbI+6v0CKbbhvtXA4qV8YR5Ji86nmw==", + "version": "0.19.1", + "resolved": "https://registry.npmjs.org/@humanfs/core/-/core-0.19.1.tgz", + "integrity": "sha512-5DyQ4+1JEUzejeK1JGICcideyfUbGixgS9jNgex5nqkW+cY7WZhxBigmieN5Qnw9ZosSNVC9KQKyb+GUaGyKUA==", "dev": true, "license": "Apache-2.0", "engines": { @@ -281,19 +253,33 @@ } }, "node_modules/@humanfs/node": { - "version": "0.16.5", - "resolved": "https://registry.npmjs.org/@humanfs/node/-/node-0.16.5.tgz", - "integrity": "sha512-KSPA4umqSG4LHYRodq31VDwKAvaTF4xmVlzM8Aeh4PlU1JQ3IG0wiA8C25d3RQ9nJyM3mBHyI53K06VVL/oFFg==", + "version": "0.16.6", + "resolved": "https://registry.npmjs.org/@humanfs/node/-/node-0.16.6.tgz", + "integrity": "sha512-YuI2ZHQL78Q5HbhDiBA1X4LmYdXCKCMQIfw0pw7piHJwyREFebJUvrQN4cMssyES6x+vfUbx1CIpaQUKYdQZOw==", "dev": true, "license": "Apache-2.0", "dependencies": { - "@humanfs/core": "^0.19.0", + "@humanfs/core": "^0.19.1", "@humanwhocodes/retry": "^0.3.0" }, "engines": { "node": ">=18.18.0" } }, + "node_modules/@humanfs/node/node_modules/@humanwhocodes/retry": { + "version": "0.3.1", + "resolved": "https://registry.npmjs.org/@humanwhocodes/retry/-/retry-0.3.1.tgz", + "integrity": "sha512-JBxkERygn7Bv/GbN5Rv8Ul6LVknS+5Bp6RgDC/O8gEBU/yeH5Ui5C/OlWrTb6qct7LjjfT6Re2NxB0ln0yYybA==", + "dev": true, + "license": "Apache-2.0", + "engines": { + "node": ">=18.18" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/nzakas" + } + }, "node_modules/@humanwhocodes/module-importer": { "version": "1.0.1", "resolved": "https://registry.npmjs.org/@humanwhocodes/module-importer/-/module-importer-1.0.1.tgz", @@ -309,9 +295,9 @@ } }, "node_modules/@humanwhocodes/retry": { - "version": "0.3.1", - "resolved": "https://registry.npmjs.org/@humanwhocodes/retry/-/retry-0.3.1.tgz", - "integrity": "sha512-JBxkERygn7Bv/GbN5Rv8Ul6LVknS+5Bp6RgDC/O8gEBU/yeH5Ui5C/OlWrTb6qct7LjjfT6Re2NxB0ln0yYybA==", + "version": "0.4.2", + "resolved": "https://registry.npmjs.org/@humanwhocodes/retry/-/retry-0.4.2.tgz", + "integrity": "sha512-xeO57FpIu4p1Ri3Jq/EXq4ClRm86dVF2z/+kvFnyqVYRavTZmaFaUBbWCOuuTh0o/g7DSsk6kc2vrS4Vl5oPOQ==", "dev": true, "license": "Apache-2.0", "engines": { @@ -340,91 +326,6 @@ "node": ">=12" } }, - "node_modules/@isaacs/cliui/node_modules/ansi-regex": { - "version": "6.1.0", - "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.1.0.tgz", - "integrity": "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/chalk/ansi-regex?sponsor=1" - } - }, - "node_modules/@isaacs/cliui/node_modules/ansi-styles": { - "version": "6.2.1", - "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-6.2.1.tgz", - "integrity": "sha512-bN798gFfQX+viw3R7yrGWRqnrN2oRkEkUjjl4JNn4E8GxxbjtG3FbrEIIY3l8/hrwUwIeCZvi4QuOTP4MErVug==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/chalk/ansi-styles?sponsor=1" - } - }, - "node_modules/@isaacs/cliui/node_modules/emoji-regex": { - "version": "9.2.2", - "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-9.2.2.tgz", - "integrity": "sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg==", - "dev": true, - "license": "MIT" - }, - "node_modules/@isaacs/cliui/node_modules/string-width": { - "version": "5.1.2", - "resolved": "https://registry.npmjs.org/string-width/-/string-width-5.1.2.tgz", - "integrity": "sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==", - "dev": true, - "license": "MIT", - "dependencies": { - "eastasianwidth": "^0.2.0", - "emoji-regex": "^9.2.2", - "strip-ansi": "^7.0.1" - }, - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/@isaacs/cliui/node_modules/strip-ansi": { - "version": "7.1.0", - "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz", - "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==", - "dev": true, - "license": "MIT", - "dependencies": { - "ansi-regex": "^6.0.1" - }, - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/chalk/strip-ansi?sponsor=1" - } - }, - "node_modules/@isaacs/cliui/node_modules/wrap-ansi": { - "version": "8.1.0", - "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-8.1.0.tgz", - "integrity": "sha512-si7QWI6zUMq56bESFvagtmzMdGOtoxfR+Sez11Mobfc7tm+VkUckk9bW2UeffTGVUbOksxmSw0AA2gs8g71NCQ==", - "dev": true, - "license": "MIT", - "dependencies": { - "ansi-styles": "^6.1.0", - "string-width": "^5.0.1", - "strip-ansi": "^7.0.1" - }, - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/chalk/wrap-ansi?sponsor=1" - } - }, "node_modules/@nodelib/fs.scandir": { "version": "2.1.5", "resolved": "https://registry.npmjs.org/@nodelib/fs.scandir/-/fs.scandir-2.1.5.tgz", @@ -483,19 +384,6 @@ "node": "^16.14.0 || >=18.0.0" } }, - "node_modules/@npmcli/config/node_modules/semver": { - "version": "7.6.3", - "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", - "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", - "dev": true, - "license": "ISC", - "bin": { - "semver": "bin/semver.js" - }, - "engines": { - "node": ">=10" - } - }, "node_modules/@npmcli/git": { "version": "5.0.8", "resolved": "https://registry.npmjs.org/@npmcli/git/-/git-5.0.8.tgz", @@ -527,19 +415,6 @@ "node": ">=16" } }, - "node_modules/@npmcli/git/node_modules/semver": { - "version": "7.6.3", - "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", - "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", - "dev": true, - "license": "ISC", - "bin": { - "semver": "bin/semver.js" - }, - "engines": { - "node": ">=10" - } - }, "node_modules/@npmcli/git/node_modules/which": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/which/-/which-4.0.0.tgz", @@ -572,53 +447,6 @@ "node": "^14.17.0 || ^16.13.0 || >=18.0.0" } }, - "node_modules/@npmcli/map-workspaces/node_modules/brace-expansion": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", - "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", - "dev": true, - "license": "MIT", - "dependencies": { - "balanced-match": "^1.0.0" - } - }, - "node_modules/@npmcli/map-workspaces/node_modules/glob": { - "version": "10.4.5", - "resolved": "https://registry.npmjs.org/glob/-/glob-10.4.5.tgz", - "integrity": "sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==", - "dev": true, - "license": "ISC", - "dependencies": { - "foreground-child": "^3.1.0", - "jackspeak": "^3.1.2", - "minimatch": "^9.0.4", - "minipass": "^7.1.2", - "package-json-from-dist": "^1.0.0", - "path-scurry": "^1.11.1" - }, - "bin": { - "glob": "dist/esm/bin.mjs" - }, - "funding": { - "url": "https://github.com/sponsors/isaacs" - } - }, - "node_modules/@npmcli/map-workspaces/node_modules/minimatch": { - "version": "9.0.5", - "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.5.tgz", - "integrity": "sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==", - "dev": true, - "license": "ISC", - "dependencies": { - "brace-expansion": "^2.0.1" - }, - "engines": { - "node": ">=16 || 14 >=14.17" - }, - "funding": { - "url": "https://github.com/sponsors/isaacs" - } - }, "node_modules/@npmcli/name-from-folder": { "version": "2.0.0", "resolved": "https://registry.npmjs.org/@npmcli/name-from-folder/-/name-from-folder-2.0.0.tgz", @@ -648,66 +476,6 @@ "node": "^16.14.0 || >=18.0.0" } }, - "node_modules/@npmcli/package-json/node_modules/brace-expansion": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", - "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", - "dev": true, - "license": "MIT", - "dependencies": { - "balanced-match": "^1.0.0" - } - }, - "node_modules/@npmcli/package-json/node_modules/glob": { - "version": "10.4.5", - "resolved": "https://registry.npmjs.org/glob/-/glob-10.4.5.tgz", - "integrity": "sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==", - "dev": true, - "license": "ISC", - "dependencies": { - "foreground-child": "^3.1.0", - "jackspeak": "^3.1.2", - "minimatch": "^9.0.4", - "minipass": "^7.1.2", - "package-json-from-dist": "^1.0.0", - "path-scurry": "^1.11.1" - }, - "bin": { - "glob": "dist/esm/bin.mjs" - }, - "funding": { - "url": "https://github.com/sponsors/isaacs" - } - }, - "node_modules/@npmcli/package-json/node_modules/minimatch": { - "version": "9.0.5", - "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.5.tgz", - "integrity": "sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==", - "dev": true, - "license": "ISC", - "dependencies": { - "brace-expansion": "^2.0.1" - }, - "engines": { - "node": ">=16 || 14 >=14.17" - }, - "funding": { - "url": "https://github.com/sponsors/isaacs" - } - }, - "node_modules/@npmcli/package-json/node_modules/semver": { - "version": "7.6.3", - "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", - "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", - "dev": true, - "license": "ISC", - "bin": { - "semver": "bin/semver.js" - }, - "engines": { - "node": ">=10" - } - }, "node_modules/@npmcli/promise-spawn": { "version": "7.0.2", "resolved": "https://registry.npmjs.org/@npmcli/promise-spawn/-/promise-spawn-7.0.2.tgz", @@ -766,15 +534,15 @@ "license": "MIT" }, "node_modules/@stylistic/eslint-plugin": { - "version": "2.9.0", - "resolved": "https://registry.npmjs.org/@stylistic/eslint-plugin/-/eslint-plugin-2.9.0.tgz", - "integrity": "sha512-OrDyFAYjBT61122MIY1a3SfEgy3YCMgt2vL4eoPmvTwDBwyQhAXurxNQznlRD/jESNfYWfID8Ej+31LljvF7Xg==", + "version": "2.13.0", + "resolved": "https://registry.npmjs.org/@stylistic/eslint-plugin/-/eslint-plugin-2.13.0.tgz", + "integrity": "sha512-RnO1SaiCFHn666wNz2QfZEFxvmiNRqhzaMXHXxXXKt+MEP7aajlPxUSMIQpKAaJfverpovEYqjBOXDq6dDcaOQ==", "dev": true, "license": "MIT", "dependencies": { - "@typescript-eslint/utils": "^8.8.0", - "eslint-visitor-keys": "^4.1.0", - "espree": "^10.2.0", + "@typescript-eslint/utils": "^8.13.0", + "eslint-visitor-keys": "^4.2.0", + "espree": "^10.3.0", "estraverse": "^5.3.0", "picomatch": "^4.0.2" }, @@ -785,41 +553,6 @@ "eslint": ">=8.40.0" } }, - "node_modules/@stylistic/eslint-plugin/node_modules/picomatch": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-4.0.2.tgz", - "integrity": "sha512-M7BAV6Rlcy5u+m6oPhAPFgJTzAioX/6B0DxyvDlo9l8+T3nLKbrczg2WLUyzd45L8RqfUMyGPzekbMvX2Ldkwg==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/sponsors/jonschlinkert" - } - }, - "node_modules/@torchlight-api/torchlight-cli": { - "version": "0.1.7", - "resolved": "https://registry.npmjs.org/@torchlight-api/torchlight-cli/-/torchlight-cli-0.1.7.tgz", - "integrity": "sha512-sHph49Nx/VfzwDsb43v6AQIDZQa/YQ1LtGKTmN/rEBJoW0ctMXUQUJ1c75rNQ/1n2rYLbQLf7s008/jgLvkEDg==", - "dev": true, - "license": "MIT", - "dependencies": { - "axios": "^0.21.1", - "chalk": "^4.1.2", - "cheerio": "^1.0.0-rc.10", - "chokidar": "^3.5.2", - "commander": "^8.1.0", - "fs-extra": "^10.0.0", - "inquirer": "^8.1.2", - "lodash.chunk": "^4.2.0", - "lodash.get": "^4.4.2", - "md5": "^2.3.0" - }, - "bin": { - "torchlight": "dist/bin/torchlight.cjs.js" - } - }, "node_modules/@types/concat-stream": { "version": "2.0.3", "resolved": "https://registry.npmjs.org/@types/concat-stream/-/concat-stream-2.0.3.tgz", @@ -906,20 +639,20 @@ } }, "node_modules/@types/ms": { - "version": "0.7.34", - "resolved": "https://registry.npmjs.org/@types/ms/-/ms-0.7.34.tgz", - "integrity": "sha512-nG96G3Wp6acyAgJqGasjODb+acrI7KltPiRxzHPXnP3NgI28bpQDRv53olbqGXbfcgF5aiiHmO3xpwEpS5Ld9g==", + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/@types/ms/-/ms-2.1.0.tgz", + "integrity": "sha512-GsCCIZDE/p3i96vtEqx+7dBUGXrc7zeSK3wwPHIaRThS+9OhWIXRqzs4d6k1SVU8g91DrNRWxWUGhp5KXQb2VA==", "dev": true, "license": "MIT" }, "node_modules/@types/node": { - "version": "20.16.11", - "resolved": "https://registry.npmjs.org/@types/node/-/node-20.16.11.tgz", - "integrity": "sha512-y+cTCACu92FyA5fgQSAI8A1H429g7aSK2HsO7K4XYUWc4dY5IUz55JSDIYT6/VsOLfGy8vmvQYC2hfb0iF16Uw==", + "version": "22.13.10", + "resolved": "https://registry.npmjs.org/@types/node/-/node-22.13.10.tgz", + "integrity": "sha512-I6LPUvlRH+O6VRUqYOcMudhaIdUVWfsjnZavnsraHvpBwaEyMN29ry+0UVJhImYL16xsscu0aske3yA+uPOWfw==", "dev": true, "license": "MIT", "dependencies": { - "undici-types": "~6.19.2" + "undici-types": "~6.20.0" } }, "node_modules/@types/supports-color": { @@ -944,14 +677,14 @@ "license": "MIT" }, "node_modules/@typescript-eslint/scope-manager": { - "version": "8.9.0", - "resolved": "https://registry.npmjs.org/@typescript-eslint/scope-manager/-/scope-manager-8.9.0.tgz", - "integrity": "sha512-bZu9bUud9ym1cabmOYH9S6TnbWRzpklVmwqICeOulTCZ9ue2/pczWzQvt/cGj2r2o1RdKoZbuEMalJJSYw3pHQ==", + "version": "8.26.1", + "resolved": "https://registry.npmjs.org/@typescript-eslint/scope-manager/-/scope-manager-8.26.1.tgz", + "integrity": "sha512-6EIvbE5cNER8sqBu6V7+KeMZIC1664d2Yjt+B9EWUXrsyWpxx4lEZrmvxgSKRC6gX+efDL/UY9OpPZ267io3mg==", "dev": true, "license": "MIT", "dependencies": { - "@typescript-eslint/types": "8.9.0", - "@typescript-eslint/visitor-keys": "8.9.0" + "@typescript-eslint/types": "8.26.1", + "@typescript-eslint/visitor-keys": "8.26.1" }, "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -962,9 +695,9 @@ } }, "node_modules/@typescript-eslint/types": { - "version": "8.9.0", - "resolved": "https://registry.npmjs.org/@typescript-eslint/types/-/types-8.9.0.tgz", - "integrity": "sha512-SjgkvdYyt1FAPhU9c6FiYCXrldwYYlIQLkuc+LfAhCna6ggp96ACncdtlbn8FmnG72tUkXclrDExOpEYf1nfJQ==", + "version": "8.26.1", + "resolved": "https://registry.npmjs.org/@typescript-eslint/types/-/types-8.26.1.tgz", + "integrity": "sha512-n4THUQW27VmQMx+3P+B0Yptl7ydfceUj4ON/AQILAASwgYdZ/2dhfymRMh5egRUrvK5lSmaOm77Ry+lmXPOgBQ==", "dev": true, "license": "MIT", "engines": { @@ -976,20 +709,20 @@ } }, "node_modules/@typescript-eslint/typescript-estree": { - "version": "8.9.0", - "resolved": "https://registry.npmjs.org/@typescript-eslint/typescript-estree/-/typescript-estree-8.9.0.tgz", - "integrity": "sha512-9iJYTgKLDG6+iqegehc5+EqE6sqaee7kb8vWpmHZ86EqwDjmlqNNHeqDVqb9duh+BY6WCNHfIGvuVU3Tf9Db0g==", + "version": "8.26.1", + "resolved": "https://registry.npmjs.org/@typescript-eslint/typescript-estree/-/typescript-estree-8.26.1.tgz", + "integrity": "sha512-yUwPpUHDgdrv1QJ7YQal3cMVBGWfnuCdKbXw1yyjArax3353rEJP1ZA+4F8nOlQ3RfS2hUN/wze3nlY+ZOhvoA==", "dev": true, - "license": "BSD-2-Clause", + "license": "MIT", "dependencies": { - "@typescript-eslint/types": "8.9.0", - "@typescript-eslint/visitor-keys": "8.9.0", + "@typescript-eslint/types": "8.26.1", + "@typescript-eslint/visitor-keys": "8.26.1", "debug": "^4.3.4", "fast-glob": "^3.3.2", "is-glob": "^4.0.3", "minimatch": "^9.0.4", "semver": "^7.6.0", - "ts-api-utils": "^1.3.0" + "ts-api-utils": "^2.0.1" }, "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -998,62 +731,21 @@ "type": "opencollective", "url": "https://opencollective.com/typescript-eslint" }, - "peerDependenciesMeta": { - "typescript": { - "optional": true - } - } - }, - "node_modules/@typescript-eslint/typescript-estree/node_modules/brace-expansion": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", - "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", - "dev": true, - "license": "MIT", - "dependencies": { - "balanced-match": "^1.0.0" - } - }, - "node_modules/@typescript-eslint/typescript-estree/node_modules/minimatch": { - "version": "9.0.5", - "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.5.tgz", - "integrity": "sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==", - "dev": true, - "license": "ISC", - "dependencies": { - "brace-expansion": "^2.0.1" - }, - "engines": { - "node": ">=16 || 14 >=14.17" - }, - "funding": { - "url": "https://github.com/sponsors/isaacs" - } - }, - "node_modules/@typescript-eslint/typescript-estree/node_modules/semver": { - "version": "7.6.3", - "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", - "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", - "dev": true, - "license": "ISC", - "bin": { - "semver": "bin/semver.js" - }, - "engines": { - "node": ">=10" + "peerDependencies": { + "typescript": ">=4.8.4 <5.9.0" } }, "node_modules/@typescript-eslint/utils": { - "version": "8.9.0", - "resolved": "https://registry.npmjs.org/@typescript-eslint/utils/-/utils-8.9.0.tgz", - "integrity": "sha512-PKgMmaSo/Yg/F7kIZvrgrWa1+Vwn036CdNUvYFEkYbPwOH4i8xvkaRlu148W3vtheWK9ckKRIz7PBP5oUlkrvQ==", + "version": "8.26.1", + "resolved": "https://registry.npmjs.org/@typescript-eslint/utils/-/utils-8.26.1.tgz", + "integrity": "sha512-V4Urxa/XtSUroUrnI7q6yUTD3hDtfJ2jzVfeT3VK0ciizfK2q/zGC0iDh1lFMUZR8cImRrep6/q0xd/1ZGPQpg==", "dev": true, "license": "MIT", "dependencies": { "@eslint-community/eslint-utils": "^4.4.0", - "@typescript-eslint/scope-manager": "8.9.0", - "@typescript-eslint/types": "8.9.0", - "@typescript-eslint/typescript-estree": "8.9.0" + "@typescript-eslint/scope-manager": "8.26.1", + "@typescript-eslint/types": "8.26.1", + "@typescript-eslint/typescript-estree": "8.26.1" }, "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -1063,18 +755,19 @@ "url": "https://opencollective.com/typescript-eslint" }, "peerDependencies": { - "eslint": "^8.57.0 || ^9.0.0" + "eslint": "^8.57.0 || ^9.0.0", + "typescript": ">=4.8.4 <5.9.0" } }, "node_modules/@typescript-eslint/visitor-keys": { - "version": "8.9.0", - "resolved": "https://registry.npmjs.org/@typescript-eslint/visitor-keys/-/visitor-keys-8.9.0.tgz", - "integrity": "sha512-Ht4y38ubk4L5/U8xKUBfKNYGmvKvA1CANoxiTRMM+tOLk3lbF3DvzZCxJCRSE+2GdCMSh6zq9VZJc3asc1XuAA==", + "version": "8.26.1", + "resolved": "https://registry.npmjs.org/@typescript-eslint/visitor-keys/-/visitor-keys-8.26.1.tgz", + "integrity": "sha512-AjOC3zfnxd6S4Eiy3jwktJPclqhFHNyd8L6Gycf9WUPoKZpgM5PjkxY1X7uSy61xVpiJDhhk7XT2NVsN3ALTWg==", "dev": true, "license": "MIT", "dependencies": { - "@typescript-eslint/types": "8.9.0", - "eslint-visitor-keys": "^3.4.3" + "@typescript-eslint/types": "8.26.1", + "eslint-visitor-keys": "^4.2.0" }, "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -1084,23 +777,10 @@ "url": "https://opencollective.com/typescript-eslint" } }, - "node_modules/@typescript-eslint/visitor-keys/node_modules/eslint-visitor-keys": { - "version": "3.4.3", - "resolved": "https://registry.npmjs.org/eslint-visitor-keys/-/eslint-visitor-keys-3.4.3.tgz", - "integrity": "sha512-wpc+LXeiyiisxPlEkUzU6svyS1frIO3Mgxj1fdy7Pm8Ygzguax2N3Fa/D/ag1WqbOprdI+uY6wMUl8/a2G+iag==", - "dev": true, - "license": "Apache-2.0", - "engines": { - "node": "^12.22.0 || ^14.17.0 || >=16.0.0" - }, - "funding": { - "url": "https://opencollective.com/eslint" - } - }, "node_modules/@ungap/structured-clone": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/@ungap/structured-clone/-/structured-clone-1.2.0.tgz", - "integrity": "sha512-zuVdFrMJiuCDQUMCzQaD6KL28MjnqqN8XnAqiEq9PNm/hCPTSGfrXCOfwj1ow4LFb/tNymJPwsNbVePc1xFqrQ==", + "version": "1.3.0", + "resolved": "https://registry.npmjs.org/@ungap/structured-clone/-/structured-clone-1.3.0.tgz", + "integrity": "sha512-WmoN8qaIAo7WTYWbAZuG8PYEhn5fkz7dZrqTBZ7dtt//lL2Gwms1IcnQ5yHqjDfX8Ft5j4YzDM23f87zBfDe9g==", "dev": true, "license": "ISC" }, @@ -1115,9 +795,9 @@ } }, "node_modules/acorn": { - "version": "8.13.0", - "resolved": "https://registry.npmjs.org/acorn/-/acorn-8.13.0.tgz", - "integrity": "sha512-8zSiw54Oxrdym50NlZ9sUusyO1Z1ZchgRLWRaK6c86XJFClyCgFKetdowBg5bKxyp/u+CDBJG4Mpp0m3HLZl9w==", + "version": "8.14.1", + "resolved": "https://registry.npmjs.org/acorn/-/acorn-8.14.1.tgz", + "integrity": "sha512-OvQ/2pUDKmgfCg++xsTX1wGxfTaszcHVcTctW4UJB4hibJx2HXxxO5UmVgyjMa+ZDsiaf5wWLXYpRWMmBI0QHg==", "dev": true, "license": "MIT", "bin": { @@ -1154,43 +834,17 @@ "url": "https://github.com/sponsors/epoberezkin" } }, - "node_modules/ansi-escapes": { - "version": "4.3.2", - "resolved": "https://registry.npmjs.org/ansi-escapes/-/ansi-escapes-4.3.2.tgz", - "integrity": "sha512-gKXj5ALrKWQLsYG9jlTRmR/xKluxHV+Z9QEwNIgCfM1/uwPMCuzVVnh5mwTd+OuBZcwSIMbqssNWRm1lE51QaQ==", + "node_modules/ansi-regex": { + "version": "6.1.0", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.1.0.tgz", + "integrity": "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA==", "dev": true, "license": "MIT", - "dependencies": { - "type-fest": "^0.21.3" - }, - "engines": { - "node": ">=8" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/ansi-escapes/node_modules/type-fest": { - "version": "0.21.3", - "resolved": "https://registry.npmjs.org/type-fest/-/type-fest-0.21.3.tgz", - "integrity": "sha512-t0rzBq87m3fVcduHDUFhKmyyX+9eo6WQjZvf51Ea/M0Q7+T374Jp1aUiyUl0GKxp8M/OETVHSDvmkyPgvX+X2w==", - "dev": true, - "license": "(MIT OR CC0-1.0)", "engines": { - "node": ">=10" + "node": ">=12" }, "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/ansi-regex": { - "version": "5.0.1", - "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz", - "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=8" + "url": "https://github.com/chalk/ansi-regex?sponsor=1" } }, "node_modules/ansi-styles": { @@ -1223,6 +877,19 @@ "node": ">= 8" } }, + "node_modules/anymatch/node_modules/picomatch": { + "version": "2.3.1", + "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz", + "integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==", + "dev": true, + "license": "MIT", + "engines": { + "node": ">=8.6" + }, + "funding": { + "url": "https://github.com/sponsors/jonschlinkert" + } + }, "node_modules/argparse": { "version": "2.0.1", "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz", @@ -1231,14 +898,14 @@ "license": "Python-2.0" }, "node_modules/array-buffer-byte-length": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/array-buffer-byte-length/-/array-buffer-byte-length-1.0.1.tgz", - "integrity": "sha512-ahC5W1xgou+KTXix4sAO8Ki12Q+jf4i0+tmk3sC+zgcynshkHxzpXdImBehiUYKKKDwvfFiJl1tZt6ewscS1Mg==", + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/array-buffer-byte-length/-/array-buffer-byte-length-1.0.2.tgz", + "integrity": "sha512-LHE+8BuR7RYGDKvnrmcuSq3tDcKv9OFEXQt/HpbZhY7V6h0zlUXutnAD82GiFx9rdieCMjkvtcsPqBwgUl1Iiw==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.5", - "is-array-buffer": "^3.0.4" + "call-bound": "^1.0.3", + "is-array-buffer": "^3.0.5" }, "engines": { "node": ">= 0.4" @@ -1269,18 +936,19 @@ } }, "node_modules/array.prototype.findlastindex": { - "version": "1.2.5", - "resolved": "https://registry.npmjs.org/array.prototype.findlastindex/-/array.prototype.findlastindex-1.2.5.tgz", - "integrity": "sha512-zfETvRFA8o7EiNn++N5f/kaCw221hrpGsDmcpndVupkPzEc1Wuf3VgC0qby1BbHs7f5DVYjgtEU2LLh5bqeGfQ==", + "version": "1.2.6", + "resolved": "https://registry.npmjs.org/array.prototype.findlastindex/-/array.prototype.findlastindex-1.2.6.tgz", + "integrity": "sha512-F/TKATkzseUExPlfvmwQKGITM3DGTK+vkAsCZoDc5daVygbJBnjEUCbgkAvVFsgfXfX4YIqZ/27G3k3tdXrTxQ==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.7", + "call-bind": "^1.0.8", + "call-bound": "^1.0.4", "define-properties": "^1.2.1", - "es-abstract": "^1.23.2", + "es-abstract": "^1.23.9", "es-errors": "^1.3.0", - "es-object-atoms": "^1.0.0", - "es-shim-unscopables": "^1.0.2" + "es-object-atoms": "^1.1.1", + "es-shim-unscopables": "^1.1.0" }, "engines": { "node": ">= 0.4" @@ -1290,16 +958,16 @@ } }, "node_modules/array.prototype.flat": { - "version": "1.3.2", - "resolved": "https://registry.npmjs.org/array.prototype.flat/-/array.prototype.flat-1.3.2.tgz", - "integrity": "sha512-djYB+Zx2vLewY8RWlNCUdHjDXs2XOgm602S9E7P/UpHgfeHL00cRiIF+IN/G/aUJ7kGPb6yO/ErDI5V2s8iycA==", + "version": "1.3.3", + "resolved": "https://registry.npmjs.org/array.prototype.flat/-/array.prototype.flat-1.3.3.tgz", + "integrity": "sha512-rwG/ja1neyLqCuGZ5YYrznA62D4mZXg0i1cIskIUKSiqF3Cje9/wXAls9B9s1Wa2fomMsIv8czB8jZcPmxCXFg==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.2", - "define-properties": "^1.2.0", - "es-abstract": "^1.22.1", - "es-shim-unscopables": "^1.0.0" + "call-bind": "^1.0.8", + "define-properties": "^1.2.1", + "es-abstract": "^1.23.5", + "es-shim-unscopables": "^1.0.2" }, "engines": { "node": ">= 0.4" @@ -1309,16 +977,16 @@ } }, "node_modules/array.prototype.flatmap": { - "version": "1.3.2", - "resolved": "https://registry.npmjs.org/array.prototype.flatmap/-/array.prototype.flatmap-1.3.2.tgz", - "integrity": "sha512-Ewyx0c9PmpcsByhSW4r+9zDU7sGjFc86qf/kKtuSCRdhfbk0SNLLkaT5qvcHnRGgc5NP/ly/y+qkXkqONX54CQ==", + "version": "1.3.3", + "resolved": "https://registry.npmjs.org/array.prototype.flatmap/-/array.prototype.flatmap-1.3.3.tgz", + "integrity": "sha512-Y7Wt51eKJSyi80hFrJCePGGNo5ktJCslFuboqJsbf57CCPcm5zztluPlc4/aD8sWsKvlwatezpV4U1efk8kpjg==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.2", - "define-properties": "^1.2.0", - "es-abstract": "^1.22.1", - "es-shim-unscopables": "^1.0.0" + "call-bind": "^1.0.8", + "define-properties": "^1.2.1", + "es-abstract": "^1.23.5", + "es-shim-unscopables": "^1.0.2" }, "engines": { "node": ">= 0.4" @@ -1328,20 +996,19 @@ } }, "node_modules/arraybuffer.prototype.slice": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/arraybuffer.prototype.slice/-/arraybuffer.prototype.slice-1.0.3.tgz", - "integrity": "sha512-bMxMKAjg13EBSVscxTaYA4mRc5t1UAXa2kXiGTNfZ079HIWXEkKmkgFrh/nJqamaLSrXO5H4WFFkPEaLJWbs3A==", + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/arraybuffer.prototype.slice/-/arraybuffer.prototype.slice-1.0.4.tgz", + "integrity": "sha512-BNoCY6SXXPQ7gF2opIP4GBE+Xw7U+pHMYKuzjgCN3GwiaIR09UUeKfheyIry77QtrCBlC0KK0q5/TER/tYh3PQ==", "dev": true, "license": "MIT", "dependencies": { "array-buffer-byte-length": "^1.0.1", - "call-bind": "^1.0.5", + "call-bind": "^1.0.8", "define-properties": "^1.2.1", - "es-abstract": "^1.22.3", - "es-errors": "^1.2.1", - "get-intrinsic": "^1.2.3", - "is-array-buffer": "^3.0.4", - "is-shared-array-buffer": "^1.0.2" + "es-abstract": "^1.23.5", + "es-errors": "^1.3.0", + "get-intrinsic": "^1.2.6", + "is-array-buffer": "^3.0.4" }, "engines": { "node": ">= 0.4" @@ -1350,6 +1017,16 @@ "url": "https://github.com/sponsors/ljharb" } }, + "node_modules/async-function": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/async-function/-/async-function-1.0.0.tgz", + "integrity": "sha512-hsU18Ae8CDTR6Kgu9DYf0EbCr/a5iGL0rytQDobUcdpYOKokk8LEjVphnXkDkgpi0wYVsqrXuP0bZxJaTqdgoA==", + "dev": true, + "license": "MIT", + "engines": { + "node": ">= 0.4" + } + }, "node_modules/available-typed-arrays": { "version": "1.0.7", "resolved": "https://registry.npmjs.org/available-typed-arrays/-/available-typed-arrays-1.0.7.tgz", @@ -1366,16 +1043,6 @@ "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/axios": { - "version": "0.21.4", - "resolved": "https://registry.npmjs.org/axios/-/axios-0.21.4.tgz", - "integrity": "sha512-ut5vewkiu8jjGBdqpM44XxjuCjq9LAKeHVmoVfHVzy8eHgxxq8SbAVQNovDA8mVi05kP0Ea/n/UzcSHcTJQfNg==", - "dev": true, - "license": "MIT", - "dependencies": { - "follow-redirects": "^1.14.0" - } - }, "node_modules/bail": { "version": "2.0.2", "resolved": "https://registry.npmjs.org/bail/-/bail-2.0.2.tgz", @@ -1394,27 +1061,6 @@ "dev": true, "license": "MIT" }, - "node_modules/base64-js": { - "version": "1.5.1", - "resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.5.1.tgz", - "integrity": "sha512-AKpaYlHn8t4SVbOHCy+b5+KKgvR4vrsD8vbvrbiQJps7fKDTkjkDry6ji0rUJjC0kzbNePLwzxq8iypo41qeWA==", - "dev": true, - "funding": [ - { - "type": "github", - "url": "https://github.com/sponsors/feross" - }, - { - "type": "patreon", - "url": "https://www.patreon.com/feross" - }, - { - "type": "consulting", - "url": "https://feross.org/support" - } - ], - "license": "MIT" - }, "node_modules/binary-extensions": { "version": "2.3.0", "resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.3.0.tgz", @@ -1428,34 +1074,14 @@ "url": "https://github.com/sponsors/sindresorhus" } }, - "node_modules/bl": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/bl/-/bl-4.1.0.tgz", - "integrity": "sha512-1W07cM9gS6DcLperZfFSj+bWLtaPGSOHWhPiGzXmvVJbRLdG82sH/Kn8EtW1VqWVA54AKf2h5k5BbnIbwF3h6w==", - "dev": true, - "license": "MIT", - "dependencies": { - "buffer": "^5.5.0", - "inherits": "^2.0.4", - "readable-stream": "^3.4.0" - } - }, - "node_modules/boolbase": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/boolbase/-/boolbase-1.0.0.tgz", - "integrity": "sha512-JZOSA7Mo9sNGB8+UjSgzdLtokWAky1zbztM3WRLCbZ70/3cTANmQmOdR7y2g+J0e2WXywy1yS468tY+IruqEww==", - "dev": true, - "license": "ISC" - }, "node_modules/brace-expansion": { - "version": "1.1.11", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz", - "integrity": "sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", + "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", "dev": true, "license": "MIT", "dependencies": { - "balanced-match": "^1.0.0", - "concat-map": "0.0.1" + "balanced-match": "^1.0.0" } }, "node_modules/braces": { @@ -1471,31 +1097,6 @@ "node": ">=8" } }, - "node_modules/buffer": { - "version": "5.7.1", - "resolved": "https://registry.npmjs.org/buffer/-/buffer-5.7.1.tgz", - "integrity": "sha512-EHcyIPBQ4BSGlvjB16k5KgAJ27CIsHY/2JBmCRReo48y9rQ3MaUzWX3KVlBa4U7MyX02HdVj0K7C3WaB3ju7FQ==", - "dev": true, - "funding": [ - { - "type": "github", - "url": "https://github.com/sponsors/feross" - }, - { - "type": "patreon", - "url": "https://www.patreon.com/feross" - }, - { - "type": "consulting", - "url": "https://feross.org/support" - } - ], - "license": "MIT", - "dependencies": { - "base64-js": "^1.3.1", - "ieee754": "^1.1.13" - } - }, "node_modules/buffer-from": { "version": "1.1.2", "resolved": "https://registry.npmjs.org/buffer-from/-/buffer-from-1.1.2.tgz", @@ -1504,17 +1105,47 @@ "license": "MIT" }, "node_modules/call-bind": { - "version": "1.0.7", - "resolved": "https://registry.npmjs.org/call-bind/-/call-bind-1.0.7.tgz", - "integrity": "sha512-GHTSNSYICQ7scH7sZ+M2rFopRoLh8t2bLSW6BbgrtLsahOIB5iyAVJf9GjWK3cYTDaMj4XdBpM1cA6pIS0Kv2w==", + "version": "1.0.8", + "resolved": "https://registry.npmjs.org/call-bind/-/call-bind-1.0.8.tgz", + "integrity": "sha512-oKlSFMcMwpUg2ednkhQ454wfWiU/ul3CkJe/PEHcTKuiX6RpbehUiFMXu13HalGZxfUwCQzZG747YXBn1im9ww==", "dev": true, "license": "MIT", "dependencies": { + "call-bind-apply-helpers": "^1.0.0", "es-define-property": "^1.0.0", - "es-errors": "^1.3.0", - "function-bind": "^1.1.2", "get-intrinsic": "^1.2.4", - "set-function-length": "^1.2.1" + "set-function-length": "^1.2.2" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/call-bind-apply-helpers": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/call-bind-apply-helpers/-/call-bind-apply-helpers-1.0.2.tgz", + "integrity": "sha512-Sp1ablJ0ivDkSzjcaJdxEunN5/XvksFJ2sMBFfq6x0ryhQV/2b/KwFe21cMpmHtPOSij8K99/wSfoEuTObmuMQ==", + "dev": true, + "license": "MIT", + "dependencies": { + "es-errors": "^1.3.0", + "function-bind": "^1.1.2" + }, + "engines": { + "node": ">= 0.4" + } + }, + "node_modules/call-bound": { + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/call-bound/-/call-bound-1.0.4.tgz", + "integrity": "sha512-+ys997U96po4Kx/ABpBCqhA9EuxJaQWDQg7295H4hBphv3IZg0boBKuwYpt4YXp6MZ5AmZQnU/tyMTlRpaSejg==", + "dev": true, + "license": "MIT", + "dependencies": { + "call-bind-apply-helpers": "^1.0.2", + "get-intrinsic": "^1.3.0" }, "engines": { "node": ">= 0.4" @@ -1605,67 +1236,6 @@ "url": "https://github.com/sponsors/wooorm" } }, - "node_modules/chardet": { - "version": "0.7.0", - "resolved": "https://registry.npmjs.org/chardet/-/chardet-0.7.0.tgz", - "integrity": "sha512-mT8iDcrh03qDGRRmoA2hmBJnxpllMR+0/0qlzjqZES6NdiWDcZkCNAk4rPFZ9Q85r27unkiNNg8ZOiwZXBHwcA==", - "dev": true, - "license": "MIT" - }, - "node_modules/charenc": { - "version": "0.0.2", - "resolved": "https://registry.npmjs.org/charenc/-/charenc-0.0.2.tgz", - "integrity": "sha512-yrLQ/yVUFXkzg7EDQsPieE/53+0RlaWTs+wBrvW36cyilJ2SaDWfl4Yj7MtLTXleV9uEKefbAGUPv2/iWSooRA==", - "dev": true, - "license": "BSD-3-Clause", - "engines": { - "node": "*" - } - }, - "node_modules/cheerio": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/cheerio/-/cheerio-1.0.0.tgz", - "integrity": "sha512-quS9HgjQpdaXOvsZz82Oz7uxtXiy6UIsIQcpBj7HRw2M63Skasm9qlDocAM7jNuaxdhpPU7c4kJN+gA5MCu4ww==", - "dev": true, - "license": "MIT", - "dependencies": { - "cheerio-select": "^2.1.0", - "dom-serializer": "^2.0.0", - "domhandler": "^5.0.3", - "domutils": "^3.1.0", - "encoding-sniffer": "^0.2.0", - "htmlparser2": "^9.1.0", - "parse5": "^7.1.2", - "parse5-htmlparser2-tree-adapter": "^7.0.0", - "parse5-parser-stream": "^7.1.2", - "undici": "^6.19.5", - "whatwg-mimetype": "^4.0.0" - }, - "engines": { - "node": ">=18.17" - }, - "funding": { - "url": "https://github.com/cheeriojs/cheerio?sponsor=1" - } - }, - "node_modules/cheerio-select": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/cheerio-select/-/cheerio-select-2.1.0.tgz", - "integrity": "sha512-9v9kG0LvzrlcungtnJtpGNxY+fzECQKhK4EGJX2vByejiMX84MFNQw4UxPJl3bFbTMw+Dfs37XaIkCwTZfLh4g==", - "dev": true, - "license": "BSD-2-Clause", - "dependencies": { - "boolbase": "^1.0.0", - "css-select": "^5.1.0", - "css-what": "^6.1.0", - "domelementtype": "^2.3.0", - "domhandler": "^5.0.3", - "domutils": "^3.0.1" - }, - "funding": { - "url": "https://github.com/sponsors/fb55" - } - }, "node_modules/chokidar": { "version": "3.6.0", "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.6.0.tgz", @@ -1705,9 +1275,9 @@ } }, "node_modules/ci-info": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/ci-info/-/ci-info-4.0.0.tgz", - "integrity": "sha512-TdHqgGf9odd8SXNuxtUBVx8Nv+qZOejE6qyqiy5NtbYYQOeFa6zmHkxlPzmaLxWWHsU6nJmB7AETdVPi+2NBUg==", + "version": "4.2.0", + "resolved": "https://registry.npmjs.org/ci-info/-/ci-info-4.2.0.tgz", + "integrity": "sha512-cYY9mypksY8NRqgDB1XD1RiJL338v/551niynFTGkZOO2LHuB2OmOYxDIe/ttN9AHwrqdum1360G3ald0W9kCg==", "dev": true, "funding": [ { @@ -1720,52 +1290,6 @@ "node": ">=8" } }, - "node_modules/cli-cursor": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/cli-cursor/-/cli-cursor-3.1.0.tgz", - "integrity": "sha512-I/zHAwsKf9FqGoXM4WWRACob9+SNukZTd94DWF57E4toouRulbCxcUh6RKUEOQlYTHJnzkPMySvPNaaSLNfLZw==", - "dev": true, - "license": "MIT", - "dependencies": { - "restore-cursor": "^3.1.0" - }, - "engines": { - "node": ">=8" - } - }, - "node_modules/cli-spinners": { - "version": "2.9.2", - "resolved": "https://registry.npmjs.org/cli-spinners/-/cli-spinners-2.9.2.tgz", - "integrity": "sha512-ywqV+5MmyL4E7ybXgKys4DugZbX0FC6LnwrhjuykIjnK9k8OQacQ7axGKnjDXWNhns0xot3bZI5h55H8yo9cJg==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=6" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/cli-width": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/cli-width/-/cli-width-3.0.0.tgz", - "integrity": "sha512-FxqpkPPwu1HjuN93Omfm4h8uIanXofW0RxVEW3k5RKx+mJJYSthzNhp32Kzxxy3YAEZ/Dc/EWN1vZRY0+kOhbw==", - "dev": true, - "license": "ISC", - "engines": { - "node": ">= 10" - } - }, - "node_modules/clone": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/clone/-/clone-1.0.4.tgz", - "integrity": "sha512-JQHZ2QMW6l3aH/j6xCqQThY/9OH4D/9ls34cgkUBiEeocRTU04tHfKPBsUK1PqZCUQM7GiA0IIXJSuXHI64Kbg==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=0.8" - } - }, "node_modules/collapse-white-space": { "version": "2.1.0", "resolved": "https://registry.npmjs.org/collapse-white-space/-/collapse-white-space-2.1.0.tgz", @@ -1808,16 +1332,6 @@ "url": "https://github.com/sponsors/wooorm" } }, - "node_modules/commander": { - "version": "8.3.0", - "resolved": "https://registry.npmjs.org/commander/-/commander-8.3.0.tgz", - "integrity": "sha512-OkTL9umf+He2DZkUq8f8J9of7yL6RJKI24dVITBmNfZBmri9zYZQrKkuXiKhyfPSu8tUhnVBB1iKXevvnlR4Ww==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">= 12" - } - }, "node_modules/concat-map": { "version": "0.0.1", "resolved": "https://registry.npmjs.org/concat-map/-/concat-map-0.0.1.tgz", @@ -1842,9 +1356,9 @@ } }, "node_modules/cross-spawn": { - "version": "7.0.3", - "resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.3.tgz", - "integrity": "sha512-iRDPJKUPVEND7dHPO8rkbOnPpyDygcDFtWjpeWNCgy8WP2rXcxXL8TskReQl6OrB2G7+UJrags1q15Fudc7G6w==", + "version": "7.0.6", + "resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.6.tgz", + "integrity": "sha512-uV2QOWP2nWzsy2aMp8aRibhi9dlzF5Hgh5SHaB9OiTGEyDTiJJyx0uy51QXdyWbtAHNua4XJzUKca3OzKUd3vA==", "dev": true, "license": "MIT", "dependencies": { @@ -1856,56 +1370,16 @@ "node": ">= 8" } }, - "node_modules/crypt": { - "version": "0.0.2", - "resolved": "https://registry.npmjs.org/crypt/-/crypt-0.0.2.tgz", - "integrity": "sha512-mCxBlsHFYh9C+HVpiEacem8FEBnMXgU9gy4zmNC+SXAZNB/1idgp/aulFJ4FgCi7GPEVbfyng092GqL2k2rmow==", - "dev": true, - "license": "BSD-3-Clause", - "engines": { - "node": "*" - } - }, - "node_modules/css-select": { - "version": "5.1.0", - "resolved": "https://registry.npmjs.org/css-select/-/css-select-5.1.0.tgz", - "integrity": "sha512-nwoRF1rvRRnnCqqY7updORDsuqKzqYJ28+oSMaJMMgOauh3fvwHqMS7EZpIPqK8GL+g9mKxF1vP/ZjSeNjEVHg==", - "dev": true, - "license": "BSD-2-Clause", - "dependencies": { - "boolbase": "^1.0.0", - "css-what": "^6.1.0", - "domhandler": "^5.0.2", - "domutils": "^3.0.1", - "nth-check": "^2.0.1" - }, - "funding": { - "url": "https://github.com/sponsors/fb55" - } - }, - "node_modules/css-what": { - "version": "6.1.0", - "resolved": "https://registry.npmjs.org/css-what/-/css-what-6.1.0.tgz", - "integrity": "sha512-HTUrgRJ7r4dsZKU6GjmpfRK1O76h97Z8MfS1G0FozR+oF2kG6Vfe8JE6zwrkbxigziPHinCJ+gCPjA9EaBDtRw==", - "dev": true, - "license": "BSD-2-Clause", - "engines": { - "node": ">= 6" - }, - "funding": { - "url": "https://github.com/sponsors/fb55" - } - }, "node_modules/data-view-buffer": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/data-view-buffer/-/data-view-buffer-1.0.1.tgz", - "integrity": "sha512-0lht7OugA5x3iJLOWFhWK/5ehONdprk0ISXqVFn/NFrDu+cuc8iADFrGQz5BnRK7LLU3JmkbXSxaqX+/mXYtUA==", + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/data-view-buffer/-/data-view-buffer-1.0.2.tgz", + "integrity": "sha512-EmKO5V3OLXh1rtK2wgXRansaK1/mtVdTUEiEI0W8RkvgT05kfxaH29PliLnpLP73yYO6142Q72QNa8Wx/A5CqQ==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.6", + "call-bound": "^1.0.3", "es-errors": "^1.3.0", - "is-data-view": "^1.0.1" + "is-data-view": "^1.0.2" }, "engines": { "node": ">= 0.4" @@ -1915,31 +1389,31 @@ } }, "node_modules/data-view-byte-length": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/data-view-byte-length/-/data-view-byte-length-1.0.1.tgz", - "integrity": "sha512-4J7wRJD3ABAzr8wP+OcIcqq2dlUKp4DVflx++hs5h5ZKydWMI6/D/fAot+yh6g2tHh8fLFTvNOaVN357NvSrOQ==", + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/data-view-byte-length/-/data-view-byte-length-1.0.2.tgz", + "integrity": "sha512-tuhGbE6CfTM9+5ANGf+oQb72Ky/0+s3xKUpHvShfiz2RxMFgFPjsXuRLBVMtvMs15awe45SRb83D6wH4ew6wlQ==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.7", + "call-bound": "^1.0.3", "es-errors": "^1.3.0", - "is-data-view": "^1.0.1" + "is-data-view": "^1.0.2" }, "engines": { "node": ">= 0.4" }, "funding": { - "url": "https://github.com/sponsors/ljharb" + "url": "https://github.com/sponsors/inspect-js" } }, "node_modules/data-view-byte-offset": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/data-view-byte-offset/-/data-view-byte-offset-1.0.0.tgz", - "integrity": "sha512-t/Ygsytq+R995EJ5PZlD4Cu56sWa8InXySaViRzw9apusqsOO2bQP+SbYzAhR0pFKoB+43lYy8rWban9JSuXnA==", + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/data-view-byte-offset/-/data-view-byte-offset-1.0.1.tgz", + "integrity": "sha512-BS8PfmtDGnrgYdOonGZQdLZslWIeCGFP9tpan0hi1Co2Zr2NKADsvGYA8XxuG/4UWgJ6Cjtv+YJnB6MM69QGlQ==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.6", + "call-bound": "^1.0.2", "es-errors": "^1.3.0", "is-data-view": "^1.0.1" }, @@ -1951,13 +1425,13 @@ } }, "node_modules/debug": { - "version": "4.3.5", - "resolved": "https://registry.npmjs.org/debug/-/debug-4.3.5.tgz", - "integrity": "sha512-pt0bNEmneDIvdL1Xsd9oDQ/wrQRkXDT4AUWlNZNPKvW5x/jyO9VFXkJUP07vQ2upmw5PlaITaPKc31jK13V+jg==", + "version": "4.4.0", + "resolved": "https://registry.npmjs.org/debug/-/debug-4.4.0.tgz", + "integrity": "sha512-6WTZ/IxCY/T6BALoZHaE4ctp9xm+Z5kY/pzYaCHRFeyVhojxlrm+46y68HA6hr0TcwEssoxNiDEUJQjfPZ/RYA==", "dev": true, "license": "MIT", "dependencies": { - "ms": "2.1.2" + "ms": "^2.1.3" }, "engines": { "node": ">=6.0" @@ -1969,9 +1443,9 @@ } }, "node_modules/decode-named-character-reference": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/decode-named-character-reference/-/decode-named-character-reference-1.0.2.tgz", - "integrity": "sha512-O8x12RzrUF8xyVcY0KJowWsmaJxQbmy0/EtnNtHRpsOcT7dFk5W598coHqBVpmWo1oQQfsCqfCmkZN5DJrZVdg==", + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/decode-named-character-reference/-/decode-named-character-reference-1.1.0.tgz", + "integrity": "sha512-Wy+JTSbFThEOXQIR2L6mxJvEs+veIzpmqD7ynWxMXGpnk3smkHQOp6forLdHsKpAMW9iJpaBBIxz285t1n1C3w==", "dev": true, "license": "MIT", "dependencies": { @@ -1989,19 +1463,6 @@ "dev": true, "license": "MIT" }, - "node_modules/defaults": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/defaults/-/defaults-1.0.4.tgz", - "integrity": "sha512-eFuaLoy/Rxalv2kr+lqMlUnrDWV+3j4pljOIJgLIhI058IQfWJ7vXhyEIHu+HtC738klGALYxOKDO0bQP3tg8A==", - "dev": true, - "license": "MIT", - "dependencies": { - "clone": "^1.0.2" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, "node_modules/define-data-property": { "version": "1.1.4", "resolved": "https://registry.npmjs.org/define-data-property/-/define-data-property-1.1.4.tgz", @@ -2053,98 +1514,41 @@ "resolved": "https://registry.npmjs.org/devlop/-/devlop-1.1.0.tgz", "integrity": "sha512-RWmIqhcFf1lRYBvNmr7qTNuyCt/7/ns2jbpp1+PalgE/rDQcBT0fioSMUpJ93irlUhC5hrg4cYqe6U+0ImW0rA==", "dev": true, - "license": "MIT", - "dependencies": { - "dequal": "^2.0.0" - }, - "funding": { - "type": "github", - "url": "https://github.com/sponsors/wooorm" - } - }, - "node_modules/doctrine": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/doctrine/-/doctrine-2.1.0.tgz", - "integrity": "sha512-35mSku4ZXK0vfCuHEDAwt55dg2jNajHZ1odvF+8SSr82EsZY4QmXfuWso8oEd8zRhVObSN18aM0CjSdoBX7zIw==", - "dev": true, - "license": "Apache-2.0", - "dependencies": { - "esutils": "^2.0.2" - }, - "engines": { - "node": ">=0.10.0" - } - }, - "node_modules/dom-serializer": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/dom-serializer/-/dom-serializer-2.0.0.tgz", - "integrity": "sha512-wIkAryiqt/nV5EQKqQpo3SToSOV9J0DnbJqwK7Wv/Trc92zIAYZ4FlMu+JPFW1DfGFt81ZTCGgDEabffXeLyJg==", - "dev": true, - "license": "MIT", - "dependencies": { - "domelementtype": "^2.3.0", - "domhandler": "^5.0.2", - "entities": "^4.2.0" - }, - "funding": { - "url": "https://github.com/cheeriojs/dom-serializer?sponsor=1" - } - }, - "node_modules/domelementtype": { - "version": "2.3.0", - "resolved": "https://registry.npmjs.org/domelementtype/-/domelementtype-2.3.0.tgz", - "integrity": "sha512-OLETBj6w0OsagBwdXnPdN0cnMfF9opN69co+7ZrbfPGrdpPVNBUj02spi6B1N7wChLQiPn4CSH/zJvXw56gmHw==", - "dev": true, - "funding": [ - { - "type": "github", - "url": "https://github.com/sponsors/fb55" - } - ], - "license": "BSD-2-Clause" - }, - "node_modules/domhandler": { - "version": "5.0.3", - "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-5.0.3.tgz", - "integrity": "sha512-cgwlv/1iFQiFnU96XXgROh8xTeetsnJiDsTc7TYCLFd9+/WNkIqPTxiM/8pSd8VIrhXGTf1Ny1q1hquVqDJB5w==", - "dev": true, - "license": "BSD-2-Clause", + "license": "MIT", "dependencies": { - "domelementtype": "^2.3.0" - }, - "engines": { - "node": ">= 4" + "dequal": "^2.0.0" }, "funding": { - "url": "https://github.com/fb55/domhandler?sponsor=1" + "type": "github", + "url": "https://github.com/sponsors/wooorm" } }, - "node_modules/domutils": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/domutils/-/domutils-3.1.0.tgz", - "integrity": "sha512-H78uMmQtI2AhgDJjWeQmHwJJ2bLPD3GMmO7Zja/ZZh84wkm+4ut+IUnUdRa8uCGX88DiVx1j6FRe1XfxEgjEZA==", + "node_modules/doctrine": { + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/doctrine/-/doctrine-2.1.0.tgz", + "integrity": "sha512-35mSku4ZXK0vfCuHEDAwt55dg2jNajHZ1odvF+8SSr82EsZY4QmXfuWso8oEd8zRhVObSN18aM0CjSdoBX7zIw==", "dev": true, - "license": "BSD-2-Clause", + "license": "Apache-2.0", "dependencies": { - "dom-serializer": "^2.0.0", - "domelementtype": "^2.3.0", - "domhandler": "^5.0.3" + "esutils": "^2.0.2" }, - "funding": { - "url": "https://github.com/fb55/domutils?sponsor=1" + "engines": { + "node": ">=0.10.0" } }, - "node_modules/dotenv": { - "version": "16.4.5", - "resolved": "https://registry.npmjs.org/dotenv/-/dotenv-16.4.5.tgz", - "integrity": "sha512-ZmdL2rui+eB2YwhsWzjInR8LldtZHGDoQ1ugH85ppHKwpUHL7j7rN0Ti9NCnGiQbhaZ11FpR+7ao1dNsmduNUg==", + "node_modules/dunder-proto": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/dunder-proto/-/dunder-proto-1.0.1.tgz", + "integrity": "sha512-KIN/nDJBQRcXw0MLVhZE9iQHmG68qAVIBg9CqmUYjmQIhgij9U5MFvrqkUL5FbtyyzZuOeOt0zdeRe4UY7ct+A==", "dev": true, - "license": "BSD-2-Clause", - "engines": { - "node": ">=12" + "license": "MIT", + "dependencies": { + "call-bind-apply-helpers": "^1.0.1", + "es-errors": "^1.3.0", + "gopd": "^1.2.0" }, - "funding": { - "url": "https://dotenvx.com" + "engines": { + "node": ">= 0.4" } }, "node_modules/eastasianwidth": { @@ -2155,39 +1559,12 @@ "license": "MIT" }, "node_modules/emoji-regex": { - "version": "8.0.0", - "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz", - "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==", + "version": "9.2.2", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-9.2.2.tgz", + "integrity": "sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg==", "dev": true, "license": "MIT" }, - "node_modules/encoding-sniffer": { - "version": "0.2.0", - "resolved": "https://registry.npmjs.org/encoding-sniffer/-/encoding-sniffer-0.2.0.tgz", - "integrity": "sha512-ju7Wq1kg04I3HtiYIOrUrdfdDvkyO9s5XM8QAj/bN61Yo/Vb4vgJxy5vi4Yxk01gWHbrofpPtpxM8bKger9jhg==", - "dev": true, - "license": "MIT", - "dependencies": { - "iconv-lite": "^0.6.3", - "whatwg-encoding": "^3.1.1" - }, - "funding": { - "url": "https://github.com/fb55/encoding-sniffer?sponsor=1" - } - }, - "node_modules/entities": { - "version": "4.5.0", - "resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz", - "integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==", - "dev": true, - "license": "BSD-2-Clause", - "engines": { - "node": ">=0.12" - }, - "funding": { - "url": "https://github.com/fb55/entities?sponsor=1" - } - }, "node_modules/err-code": { "version": "2.0.3", "resolved": "https://registry.npmjs.org/err-code/-/err-code-2.0.3.tgz", @@ -2206,58 +1583,63 @@ } }, "node_modules/es-abstract": { - "version": "1.23.3", - "resolved": "https://registry.npmjs.org/es-abstract/-/es-abstract-1.23.3.tgz", - "integrity": "sha512-e+HfNH61Bj1X9/jLc5v1owaLYuHdeHHSQlkhCBiTK8rBvKaULl/beGMxwrMXjpYrv4pz22BlY570vVePA2ho4A==", + "version": "1.23.9", + "resolved": "https://registry.npmjs.org/es-abstract/-/es-abstract-1.23.9.tgz", + "integrity": "sha512-py07lI0wjxAC/DcfK1S6G7iANonniZwTISvdPzk9hzeH0IZIshbuuFxLIU96OyF89Yb9hiqWn8M/bY83KY5vzA==", "dev": true, "license": "MIT", "dependencies": { - "array-buffer-byte-length": "^1.0.1", - "arraybuffer.prototype.slice": "^1.0.3", + "array-buffer-byte-length": "^1.0.2", + "arraybuffer.prototype.slice": "^1.0.4", "available-typed-arrays": "^1.0.7", - "call-bind": "^1.0.7", - "data-view-buffer": "^1.0.1", - "data-view-byte-length": "^1.0.1", - "data-view-byte-offset": "^1.0.0", - "es-define-property": "^1.0.0", + "call-bind": "^1.0.8", + "call-bound": "^1.0.3", + "data-view-buffer": "^1.0.2", + "data-view-byte-length": "^1.0.2", + "data-view-byte-offset": "^1.0.1", + "es-define-property": "^1.0.1", "es-errors": "^1.3.0", "es-object-atoms": "^1.0.0", - "es-set-tostringtag": "^2.0.3", - "es-to-primitive": "^1.2.1", - "function.prototype.name": "^1.1.6", - "get-intrinsic": "^1.2.4", - "get-symbol-description": "^1.0.2", - "globalthis": "^1.0.3", - "gopd": "^1.0.1", + "es-set-tostringtag": "^2.1.0", + "es-to-primitive": "^1.3.0", + "function.prototype.name": "^1.1.8", + "get-intrinsic": "^1.2.7", + "get-proto": "^1.0.0", + "get-symbol-description": "^1.1.0", + "globalthis": "^1.0.4", + "gopd": "^1.2.0", "has-property-descriptors": "^1.0.2", - "has-proto": "^1.0.3", - "has-symbols": "^1.0.3", + "has-proto": "^1.2.0", + "has-symbols": "^1.1.0", "hasown": "^2.0.2", - "internal-slot": "^1.0.7", - "is-array-buffer": "^3.0.4", + "internal-slot": "^1.1.0", + "is-array-buffer": "^3.0.5", "is-callable": "^1.2.7", - "is-data-view": "^1.0.1", - "is-negative-zero": "^2.0.3", - "is-regex": "^1.1.4", - "is-shared-array-buffer": "^1.0.3", - "is-string": "^1.0.7", - "is-typed-array": "^1.1.13", - "is-weakref": "^1.0.2", - "object-inspect": "^1.13.1", + "is-data-view": "^1.0.2", + "is-regex": "^1.2.1", + "is-shared-array-buffer": "^1.0.4", + "is-string": "^1.1.1", + "is-typed-array": "^1.1.15", + "is-weakref": "^1.1.0", + "math-intrinsics": "^1.1.0", + "object-inspect": "^1.13.3", "object-keys": "^1.1.1", - "object.assign": "^4.1.5", - "regexp.prototype.flags": "^1.5.2", - "safe-array-concat": "^1.1.2", - "safe-regex-test": "^1.0.3", - "string.prototype.trim": "^1.2.9", - "string.prototype.trimend": "^1.0.8", + "object.assign": "^4.1.7", + "own-keys": "^1.0.1", + "regexp.prototype.flags": "^1.5.3", + "safe-array-concat": "^1.1.3", + "safe-push-apply": "^1.0.0", + "safe-regex-test": "^1.1.0", + "set-proto": "^1.0.0", + "string.prototype.trim": "^1.2.10", + "string.prototype.trimend": "^1.0.9", "string.prototype.trimstart": "^1.0.8", - "typed-array-buffer": "^1.0.2", - "typed-array-byte-length": "^1.0.1", - "typed-array-byte-offset": "^1.0.2", - "typed-array-length": "^1.0.6", - "unbox-primitive": "^1.0.2", - "which-typed-array": "^1.1.15" + "typed-array-buffer": "^1.0.3", + "typed-array-byte-length": "^1.0.3", + "typed-array-byte-offset": "^1.0.4", + "typed-array-length": "^1.0.7", + "unbox-primitive": "^1.1.0", + "which-typed-array": "^1.1.18" }, "engines": { "node": ">= 0.4" @@ -2267,14 +1649,11 @@ } }, "node_modules/es-define-property": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/es-define-property/-/es-define-property-1.0.0.tgz", - "integrity": "sha512-jxayLKShrEqqzJ0eumQbVhTYQM27CfT1T35+gCgDFoL82JLsXqTJ76zv6A0YLOgEnLUMvLzsDsGIrl8NFpT2gQ==", + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/es-define-property/-/es-define-property-1.0.1.tgz", + "integrity": "sha512-e3nRfgfUZ4rNGL232gUgX06QNyyez04KdjFrF+LTRoOXmrOgFKDg4BCdsjW8EnT69eqdYGmRpJwiPVYNrCaW3g==", "dev": true, "license": "MIT", - "dependencies": { - "get-intrinsic": "^1.2.4" - }, "engines": { "node": ">= 0.4" } @@ -2290,9 +1669,9 @@ } }, "node_modules/es-object-atoms": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/es-object-atoms/-/es-object-atoms-1.0.0.tgz", - "integrity": "sha512-MZ4iQ6JwHOBQjahnjwaC1ZtIBH+2ohjamzAO3oaHcXYup7qxjF2fixyH+Q71voWHeOkI2q/TnJao/KfXYIZWbw==", + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/es-object-atoms/-/es-object-atoms-1.1.1.tgz", + "integrity": "sha512-FGgH2h8zKNim9ljj7dankFPcICIK9Cp5bm+c2gQSYePhpaG5+esrLODihIorn+Pe6FGJzWhXQotPv73jTaldXA==", "dev": true, "license": "MIT", "dependencies": { @@ -2303,40 +1682,44 @@ } }, "node_modules/es-set-tostringtag": { - "version": "2.0.3", - "resolved": "https://registry.npmjs.org/es-set-tostringtag/-/es-set-tostringtag-2.0.3.tgz", - "integrity": "sha512-3T8uNMC3OQTHkFUsFq8r/BwAXLHvU/9O9mE0fBc/MY5iq/8H7ncvO947LmYA6ldWw9Uh8Yhf25zu6n7nML5QWQ==", + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/es-set-tostringtag/-/es-set-tostringtag-2.1.0.tgz", + "integrity": "sha512-j6vWzfrGVfyXxge+O0x5sh6cvxAog0a/4Rdd2K36zCMV5eJ+/+tOAngRO8cODMNWbVRdVlmGZQL2YS3yR8bIUA==", "dev": true, "license": "MIT", "dependencies": { - "get-intrinsic": "^1.2.4", + "es-errors": "^1.3.0", + "get-intrinsic": "^1.2.6", "has-tostringtag": "^1.0.2", - "hasown": "^2.0.1" + "hasown": "^2.0.2" }, "engines": { "node": ">= 0.4" } }, "node_modules/es-shim-unscopables": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/es-shim-unscopables/-/es-shim-unscopables-1.0.2.tgz", - "integrity": "sha512-J3yBRXCzDu4ULnQwxyToo/OjdMx6akgVC7K6few0a7F/0wLtmKKN7I73AH5T2836UuXRqN7Qg+IIUw/+YJksRw==", + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/es-shim-unscopables/-/es-shim-unscopables-1.1.0.tgz", + "integrity": "sha512-d9T8ucsEhh8Bi1woXCf+TIKDIROLG5WCkxg8geBCbvk22kzwC5G2OnXVMO6FUsvQlgUUXQ2itephWDLqDzbeCw==", "dev": true, "license": "MIT", "dependencies": { - "hasown": "^2.0.0" + "hasown": "^2.0.2" + }, + "engines": { + "node": ">= 0.4" } }, "node_modules/es-to-primitive": { - "version": "1.2.1", - "resolved": "https://registry.npmjs.org/es-to-primitive/-/es-to-primitive-1.2.1.tgz", - "integrity": "sha512-QCOllgZJtaUo9miYBcLChTUaHNjJF3PYs1VidD7AwiEj1kYxKeQTctLAezAOH5ZKRH0g2IgPn6KwB4IT8iRpvA==", + "version": "1.3.0", + "resolved": "https://registry.npmjs.org/es-to-primitive/-/es-to-primitive-1.3.0.tgz", + "integrity": "sha512-w+5mJ3GuFL+NjVtJlvydShqE1eN3h3PbI7/5LAsYJP/2qtuMXjfL2LpHSRqo4b4eSF5K/DH1JXKUAHSB2UW50g==", "dev": true, "license": "MIT", "dependencies": { - "is-callable": "^1.1.4", - "is-date-object": "^1.0.1", - "is-symbol": "^1.0.2" + "is-callable": "^1.2.7", + "is-date-object": "^1.0.5", + "is-symbol": "^1.0.4" }, "engines": { "node": ">= 0.4" @@ -2359,32 +1742,33 @@ } }, "node_modules/eslint": { - "version": "9.13.0", - "resolved": "https://registry.npmjs.org/eslint/-/eslint-9.13.0.tgz", - "integrity": "sha512-EYZK6SX6zjFHST/HRytOdA/zE72Cq/bfw45LSyuwrdvcclb/gqV8RRQxywOBEWO2+WDpva6UZa4CcDeJKzUCFA==", + "version": "9.22.0", + "resolved": "https://registry.npmjs.org/eslint/-/eslint-9.22.0.tgz", + "integrity": "sha512-9V/QURhsRN40xuHXWjV64yvrzMjcz7ZyNoF2jJFmy9j/SLk0u1OLSZgXi28MrXjymnjEGSR80WCdab3RGMDveQ==", "dev": true, "license": "MIT", "dependencies": { "@eslint-community/eslint-utils": "^4.2.0", - "@eslint-community/regexpp": "^4.11.0", - "@eslint/config-array": "^0.18.0", - "@eslint/core": "^0.7.0", - "@eslint/eslintrc": "^3.1.0", - "@eslint/js": "9.13.0", - "@eslint/plugin-kit": "^0.2.0", - "@humanfs/node": "^0.16.5", + "@eslint-community/regexpp": "^4.12.1", + "@eslint/config-array": "^0.19.2", + "@eslint/config-helpers": "^0.1.0", + "@eslint/core": "^0.12.0", + "@eslint/eslintrc": "^3.3.0", + "@eslint/js": "9.22.0", + "@eslint/plugin-kit": "^0.2.7", + "@humanfs/node": "^0.16.6", "@humanwhocodes/module-importer": "^1.0.1", - "@humanwhocodes/retry": "^0.3.1", + "@humanwhocodes/retry": "^0.4.2", "@types/estree": "^1.0.6", "@types/json-schema": "^7.0.15", "ajv": "^6.12.4", "chalk": "^4.0.0", - "cross-spawn": "^7.0.2", + "cross-spawn": "^7.0.6", "debug": "^4.3.2", "escape-string-regexp": "^4.0.0", - "eslint-scope": "^8.1.0", - "eslint-visitor-keys": "^4.1.0", - "espree": "^10.2.0", + "eslint-scope": "^8.3.0", + "eslint-visitor-keys": "^4.2.0", + "espree": "^10.3.0", "esquery": "^1.5.0", "esutils": "^2.0.2", "fast-deep-equal": "^3.1.3", @@ -2398,8 +1782,7 @@ "lodash.merge": "^4.6.2", "minimatch": "^3.1.2", "natural-compare": "^1.4.0", - "optionator": "^0.9.3", - "text-table": "^0.2.0" + "optionator": "^0.9.3" }, "bin": { "eslint": "bin/eslint.js" @@ -2503,6 +1886,17 @@ "eslint": "^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9" } }, + "node_modules/eslint-plugin-import/node_modules/brace-expansion": { + "version": "1.1.11", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz", + "integrity": "sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==", + "dev": true, + "license": "MIT", + "dependencies": { + "balanced-match": "^1.0.0", + "concat-map": "0.0.1" + } + }, "node_modules/eslint-plugin-import/node_modules/debug": { "version": "3.2.7", "resolved": "https://registry.npmjs.org/debug/-/debug-3.2.7.tgz", @@ -2513,10 +1907,33 @@ "ms": "^2.1.1" } }, + "node_modules/eslint-plugin-import/node_modules/minimatch": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz", + "integrity": "sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==", + "dev": true, + "license": "ISC", + "dependencies": { + "brace-expansion": "^1.1.7" + }, + "engines": { + "node": "*" + } + }, + "node_modules/eslint-plugin-import/node_modules/semver": { + "version": "6.3.1", + "resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz", + "integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==", + "dev": true, + "license": "ISC", + "bin": { + "semver": "bin/semver.js" + } + }, "node_modules/eslint-scope": { - "version": "8.1.0", - "resolved": "https://registry.npmjs.org/eslint-scope/-/eslint-scope-8.1.0.tgz", - "integrity": "sha512-14dSvlhaVhKKsa9Fx1l8A17s7ah7Ef7wCakJ10LYk6+GYmP9yDti2oq2SEwcyndt6knfcZyhyxwY3i9yL78EQw==", + "version": "8.3.0", + "resolved": "https://registry.npmjs.org/eslint-scope/-/eslint-scope-8.3.0.tgz", + "integrity": "sha512-pUNxi75F8MJ/GdeKtVLSbYg4ZI34J6C0C7sbL4YOp2exGwen7ZsuBqKzUhXd0qMQ362yET3z+uPwKeg/0C2XCQ==", "dev": true, "license": "BSD-2-Clause", "dependencies": { @@ -2531,9 +1948,9 @@ } }, "node_modules/eslint-visitor-keys": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/eslint-visitor-keys/-/eslint-visitor-keys-4.1.0.tgz", - "integrity": "sha512-Q7lok0mqMUSf5a/AdAZkA5a/gHcO6snwQClVNNvFKCAVlxXucdU8pKydU5ZVZjBx5xr37vGbFFWtLQYreLzrZg==", + "version": "4.2.0", + "resolved": "https://registry.npmjs.org/eslint-visitor-keys/-/eslint-visitor-keys-4.2.0.tgz", + "integrity": "sha512-UyLnSehNt62FFhSwjZlHmeokpRK59rcz29j+F1/aDgbkbRTk7wIc9XzdoasMUbRNKDM0qQt/+BJ4BrpFeABemw==", "dev": true, "license": "Apache-2.0", "engines": { @@ -2543,16 +1960,40 @@ "url": "https://opencollective.com/eslint" } }, + "node_modules/eslint/node_modules/brace-expansion": { + "version": "1.1.11", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz", + "integrity": "sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==", + "dev": true, + "license": "MIT", + "dependencies": { + "balanced-match": "^1.0.0", + "concat-map": "0.0.1" + } + }, + "node_modules/eslint/node_modules/minimatch": { + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz", + "integrity": "sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==", + "dev": true, + "license": "ISC", + "dependencies": { + "brace-expansion": "^1.1.7" + }, + "engines": { + "node": "*" + } + }, "node_modules/espree": { - "version": "10.2.0", - "resolved": "https://registry.npmjs.org/espree/-/espree-10.2.0.tgz", - "integrity": "sha512-upbkBJbckcCNBDBDXEbuhjbP68n+scUd3k/U2EkyM9nw+I/jPiL4cLF/Al06CF96wRltFda16sxDFrxsI1v0/g==", + "version": "10.3.0", + "resolved": "https://registry.npmjs.org/espree/-/espree-10.3.0.tgz", + "integrity": "sha512-0QYC8b24HWY8zjRnDTL6RiHfDbAWn63qb4LMj1Z4b076A4une81+z03Kg7l7mn/48PUTqoLptSXez8oknU8Clg==", "dev": true, "license": "BSD-2-Clause", "dependencies": { - "acorn": "^8.12.0", + "acorn": "^8.14.0", "acorn-jsx": "^5.3.2", - "eslint-visitor-keys": "^4.1.0" + "eslint-visitor-keys": "^4.2.0" }, "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -2614,34 +2055,6 @@ "dev": true, "license": "MIT" }, - "node_modules/external-editor": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/external-editor/-/external-editor-3.1.0.tgz", - "integrity": "sha512-hMQ4CX1p1izmuLYyZqLMO/qGNw10wSv9QDCPfzXfyFrOaCSSoRfqE1Kf1s5an66J5JZC62NewG+mK49jOCtQew==", - "dev": true, - "license": "MIT", - "dependencies": { - "chardet": "^0.7.0", - "iconv-lite": "^0.4.24", - "tmp": "^0.0.33" - }, - "engines": { - "node": ">=4" - } - }, - "node_modules/external-editor/node_modules/iconv-lite": { - "version": "0.4.24", - "resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.4.24.tgz", - "integrity": "sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA==", - "dev": true, - "license": "MIT", - "dependencies": { - "safer-buffer": ">= 2.1.2 < 3" - }, - "engines": { - "node": ">=0.10.0" - } - }, "node_modules/fast-deep-equal": { "version": "3.1.3", "resolved": "https://registry.npmjs.org/fast-deep-equal/-/fast-deep-equal-3.1.3.tgz", @@ -2650,9 +2063,9 @@ "license": "MIT" }, "node_modules/fast-glob": { - "version": "3.3.2", - "resolved": "https://registry.npmjs.org/fast-glob/-/fast-glob-3.3.2.tgz", - "integrity": "sha512-oX2ruAFQwf/Orj8m737Y5adxDQO0LAB7/S5MnxCdTNDd4p6BsyIVsv9JQsATbTSq8KHRpLwIHbVlUNatxd+1Ow==", + "version": "3.3.3", + "resolved": "https://registry.npmjs.org/fast-glob/-/fast-glob-3.3.3.tgz", + "integrity": "sha512-7MptL8U0cqcFdzIzwOTHoilX9x5BrNqye7Z/LuC7kCMRio1EMSyqRK3BEAUD7sXRq4iT4AzTVuZdhgQ2TCvYLg==", "dev": true, "license": "MIT", "dependencies": { @@ -2660,7 +2073,7 @@ "@nodelib/fs.walk": "^1.2.3", "glob-parent": "^5.1.2", "merge2": "^1.3.0", - "micromatch": "^4.0.4" + "micromatch": "^4.0.8" }, "engines": { "node": ">=8.6.0" @@ -2694,41 +2107,15 @@ "license": "MIT" }, "node_modules/fastq": { - "version": "1.17.1", - "resolved": "https://registry.npmjs.org/fastq/-/fastq-1.17.1.tgz", - "integrity": "sha512-sRVD3lWVIXWg6By68ZN7vho9a1pQcN/WBFaAAsDDFzlJjvoGx0P8z7V1t72grFJfJhu3YPZBuu25f7Kaw2jN1w==", + "version": "1.19.1", + "resolved": "https://registry.npmjs.org/fastq/-/fastq-1.19.1.tgz", + "integrity": "sha512-GwLTyxkCXjXbxqIhTsMI2Nui8huMPtnxg7krajPJAjnEG/iiOS7i+zCtWGZR9G0NBKbXKh6X9m9UIsYX/N6vvQ==", "dev": true, "license": "ISC", "dependencies": { "reusify": "^1.0.4" } }, - "node_modules/figures": { - "version": "3.2.0", - "resolved": "https://registry.npmjs.org/figures/-/figures-3.2.0.tgz", - "integrity": "sha512-yaduQFRKLXYOGgEn6AZau90j3ggSOyiqXU0F9JZfeXYhNa+Jk4X+s45A2zg5jns87GAFa34BBm2kXw4XpNcbdg==", - "dev": true, - "license": "MIT", - "dependencies": { - "escape-string-regexp": "^1.0.5" - }, - "engines": { - "node": ">=8" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/figures/node_modules/escape-string-regexp": { - "version": "1.0.5", - "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz", - "integrity": "sha512-vbRorB5FUQWvla16U8R/qgaFIya2qGzwDrNmCZuYKrbdSUMG6I1ZCGQRefkRVhuOkIGVne7BQ35DSfo1qvJqFg==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=0.8.0" - } - }, "node_modules/file-entry-cache": { "version": "8.0.0", "resolved": "https://registry.npmjs.org/file-entry-cache/-/file-entry-cache-8.0.0.tgz", @@ -2787,66 +2174,38 @@ } }, "node_modules/flatted": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/flatted/-/flatted-3.3.1.tgz", - "integrity": "sha512-X8cqMLLie7KsNUDSdzeN8FYK9rEt4Dt67OsG/DNGnYTSDBG4uFAJFBnUeiV+zCVAvwFy56IjM9sH51jVaEhNxw==", + "version": "3.3.3", + "resolved": "https://registry.npmjs.org/flatted/-/flatted-3.3.3.tgz", + "integrity": "sha512-GX+ysw4PBCz0PzosHDepZGANEuFCMLrnRTiEy9McGjmkCQYwRq4A/X786G/fjM/+OjsWSU1ZrY5qyARZmO/uwg==", "dev": true, "license": "ISC" }, - "node_modules/follow-redirects": { - "version": "1.15.9", - "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.15.9.tgz", - "integrity": "sha512-gew4GsXizNgdoRyqmyfMHyAmXsZDk6mHkSxZFCzW9gwlbtOW44CDtYavM+y+72qD/Vq2l550kMF52DT8fOLJqQ==", - "dev": true, - "funding": [ - { - "type": "individual", - "url": "https://github.com/sponsors/RubenVerborgh" - } - ], - "license": "MIT", - "engines": { - "node": ">=4.0" - }, - "peerDependenciesMeta": { - "debug": { - "optional": true - } - } - }, "node_modules/for-each": { - "version": "0.3.3", - "resolved": "https://registry.npmjs.org/for-each/-/for-each-0.3.3.tgz", - "integrity": "sha512-jqYfLp7mo9vIyQf8ykW2v7A+2N4QjeCeI5+Dz9XraiO1ign81wjiH7Fb9vSOWvQfNtmSa4H2RoQTrrXivdUZmw==", + "version": "0.3.5", + "resolved": "https://registry.npmjs.org/for-each/-/for-each-0.3.5.tgz", + "integrity": "sha512-dKx12eRCVIzqCxFGplyFKJMPvLEWgmNtUrpTiJIR5u97zEhRG8ySrtboPHZXx7daLxQVrl643cTzbab2tkQjxg==", "dev": true, "license": "MIT", "dependencies": { - "is-callable": "^1.1.3" - } - }, - "node_modules/foreground-child": { - "version": "3.3.0", - "resolved": "https://registry.npmjs.org/foreground-child/-/foreground-child-3.3.0.tgz", - "integrity": "sha512-Ld2g8rrAyMYFXBhEqMz8ZAHBi4J4uS1i/CxGMDnjyFWddMXLVcDp051DZfu+t7+ab7Wv6SMqpWmyFIj5UbfFvg==", - "dev": true, - "license": "ISC", - "dependencies": { - "cross-spawn": "^7.0.0", - "signal-exit": "^4.0.1" + "is-callable": "^1.2.7" }, "engines": { - "node": ">=14" + "node": ">= 0.4" }, "funding": { - "url": "https://github.com/sponsors/isaacs" + "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/foreground-child/node_modules/signal-exit": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-4.1.0.tgz", - "integrity": "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw==", + "node_modules/foreground-child": { + "version": "3.3.1", + "resolved": "https://registry.npmjs.org/foreground-child/-/foreground-child-3.3.1.tgz", + "integrity": "sha512-gIXjKqtFuWEgzFRJA9WCQeSJLZDjgJUOMCMzxtvFq/37KojM1BFGufqsCy0r4qSQmYLsZYMeyRqzIWOMup03sw==", "dev": true, "license": "ISC", + "dependencies": { + "cross-spawn": "^7.0.6", + "signal-exit": "^4.0.1" + }, "engines": { "node": ">=14" }, @@ -2854,21 +2213,6 @@ "url": "https://github.com/sponsors/isaacs" } }, - "node_modules/fs-extra": { - "version": "10.1.0", - "resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-10.1.0.tgz", - "integrity": "sha512-oRXApq54ETRj4eMiFzGnHWGy+zo5raudjuxN0b8H7s/RU2oW0Wvsx9O0ACRN/kRq9E8Vu/ReskGB5o3ji+FzHQ==", - "dev": true, - "license": "MIT", - "dependencies": { - "graceful-fs": "^4.2.0", - "jsonfile": "^6.0.1", - "universalify": "^2.0.0" - }, - "engines": { - "node": ">=12" - } - }, "node_modules/fsevents": { "version": "2.3.3", "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz", @@ -2895,16 +2239,18 @@ } }, "node_modules/function.prototype.name": { - "version": "1.1.6", - "resolved": "https://registry.npmjs.org/function.prototype.name/-/function.prototype.name-1.1.6.tgz", - "integrity": "sha512-Z5kx79swU5P27WEayXM1tBi5Ze/lbIyiNgU3qyXUOf9b2rgXYyF9Dy9Cx+IQv/Lc8WCG6L82zwUPpSS9hGehIg==", + "version": "1.1.8", + "resolved": "https://registry.npmjs.org/function.prototype.name/-/function.prototype.name-1.1.8.tgz", + "integrity": "sha512-e5iwyodOHhbMr/yNrc7fDYG4qlbIvI5gajyzPnb5TCwyhjApznQh1BMFou9b30SevY43gCJKXycoCBjMbsuW0Q==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.2", - "define-properties": "^1.2.0", - "es-abstract": "^1.22.1", - "functions-have-names": "^1.2.3" + "call-bind": "^1.0.8", + "call-bound": "^1.0.3", + "define-properties": "^1.2.1", + "functions-have-names": "^1.2.3", + "hasown": "^2.0.2", + "is-callable": "^1.2.7" }, "engines": { "node": ">= 0.4" @@ -2924,17 +2270,22 @@ } }, "node_modules/get-intrinsic": { - "version": "1.2.4", - "resolved": "https://registry.npmjs.org/get-intrinsic/-/get-intrinsic-1.2.4.tgz", - "integrity": "sha512-5uYhsJH8VJBTv7oslg4BznJYhDoRI6waYCxMmCdnTrcCrHA/fCFKoTFz2JKKE0HdDFUF7/oQuhzumXJK7paBRQ==", + "version": "1.3.0", + "resolved": "https://registry.npmjs.org/get-intrinsic/-/get-intrinsic-1.3.0.tgz", + "integrity": "sha512-9fSjSaos/fRIVIp+xSJlE6lfwhES7LNtKaCBIamHsjr2na1BiABJPo0mOjjz8GJDURarmCPGqaiVg5mfjb98CQ==", "dev": true, "license": "MIT", "dependencies": { + "call-bind-apply-helpers": "^1.0.2", + "es-define-property": "^1.0.1", "es-errors": "^1.3.0", + "es-object-atoms": "^1.1.1", "function-bind": "^1.1.2", - "has-proto": "^1.0.1", - "has-symbols": "^1.0.3", - "hasown": "^2.0.0" + "get-proto": "^1.0.1", + "gopd": "^1.2.0", + "has-symbols": "^1.1.0", + "hasown": "^2.0.2", + "math-intrinsics": "^1.1.0" }, "engines": { "node": ">= 0.4" @@ -2943,16 +2294,30 @@ "url": "https://github.com/sponsors/ljharb" } }, + "node_modules/get-proto": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/get-proto/-/get-proto-1.0.1.tgz", + "integrity": "sha512-sTSfBjoXBp89JvIKIefqw7U2CCebsc74kiY6awiGogKtoSGbgjYE/G/+l9sF3MWFPNc9IcoOC4ODfKHfxFmp0g==", + "dev": true, + "license": "MIT", + "dependencies": { + "dunder-proto": "^1.0.1", + "es-object-atoms": "^1.0.0" + }, + "engines": { + "node": ">= 0.4" + } + }, "node_modules/get-symbol-description": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/get-symbol-description/-/get-symbol-description-1.0.2.tgz", - "integrity": "sha512-g0QYk1dZBxGwk+Ngc+ltRH2IBp2f7zBkBMBJZCDerh6EhlhSR6+9irMCuT/09zD6qkarHUSn529sK/yL4S27mg==", + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/get-symbol-description/-/get-symbol-description-1.1.0.tgz", + "integrity": "sha512-w9UMqWwJxHNOvoNzSJ2oPF5wvYcvP7jUvYzhp67yEhTi17ZDBBC1z9pTdGuzjD+EFIqLSYRweZjqfiPzQ06Ebg==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.5", + "call-bound": "^1.0.3", "es-errors": "^1.3.0", - "get-intrinsic": "^1.2.4" + "get-intrinsic": "^1.2.6" }, "engines": { "node": ">= 0.4" @@ -2968,6 +2333,27 @@ "dev": true, "license": "ISC" }, + "node_modules/glob": { + "version": "10.4.5", + "resolved": "https://registry.npmjs.org/glob/-/glob-10.4.5.tgz", + "integrity": "sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==", + "dev": true, + "license": "ISC", + "dependencies": { + "foreground-child": "^3.1.0", + "jackspeak": "^3.1.2", + "minimatch": "^9.0.4", + "minipass": "^7.1.2", + "package-json-from-dist": "^1.0.0", + "path-scurry": "^1.11.1" + }, + "bin": { + "glob": "dist/esm/bin.mjs" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } + }, "node_modules/glob-parent": { "version": "6.0.2", "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-6.0.2.tgz", @@ -3012,31 +2398,27 @@ } }, "node_modules/gopd": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/gopd/-/gopd-1.0.1.tgz", - "integrity": "sha512-d65bNlIadxvpb/A2abVdlqKqV563juRnZ1Wtk6s1sIR8uNsXR70xqIzVqxVf1eTqDunwT2MkczEeaezCKTZhwA==", + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/gopd/-/gopd-1.2.0.tgz", + "integrity": "sha512-ZUKRh6/kUFoAiTAtTYPZJ3hw9wNxx+BIBOijnlG9PnrJsCcSjs1wyyD6vJpaYtgnzDrKYRSqf3OO6Rfa93xsRg==", "dev": true, "license": "MIT", - "dependencies": { - "get-intrinsic": "^1.1.3" + "engines": { + "node": ">= 0.4" }, "funding": { "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/graceful-fs": { - "version": "4.2.11", - "resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.11.tgz", - "integrity": "sha512-RbJ5/jmFcNNCcDV5o9eTnBLJ/HszWV0P73bc+Ff4nS/rJj+YaS6IGyiOL0VoBYX+l1Wrl3k63h/KrH+nhJ0XvQ==", - "dev": true, - "license": "ISC" - }, "node_modules/has-bigints": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/has-bigints/-/has-bigints-1.0.2.tgz", - "integrity": "sha512-tSvCKtBr9lkF0Ex0aQiP9N+OpV4zi2r/Nee5VkRDbaqv35RLYMzbwQfFSZZH0kR+Rd6302UJZ2p/bJCEoR3VoQ==", + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/has-bigints/-/has-bigints-1.1.0.tgz", + "integrity": "sha512-R3pbpkcIqv2Pm3dUwgjclDRVmWpTJW2DcMzcIhEXEx1oh/CEMObMm3KLmRJOdvhM7o4uQBnwr8pzRK2sJWIqfg==", "dev": true, "license": "MIT", + "engines": { + "node": ">= 0.4" + }, "funding": { "url": "https://github.com/sponsors/ljharb" } @@ -3065,11 +2447,14 @@ } }, "node_modules/has-proto": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/has-proto/-/has-proto-1.0.3.tgz", - "integrity": "sha512-SJ1amZAJUiZS+PhsVLf5tGydlaVB8EdFpaSO4gmiUKUOxk8qzn5AIy4ZeJUmh22znIdk/uMAUT2pl3FxzVUH+Q==", + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/has-proto/-/has-proto-1.2.0.tgz", + "integrity": "sha512-KIL7eQPfHQRC8+XluaIw7BHUwwqL19bQn4hzNgdr+1wXoU0KKj6rufu47lhY7KbJR2C6T6+PfyN0Ea7wkSS+qQ==", "dev": true, "license": "MIT", + "dependencies": { + "dunder-proto": "^1.0.0" + }, "engines": { "node": ">= 0.4" }, @@ -3078,9 +2463,9 @@ } }, "node_modules/has-symbols": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/has-symbols/-/has-symbols-1.0.3.tgz", - "integrity": "sha512-l3LCuF6MgDNwTDKkdYGEihYjt5pRPbEg46rtlmnSPlUbgmB8LOIrKJbYYFBSbnPaJexMKtiPO8hmeRjRz2Td+A==", + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/has-symbols/-/has-symbols-1.1.0.tgz", + "integrity": "sha512-1cDNdwJ2Jaohmb3sg4OmKaMBwuC48sYni5HUw2DvsC8LjGTLK9h+eb1X6RyuOHe4hT0ULCW68iomhjUoKUqlPQ==", "dev": true, "license": "MIT", "engines": { @@ -3119,6 +2504,20 @@ "node": ">= 0.4" } }, + "node_modules/hast-util-is-element": { + "version": "3.0.0", + "resolved": "https://registry.npmjs.org/hast-util-is-element/-/hast-util-is-element-3.0.0.tgz", + "integrity": "sha512-Val9mnv2IWpLbNPqc/pUem+a7Ipj2aHacCwgNfTiK0vJKl0LF+4Ba4+v1oPHFpf3bLYmreq0/l3Gud9S5OH42g==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/hast": "^3.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, "node_modules/hast-util-parse-selector": { "version": "4.0.0", "resolved": "https://registry.npmjs.org/hast-util-parse-selector/-/hast-util-parse-selector-4.0.0.tgz", @@ -3134,9 +2533,9 @@ } }, "node_modules/hast-util-to-html": { - "version": "9.0.3", - "resolved": "https://registry.npmjs.org/hast-util-to-html/-/hast-util-to-html-9.0.3.tgz", - "integrity": "sha512-M17uBDzMJ9RPCqLMO92gNNUDuBSq10a25SDBI08iCCxmorf4Yy6sYHK57n9WAbRAAaU+DuR4W6GN9K4DFZesYg==", + "version": "9.0.5", + "resolved": "https://registry.npmjs.org/hast-util-to-html/-/hast-util-to-html-9.0.5.tgz", + "integrity": "sha512-OguPdidb+fbHQSU4Q4ZiLKnzWo8Wwsf5bZfbvu7//a9oTYoqD/fWpe96NuHkoS9h0ccGOTe0C4NGXdtS0iObOw==", "dev": true, "license": "MIT", "dependencies": { @@ -3147,7 +2546,7 @@ "hast-util-whitespace": "^3.0.0", "html-void-elements": "^3.0.0", "mdast-util-to-hast": "^13.0.0", - "property-information": "^6.0.0", + "property-information": "^7.0.0", "space-separated-tokens": "^2.0.0", "stringify-entities": "^4.0.0", "zwitch": "^2.0.4" @@ -3164,6 +2563,41 @@ "dev": true, "license": "MIT" }, + "node_modules/hast-util-to-html/node_modules/property-information": { + "version": "7.0.0", + "resolved": "https://registry.npmjs.org/property-information/-/property-information-7.0.0.tgz", + "integrity": "sha512-7D/qOz/+Y4X/rzSB6jKxKUsQnphO046ei8qxG59mtM3RG3DHgTK81HrxrmoDVINJb8NKT5ZsRbwHvQ6B68Iyhg==", + "dev": true, + "license": "MIT", + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, + "node_modules/hast-util-to-text": { + "version": "4.0.2", + "resolved": "https://registry.npmjs.org/hast-util-to-text/-/hast-util-to-text-4.0.2.tgz", + "integrity": "sha512-KK6y/BN8lbaq654j7JgBydev7wuNMcID54lkRav1P0CaE1e47P72AWWPiGKXTJU271ooYzcvTAn/Zt0REnvc7A==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/hast": "^3.0.0", + "@types/unist": "^3.0.0", + "hast-util-is-element": "^3.0.0", + "unist-util-find-after": "^5.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/hast-util-to-text/node_modules/@types/unist": { + "version": "3.0.3", + "resolved": "https://registry.npmjs.org/@types/unist/-/unist-3.0.3.tgz", + "integrity": "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q==", + "dev": true, + "license": "MIT" + }, "node_modules/hast-util-whitespace": { "version": "3.0.0", "resolved": "https://registry.npmjs.org/hast-util-whitespace/-/hast-util-whitespace-3.0.0.tgz", @@ -3196,6 +2630,16 @@ "url": "https://opencollective.com/unified" } }, + "node_modules/highlight.js": { + "version": "11.11.1", + "resolved": "https://registry.npmjs.org/highlight.js/-/highlight.js-11.11.1.tgz", + "integrity": "sha512-Xwwo44whKBVCYoliBQwaPvtd/2tYFkRQtXDWj1nackaV2JPXx3L0+Jvd8/qCJ2p+ML0/XVkJ2q+Mr+UVdpJK5w==", + "dev": true, + "license": "BSD-3-Clause", + "engines": { + "node": ">=12.0.0" + } + }, "node_modules/hosted-git-info": { "version": "7.0.2", "resolved": "https://registry.npmjs.org/hosted-git-info/-/hosted-git-info-7.0.2.tgz", @@ -3220,64 +2664,10 @@ "url": "https://github.com/sponsors/wooorm" } }, - "node_modules/htmlparser2": { - "version": "9.1.0", - "resolved": "https://registry.npmjs.org/htmlparser2/-/htmlparser2-9.1.0.tgz", - "integrity": "sha512-5zfg6mHUoaer/97TxnGpxmbR7zJtPwIYFMZ/H5ucTlPZhKvtum05yiPK3Mgai3a0DyVxv7qYqoweaEd2nrYQzQ==", - "dev": true, - "funding": [ - "https://github.com/fb55/htmlparser2?sponsor=1", - { - "type": "github", - "url": "https://github.com/sponsors/fb55" - } - ], - "license": "MIT", - "dependencies": { - "domelementtype": "^2.3.0", - "domhandler": "^5.0.3", - "domutils": "^3.1.0", - "entities": "^4.5.0" - } - }, - "node_modules/iconv-lite": { - "version": "0.6.3", - "resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.6.3.tgz", - "integrity": "sha512-4fCk79wshMdzMp2rH06qWrJE4iolqLhCUH+OiuIgU++RB0+94NlDL81atO7GX55uUKueo0txHNtvEyI6D7WdMw==", - "dev": true, - "license": "MIT", - "dependencies": { - "safer-buffer": ">= 2.1.2 < 3.0.0" - }, - "engines": { - "node": ">=0.10.0" - } - }, - "node_modules/ieee754": { - "version": "1.2.1", - "resolved": "https://registry.npmjs.org/ieee754/-/ieee754-1.2.1.tgz", - "integrity": "sha512-dcyqhDvX1C46lXZcVqCpK+FtMRQVdIMN6/Df5js2zouUsqG7I6sFxitIC+7KYK29KdXOLHdu9zL4sFnoVQnqaA==", - "dev": true, - "funding": [ - { - "type": "github", - "url": "https://github.com/sponsors/feross" - }, - { - "type": "patreon", - "url": "https://www.patreon.com/feross" - }, - { - "type": "consulting", - "url": "https://feross.org/support" - } - ], - "license": "BSD-3-Clause" - }, "node_modules/ignore": { - "version": "5.3.1", - "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.3.1.tgz", - "integrity": "sha512-5Fytz/IraMjqpwfd34ke28PTVMjZjJG2MPn5t7OE4eUCUNf8BAa7b5WUS9/Qvr6mwOQS7Mk6vdsMno5he+T8Xw==", + "version": "5.3.2", + "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.3.2.tgz", + "integrity": "sha512-hsBTNUqQTDwkWtcdYI2i06Y/nUBEsNEDJKjWdigLvegy8kDuJAS8uRlpkkcQpyEXL0Z/pjDy5HBmMjRCJ2gq+g==", "dev": true, "license": "MIT", "engines": { @@ -3285,9 +2675,9 @@ } }, "node_modules/import-fresh": { - "version": "3.3.0", - "resolved": "https://registry.npmjs.org/import-fresh/-/import-fresh-3.3.0.tgz", - "integrity": "sha512-veYYhQa+D1QBKznvhUHxb8faxlrwUnxseDAbAp457E0wLNio2bOSKnjYDhMj+YiAq61xrMGhQk9iXVk5FzgQMw==", + "version": "3.3.1", + "resolved": "https://registry.npmjs.org/import-fresh/-/import-fresh-3.3.1.tgz", + "integrity": "sha512-TR3KfrTZTYLPB6jUjfx6MF9WcWrHL9su5TObK4ZkYgBdWKPOFoSoQIdEuTuR82pmtxH2spWG9h6etwfr1pLBqQ==", "dev": true, "license": "MIT", "dependencies": { @@ -3339,43 +2729,16 @@ "node": "^14.17.0 || ^16.13.0 || >=18.0.0" } }, - "node_modules/inquirer": { - "version": "8.2.6", - "resolved": "https://registry.npmjs.org/inquirer/-/inquirer-8.2.6.tgz", - "integrity": "sha512-M1WuAmb7pn9zdFRtQYk26ZBoY043Sse0wVDdk4Bppr+JOXyQYybdtvK+l9wUibhtjdjvtoiNy8tk+EgsYIUqKg==", - "dev": true, - "license": "MIT", - "dependencies": { - "ansi-escapes": "^4.2.1", - "chalk": "^4.1.1", - "cli-cursor": "^3.1.0", - "cli-width": "^3.0.0", - "external-editor": "^3.0.3", - "figures": "^3.0.0", - "lodash": "^4.17.21", - "mute-stream": "0.0.8", - "ora": "^5.4.1", - "run-async": "^2.4.0", - "rxjs": "^7.5.5", - "string-width": "^4.1.0", - "strip-ansi": "^6.0.0", - "through": "^2.3.6", - "wrap-ansi": "^6.0.1" - }, - "engines": { - "node": ">=12.0.0" - } - }, "node_modules/internal-slot": { - "version": "1.0.7", - "resolved": "https://registry.npmjs.org/internal-slot/-/internal-slot-1.0.7.tgz", - "integrity": "sha512-NGnrKwXzSms2qUUih/ILZ5JBqNTSa1+ZmP6flaIp6KmSElgE9qdndzS3cqjrDovwFdmwsGsLdeFgB6suw+1e9g==", + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/internal-slot/-/internal-slot-1.1.0.tgz", + "integrity": "sha512-4gd7VpWNQNB4UKKCFFVcp1AVv+FMOgs9NKzjHKusc8jTMhd5eL1NqQqOpE0KzMds804/yHlglp3uxgluOqAPLw==", "dev": true, "license": "MIT", "dependencies": { "es-errors": "^1.3.0", - "hasown": "^2.0.0", - "side-channel": "^1.0.4" + "hasown": "^2.0.2", + "side-channel": "^1.1.0" }, "engines": { "node": ">= 0.4" @@ -3408,14 +2771,15 @@ } }, "node_modules/is-array-buffer": { - "version": "3.0.4", - "resolved": "https://registry.npmjs.org/is-array-buffer/-/is-array-buffer-3.0.4.tgz", - "integrity": "sha512-wcjaerHw0ydZwfhiKbXJWLDY8A7yV7KhjQOpb83hGgGfId/aQa4TOvwyzn2PuswW2gPCYEL/nEAiSVpdOj1lXw==", + "version": "3.0.5", + "resolved": "https://registry.npmjs.org/is-array-buffer/-/is-array-buffer-3.0.5.tgz", + "integrity": "sha512-DDfANUiiG2wC1qawP66qlTugJeL5HyzMpfr8lLK+jMQirGzNod0B12cFB/9q838Ru27sBwfw78/rdoU7RERz6A==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.2", - "get-intrinsic": "^1.2.1" + "call-bind": "^1.0.8", + "call-bound": "^1.0.3", + "get-intrinsic": "^1.2.6" }, "engines": { "node": ">= 0.4" @@ -3431,14 +2795,37 @@ "dev": true, "license": "MIT" }, + "node_modules/is-async-function": { + "version": "2.1.1", + "resolved": "https://registry.npmjs.org/is-async-function/-/is-async-function-2.1.1.tgz", + "integrity": "sha512-9dgM/cZBnNvjzaMYHVoxxfPj2QXt22Ev7SuuPrs+xav0ukGB0S6d4ydZdEiM48kLx5kDV+QBPrpVnFyefL8kkQ==", + "dev": true, + "license": "MIT", + "dependencies": { + "async-function": "^1.0.0", + "call-bound": "^1.0.3", + "get-proto": "^1.0.1", + "has-tostringtag": "^1.0.2", + "safe-regex-test": "^1.1.0" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, "node_modules/is-bigint": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/is-bigint/-/is-bigint-1.0.4.tgz", - "integrity": "sha512-zB9CruMamjym81i2JZ3UMn54PKGsQzsJeo6xvN3HJJ4CAsQNB6iRutp2To77OfCNuoxspsIhzaPoO1zyCEhFOg==", + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/is-bigint/-/is-bigint-1.1.0.tgz", + "integrity": "sha512-n4ZT37wG78iz03xPRKJrHTdZbe3IicyucEtdRsV5yglwc3GyUfbAfpSeD0FJ41NbUNSt5wbhqfp1fS+BgnvDFQ==", "dev": true, "license": "MIT", "dependencies": { - "has-bigints": "^1.0.1" + "has-bigints": "^1.0.2" + }, + "engines": { + "node": ">= 0.4" }, "funding": { "url": "https://github.com/sponsors/ljharb" @@ -3458,14 +2845,14 @@ } }, "node_modules/is-boolean-object": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/is-boolean-object/-/is-boolean-object-1.1.2.tgz", - "integrity": "sha512-gDYaKHJmnj4aWxyj6YHyXVpdQawtVLHU5cb+eztPGczf6cjuTdwve5ZIEfgXqH4e57An1D1AKf8CZ3kYrQRqYA==", + "version": "1.2.2", + "resolved": "https://registry.npmjs.org/is-boolean-object/-/is-boolean-object-1.2.2.tgz", + "integrity": "sha512-wa56o2/ElJMYqjCjGkXri7it5FbebW5usLw/nPmCMs5DeZ7eziSYZhSmPRn0txqeW4LnAmQQU7FgqLpsEFKM4A==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.2", - "has-tostringtag": "^1.0.0" + "call-bound": "^1.0.3", + "has-tostringtag": "^1.0.2" }, "engines": { "node": ">= 0.4" @@ -3474,13 +2861,6 @@ "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/is-buffer": { - "version": "1.1.6", - "resolved": "https://registry.npmjs.org/is-buffer/-/is-buffer-1.1.6.tgz", - "integrity": "sha512-NcdALwpXkTm5Zvvbk7owOUSvVvBKDgKP5/ewfXEznmQFfs4ZRmanOeKBTjRVjka3QFoN6XJ+9F3USqfHqTaU5w==", - "dev": true, - "license": "MIT" - }, "node_modules/is-callable": { "version": "1.2.7", "resolved": "https://registry.npmjs.org/is-callable/-/is-callable-1.2.7.tgz", @@ -3495,9 +2875,9 @@ } }, "node_modules/is-core-module": { - "version": "2.15.1", - "resolved": "https://registry.npmjs.org/is-core-module/-/is-core-module-2.15.1.tgz", - "integrity": "sha512-z0vtXSwucUJtANQWldhbtbt7BnL0vxiFjIdDLAatwhDYty2bad6s+rijD6Ri4YuYJubLzIJLUidCh09e1djEVQ==", + "version": "2.16.1", + "resolved": "https://registry.npmjs.org/is-core-module/-/is-core-module-2.16.1.tgz", + "integrity": "sha512-UfoeMA6fIJ8wTYFEUjelnaGI67v6+N7qXJEvQuIGa99l4xsCruSYOVSQ0uPANn4dAzm8lkYPaKLrrijLq7x23w==", "dev": true, "license": "MIT", "dependencies": { @@ -3511,12 +2891,14 @@ } }, "node_modules/is-data-view": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/is-data-view/-/is-data-view-1.0.1.tgz", - "integrity": "sha512-AHkaJrsUVW6wq6JS8y3JnM/GJF/9cf+k20+iDzlSaJrinEo5+7vRiteOSwBhHRiAyQATN1AmY4hwzxJKPmYf+w==", + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/is-data-view/-/is-data-view-1.0.2.tgz", + "integrity": "sha512-RKtWF8pGmS87i2D6gqQu/l7EYRlVdfzemCJN/P3UOs//x1QE7mfhvzHIApBTRf7axvT6DMGwSwBXYCT0nfB9xw==", "dev": true, "license": "MIT", "dependencies": { + "call-bound": "^1.0.2", + "get-intrinsic": "^1.2.6", "is-typed-array": "^1.1.13" }, "engines": { @@ -3527,13 +2909,14 @@ } }, "node_modules/is-date-object": { - "version": "1.0.5", - "resolved": "https://registry.npmjs.org/is-date-object/-/is-date-object-1.0.5.tgz", - "integrity": "sha512-9YQaSxsAiSwcvS33MBk3wTCVnWK+HhF8VZR2jRxehM16QcVOdHqPn4VPHmRK4lSr38n9JriurInLcP90xsYNfQ==", + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/is-date-object/-/is-date-object-1.1.0.tgz", + "integrity": "sha512-PwwhEakHVKTdRNVOw+/Gyh0+MzlCl4R6qKvkhuvLtPMggI1WAHt9sOwZxQLSGpUaDnrdyDsomoRgNnCfKNSXXg==", "dev": true, "license": "MIT", "dependencies": { - "has-tostringtag": "^1.0.0" + "call-bound": "^1.0.2", + "has-tostringtag": "^1.0.2" }, "engines": { "node": ">= 0.4" @@ -3570,6 +2953,22 @@ "node": ">=0.10.0" } }, + "node_modules/is-finalizationregistry": { + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/is-finalizationregistry/-/is-finalizationregistry-1.1.1.tgz", + "integrity": "sha512-1pC6N8qWJbWoPtEjgcL2xyhQOP491EQjeUo3qTKcmV8YSDDJrOepfG8pcC7h/QgnQHYSv0mJ3Z/ZWxmatVrysg==", + "dev": true, + "license": "MIT", + "dependencies": { + "call-bound": "^1.0.3" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, "node_modules/is-fullwidth-code-point": { "version": "3.0.0", "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz", @@ -3580,6 +2979,25 @@ "node": ">=8" } }, + "node_modules/is-generator-function": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/is-generator-function/-/is-generator-function-1.1.0.tgz", + "integrity": "sha512-nPUB5km40q9e8UfN/Zc24eLlzdSf9OfKByBw9CIdw4H1giPMeA0OIJvbchsCu4npfI2QcMVBsGEBHKZ7wLTWmQ==", + "dev": true, + "license": "MIT", + "dependencies": { + "call-bound": "^1.0.3", + "get-proto": "^1.0.0", + "has-tostringtag": "^1.0.2", + "safe-regex-test": "^1.1.0" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, "node_modules/is-glob": { "version": "4.0.3", "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz", @@ -3604,20 +3022,10 @@ "url": "https://github.com/sponsors/wooorm" } }, - "node_modules/is-interactive": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/is-interactive/-/is-interactive-1.0.0.tgz", - "integrity": "sha512-2HvIEKRoqS62guEC+qBjpvRubdX910WCMuJTZ+I9yvqKU2/12eSL549HMwtabb4oupdj2sMP50k+XJfB/8JE6w==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=8" - } - }, - "node_modules/is-negative-zero": { + "node_modules/is-map": { "version": "2.0.3", - "resolved": "https://registry.npmjs.org/is-negative-zero/-/is-negative-zero-2.0.3.tgz", - "integrity": "sha512-5KoIu2Ngpyek75jXodFvnafB6DJgr3u8uuK0LEZJjrU19DrMD3EVERaR8sjz8CCGgpZvxPl9SuE1GMVPFHx1mw==", + "resolved": "https://registry.npmjs.org/is-map/-/is-map-2.0.3.tgz", + "integrity": "sha512-1Qed0/Hr2m+YqxnM09CjA2d/i6YZNfF6R2oRAOj36eUdS6qIV/huPJNSEpKbupewFs+ZsJlxsjjPbc0/afW6Lw==", "dev": true, "license": "MIT", "engines": { @@ -3638,13 +3046,14 @@ } }, "node_modules/is-number-object": { - "version": "1.0.7", - "resolved": "https://registry.npmjs.org/is-number-object/-/is-number-object-1.0.7.tgz", - "integrity": "sha512-k1U0IRzLMo7ZlYIfzRu23Oh6MiIFasgpb9X76eqfFZAqwH44UI4KTBvBYIZ1dSL9ZzChTB9ShHfLkR4pdW5krQ==", + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/is-number-object/-/is-number-object-1.1.1.tgz", + "integrity": "sha512-lZhclumE1G6VYD8VHe35wFaIif+CTy5SJIi5+3y4psDgWu4wPDoBhF8NxUOinEc7pHgiTsT6MaBb92rKhhD+Xw==", "dev": true, "license": "MIT", "dependencies": { - "has-tostringtag": "^1.0.0" + "call-bound": "^1.0.3", + "has-tostringtag": "^1.0.2" }, "engines": { "node": ">= 0.4" @@ -3667,15 +3076,30 @@ } }, "node_modules/is-regex": { - "version": "1.1.4", - "resolved": "https://registry.npmjs.org/is-regex/-/is-regex-1.1.4.tgz", - "integrity": "sha512-kvRdxDsxZjhzUX07ZnLydzS1TU/TJlTUHHY4YLL87e37oUA49DfkLqgy+VjFocowy29cKvcSiu+kIv728jTTVg==", + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/is-regex/-/is-regex-1.2.1.tgz", + "integrity": "sha512-MjYsKHO5O7mCsmRGxWcLWheFqN9DJ/2TmngvjKXihe6efViPqc274+Fx/4fYj/r03+ESvBdTXK0V6tA3rgez1g==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.2", - "has-tostringtag": "^1.0.0" + "call-bound": "^1.0.2", + "gopd": "^1.2.0", + "has-tostringtag": "^1.0.2", + "hasown": "^2.0.2" + }, + "engines": { + "node": ">= 0.4" }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-set": { + "version": "2.0.3", + "resolved": "https://registry.npmjs.org/is-set/-/is-set-2.0.3.tgz", + "integrity": "sha512-iPAjerrse27/ygGLxw+EBR9agv9Y6uLeYVJMu+QNCoouJ1/1ri0mGrcWpfCqFZuzzx3WjtwxG098X+n4OuRkPg==", + "dev": true, + "license": "MIT", "engines": { "node": ">= 0.4" }, @@ -3684,13 +3108,13 @@ } }, "node_modules/is-shared-array-buffer": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/is-shared-array-buffer/-/is-shared-array-buffer-1.0.3.tgz", - "integrity": "sha512-nA2hv5XIhLR3uVzDDfCIknerhx8XUKnstuOERPNNIinXG7v9u+ohXF67vxm4TPTEPU6lm61ZkwP3c9PCB97rhg==", + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/is-shared-array-buffer/-/is-shared-array-buffer-1.0.4.tgz", + "integrity": "sha512-ISWac8drv4ZGfwKl5slpHG9OwPNty4jOWPRIhBpxOoD+hqITiwuipOQ2bNthAzwA3B4fIjO4Nln74N0S9byq8A==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.7" + "call-bound": "^1.0.3" }, "engines": { "node": ">= 0.4" @@ -3700,13 +3124,14 @@ } }, "node_modules/is-string": { - "version": "1.0.7", - "resolved": "https://registry.npmjs.org/is-string/-/is-string-1.0.7.tgz", - "integrity": "sha512-tE2UXzivje6ofPW7l23cjDOMa09gb7xlAqG6jG5ej6uPV32TlWP3NKPigtaGeHNu9fohccRYvIiZMfOOnOYUtg==", + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/is-string/-/is-string-1.1.1.tgz", + "integrity": "sha512-BtEeSsoaQjlSPBemMQIrY1MY0uM6vnS1g5fmufYOtnxLGUZM2178PKbhsk7Ffv58IX+ZtcvoGwccYsh0PglkAA==", "dev": true, "license": "MIT", "dependencies": { - "has-tostringtag": "^1.0.0" + "call-bound": "^1.0.3", + "has-tostringtag": "^1.0.2" }, "engines": { "node": ">= 0.4" @@ -3716,13 +3141,15 @@ } }, "node_modules/is-symbol": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/is-symbol/-/is-symbol-1.0.4.tgz", - "integrity": "sha512-C/CPBqKWnvdcxqIARxyOh4v1UUEOCHpgDa0WYgpKDFMszcrPcffg5uhwSgPCLD2WWxmq6isisz87tzT01tuGhg==", + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/is-symbol/-/is-symbol-1.1.1.tgz", + "integrity": "sha512-9gGx6GTtCQM73BgmHQXfDmLtfjjTUDSyoxTCbp5WtoixAhfgsDirWIcVQ/IHpvI5Vgd5i/J5F7B9cN/WlVbC/w==", "dev": true, "license": "MIT", "dependencies": { - "has-symbols": "^1.0.2" + "call-bound": "^1.0.2", + "has-symbols": "^1.1.0", + "safe-regex-test": "^1.1.0" }, "engines": { "node": ">= 0.4" @@ -3732,13 +3159,13 @@ } }, "node_modules/is-typed-array": { - "version": "1.1.13", - "resolved": "https://registry.npmjs.org/is-typed-array/-/is-typed-array-1.1.13.tgz", - "integrity": "sha512-uZ25/bUAlUY5fR4OKT4rZQEBrzQWYV9ZJYGGsUmEJ6thodVJ1HX64ePQ6Z0qPWP+m+Uq6e9UugrE38jeYsDSMw==", + "version": "1.1.15", + "resolved": "https://registry.npmjs.org/is-typed-array/-/is-typed-array-1.1.15.tgz", + "integrity": "sha512-p3EcsicXjit7SaskXHs1hA91QxgTw46Fv6EFKKGS5DRFLD8yKnohjF3hxoju94b/OcMZoQukzpPpBE9uLVKzgQ==", "dev": true, "license": "MIT", "dependencies": { - "which-typed-array": "^1.1.14" + "which-typed-array": "^1.1.16" }, "engines": { "node": ">= 0.4" @@ -3747,27 +3174,47 @@ "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/is-unicode-supported": { - "version": "0.1.0", - "resolved": "https://registry.npmjs.org/is-unicode-supported/-/is-unicode-supported-0.1.0.tgz", - "integrity": "sha512-knxG2q4UC3u8stRGyAVJCOdxFmv5DZiRcdlIaAQXAbSfJya+OhopNotLQrstBhququ4ZpuKbDc/8S6mgXgPFPw==", + "node_modules/is-weakmap": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/is-weakmap/-/is-weakmap-2.0.2.tgz", + "integrity": "sha512-K5pXYOm9wqY1RgjpL3YTkF39tni1XajUIkawTLUo9EZEVUFga5gSQJF8nNS7ZwJQ02y+1YCNYcMh+HIf1ZqE+w==", "dev": true, "license": "MIT", "engines": { - "node": ">=10" + "node": ">= 0.4" }, "funding": { - "url": "https://github.com/sponsors/sindresorhus" + "url": "https://github.com/sponsors/ljharb" } }, "node_modules/is-weakref": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/is-weakref/-/is-weakref-1.0.2.tgz", - "integrity": "sha512-qctsuLZmIQ0+vSSMfoVvyFe2+GSEvnmZ2ezTup1SBse9+twCCeial6EEi3Nc2KFcf6+qz2FBPnjXsk8xhKSaPQ==", + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/is-weakref/-/is-weakref-1.1.1.tgz", + "integrity": "sha512-6i9mGWSlqzNMEqpCp93KwRS1uUOodk2OJ6b+sq7ZPDSy2WuI5NFIxp/254TytR8ftefexkWn5xNiHUNpPOfSew==", + "dev": true, + "license": "MIT", + "dependencies": { + "call-bound": "^1.0.3" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/is-weakset": { + "version": "2.0.4", + "resolved": "https://registry.npmjs.org/is-weakset/-/is-weakset-2.0.4.tgz", + "integrity": "sha512-mfcwb6IzQyOKTs84CQMrOwW4gQcaTOAWJ0zzJCl2WSPDrWk/OzDaImWFH3djXhb24g4eudZfLRozAvPGw4d9hQ==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.2" + "call-bound": "^1.0.3", + "get-intrinsic": "^1.2.6" + }, + "engines": { + "node": ">= 0.4" }, "funding": { "url": "https://github.com/sponsors/ljharb" @@ -3867,19 +3314,6 @@ "json5": "lib/cli.js" } }, - "node_modules/jsonfile": { - "version": "6.1.0", - "resolved": "https://registry.npmjs.org/jsonfile/-/jsonfile-6.1.0.tgz", - "integrity": "sha512-5dgndWOriYSm5cnYaJNhalLNDKOqFwyDB/rr1E9ZsGciGvKPs8R2xYGCacuf3z6K1YKDz182fd+fY3cn3pMqXQ==", - "dev": true, - "license": "MIT", - "dependencies": { - "universalify": "^2.0.0" - }, - "optionalDependencies": { - "graceful-fs": "^4.1.6" - } - }, "node_modules/keyv": { "version": "4.5.4", "resolved": "https://registry.npmjs.org/keyv/-/keyv-4.5.4.tgz", @@ -3962,44 +3396,13 @@ "dev": true, "license": "MIT" }, - "node_modules/lodash.chunk": { - "version": "4.2.0", - "resolved": "https://registry.npmjs.org/lodash.chunk/-/lodash.chunk-4.2.0.tgz", - "integrity": "sha512-ZzydJKfUHJwHa+hF5X66zLFCBrWn5GeF28OHEr4WVWtNDXlQ/IjWKPBiikqKo2ne0+v6JgCgJ0GzJp8k8bHC7w==", - "dev": true, - "license": "MIT" - }, - "node_modules/lodash.get": { - "version": "4.4.2", - "resolved": "https://registry.npmjs.org/lodash.get/-/lodash.get-4.4.2.tgz", - "integrity": "sha512-z+Uw/vLuy6gQe8cfaFWD7p0wVv8fJl3mbzXh33RS+0oW2wvUqiRXiQ69gLWSLpgB5/6sU+r6BlQR0MBILadqTQ==", - "dev": true, - "license": "MIT" - }, - "node_modules/lodash.merge": { - "version": "4.6.2", - "resolved": "https://registry.npmjs.org/lodash.merge/-/lodash.merge-4.6.2.tgz", - "integrity": "sha512-0KpjqXRVvrYyCsX1swR/XTK0va6VQkQM6MNo7PqW77ByjAhoARA8EfrP1N4+KlKj8YS0ZUCtRT/YUuhyYDujIQ==", - "dev": true, - "license": "MIT" - }, - "node_modules/log-symbols": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/log-symbols/-/log-symbols-4.1.0.tgz", - "integrity": "sha512-8XPvpAA8uyhfteu8pIvQxpJZ7SYYdpUivZpGy6sFsBuKRY/7rQGavedeB8aK+Zkyq6upMFVL/9AW6vOYzfRyLg==", - "dev": true, - "license": "MIT", - "dependencies": { - "chalk": "^4.1.0", - "is-unicode-supported": "^0.1.0" - }, - "engines": { - "node": ">=10" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, + "node_modules/lodash.merge": { + "version": "4.6.2", + "resolved": "https://registry.npmjs.org/lodash.merge/-/lodash.merge-4.6.2.tgz", + "integrity": "sha512-0KpjqXRVvrYyCsX1swR/XTK0va6VQkQM6MNo7PqW77ByjAhoARA8EfrP1N4+KlKj8YS0ZUCtRT/YUuhyYDujIQ==", + "dev": true, + "license": "MIT" + }, "node_modules/longest-streak": { "version": "3.1.0", "resolved": "https://registry.npmjs.org/longest-streak/-/longest-streak-3.1.0.tgz", @@ -4011,6 +3414,22 @@ "url": "https://github.com/sponsors/wooorm" } }, + "node_modules/lowlight": { + "version": "3.3.0", + "resolved": "https://registry.npmjs.org/lowlight/-/lowlight-3.3.0.tgz", + "integrity": "sha512-0JNhgFoPvP6U6lE/UdVsSq99tn6DhjjpAj5MxG49ewd2mOBVtwWYIT8ClyABhq198aXXODMU6Ox8DrGy/CpTZQ==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/hast": "^3.0.0", + "devlop": "^1.0.0", + "highlight.js": "~11.11.0" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/wooorm" + } + }, "node_modules/lru-cache": { "version": "10.4.3", "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-10.4.3.tgz", @@ -4032,9 +3451,9 @@ } }, "node_modules/markdown-table": { - "version": "3.0.3", - "resolved": "https://registry.npmjs.org/markdown-table/-/markdown-table-3.0.3.tgz", - "integrity": "sha512-Z1NL3Tb1M9wH4XESsCDEksWoKTdlUafKc4pt0GRwjUyXaCFZ+dc3g2erqB6zm3szA2IUSi7VnPI+o/9jnxh9hw==", + "version": "3.0.4", + "resolved": "https://registry.npmjs.org/markdown-table/-/markdown-table-3.0.4.tgz", + "integrity": "sha512-wiYz4+JrLyb/DqW2hkFJxP7Vd7JuTDm77fvbM8VfEQdmSMqcImWeeRbHwZjBjIFki/VaMK2BhFi7oUUZeM5bqw==", "dev": true, "license": "MIT", "funding": { @@ -4042,16 +3461,14 @@ "url": "https://github.com/sponsors/wooorm" } }, - "node_modules/md5": { - "version": "2.3.0", - "resolved": "https://registry.npmjs.org/md5/-/md5-2.3.0.tgz", - "integrity": "sha512-T1GITYmFaKuO91vxyoQMFETst+O71VUPEU3ze5GNzDm0OWdP8v1ziTaAEPUr/3kLsY3Sftgz242A1SetQiDL7g==", + "node_modules/math-intrinsics": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/math-intrinsics/-/math-intrinsics-1.1.0.tgz", + "integrity": "sha512-/IXtbwEk5HTPyEwyKX6hGkYXxM9nbj64B+ilVJnC/R6B0pH5G4V3b0pVbL7DBj4tkhBAppbQUlf6F6Xl9LHu1g==", "dev": true, - "license": "BSD-3-Clause", - "dependencies": { - "charenc": "0.0.2", - "crypt": "0.0.2", - "is-buffer": "~1.1.6" + "license": "MIT", + "engines": { + "node": ">= 0.4" } }, "node_modules/mdast-builder": { @@ -4080,14 +3497,15 @@ } }, "node_modules/mdast-util-directive": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/mdast-util-directive/-/mdast-util-directive-3.0.0.tgz", - "integrity": "sha512-JUpYOqKI4mM3sZcNxmF/ox04XYFFkNwr0CFlrQIkCwbvH0xzMCqkMqAde9wRd80VAhaUrwFwKm2nxretdT1h7Q==", + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/mdast-util-directive/-/mdast-util-directive-3.1.0.tgz", + "integrity": "sha512-I3fNFt+DHmpWCYAT7quoM6lHf9wuqtI+oCOfvILnoicNIqjh5E3dEJWiXuYME2gNe8vl1iMQwyUHa7bgFmak6Q==", "dev": true, "license": "MIT", "dependencies": { "@types/mdast": "^4.0.0", "@types/unist": "^3.0.0", + "ccount": "^2.0.0", "devlop": "^1.0.0", "mdast-util-from-markdown": "^2.0.0", "mdast-util-to-markdown": "^2.0.0", @@ -4108,9 +3526,9 @@ "license": "MIT" }, "node_modules/mdast-util-find-and-replace": { - "version": "3.0.1", - "resolved": "https://registry.npmjs.org/mdast-util-find-and-replace/-/mdast-util-find-and-replace-3.0.1.tgz", - "integrity": "sha512-SG21kZHGC3XRTSUhtofZkBzZTJNM5ecCi0SK2IMKmSXR8vO3peL+kb1O0z7Zl83jKtutG4k5Wv/W7V3/YHvzPA==", + "version": "3.0.2", + "resolved": "https://registry.npmjs.org/mdast-util-find-and-replace/-/mdast-util-find-and-replace-3.0.2.tgz", + "integrity": "sha512-Tmd1Vg/m3Xz43afeNxDIhWRtFZgM2VLyaf4vSTYwudTyeuTneoL3qtWMA5jeLyz/O1vDJmmV4QuScFCA2tBPwg==", "dev": true, "license": "MIT", "dependencies": { @@ -4138,9 +3556,9 @@ } }, "node_modules/mdast-util-from-markdown": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/mdast-util-from-markdown/-/mdast-util-from-markdown-2.0.1.tgz", - "integrity": "sha512-aJEUyzZ6TzlsX2s5B4Of7lN7EQtAxvtradMMglCQDyaTFgse6CmtmdJ15ElnVRlCg1vpNyVtbem0PWzlNieZsA==", + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/mdast-util-from-markdown/-/mdast-util-from-markdown-2.0.2.tgz", + "integrity": "sha512-uZhTV/8NBuw0WHkPTrCqDOl0zVe1BIng5ZtHoDk49ME1qqcjYmmLmOf0gELgcRMxN4w2iuIeVso5/6QymSrgmA==", "dev": true, "license": "MIT", "dependencies": { @@ -4170,9 +3588,9 @@ "license": "MIT" }, "node_modules/mdast-util-gfm": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/mdast-util-gfm/-/mdast-util-gfm-3.0.0.tgz", - "integrity": "sha512-dgQEX5Amaq+DuUqf26jJqSK9qgixgd6rYDHAv4aTBuA92cTknZlKpPfa86Z/s8Dj8xsAQpFfBmPUHWJBWqS4Bw==", + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/mdast-util-gfm/-/mdast-util-gfm-3.1.0.tgz", + "integrity": "sha512-0ulfdQOM3ysHhCJ1p06l0b0VKlhU0wuQs3thxZQagjcjPrlFRqY215uZGHHJan9GEAXd9MbfPjFJz+qMkVR6zQ==", "dev": true, "license": "MIT", "dependencies": { @@ -4208,9 +3626,9 @@ } }, "node_modules/mdast-util-gfm-footnote": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/mdast-util-gfm-footnote/-/mdast-util-gfm-footnote-2.0.0.tgz", - "integrity": "sha512-5jOT2boTSVkMnQ7LTrd6n/18kqwjmuYqo7JUPe+tRCY6O7dAuTFMtTPauYYrMPpox9hlN0uOx/FL8XvEfG9/mQ==", + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/mdast-util-gfm-footnote/-/mdast-util-gfm-footnote-2.1.0.tgz", + "integrity": "sha512-sqpDWlsHn7Ac9GNZQMeUzPQSMzR6Wv0WKRNvQRg0KqHh02fpTz69Qc1QSseNX29bhz1ROIyNyxExfawVKTm1GQ==", "dev": true, "license": "MIT", "dependencies": { @@ -4328,9 +3746,9 @@ } }, "node_modules/mdast-util-mdx-jsx": { - "version": "3.1.3", - "resolved": "https://registry.npmjs.org/mdast-util-mdx-jsx/-/mdast-util-mdx-jsx-3.1.3.tgz", - "integrity": "sha512-bfOjvNt+1AcbPLTFMFWY149nJz0OjmewJs3LQQ5pIyVGxP4CdOqNVJL6kTaM5c68p8q82Xv3nCyFfUnuEcH3UQ==", + "version": "3.2.0", + "resolved": "https://registry.npmjs.org/mdast-util-mdx-jsx/-/mdast-util-mdx-jsx-3.2.0.tgz", + "integrity": "sha512-lj/z8v0r6ZtsN/cGNNtemmmfoLAFZnjMbNyLzBafjzikOM+glrjNHPlf6lQDOTccj9n5b0PPihEBbhneMyGs1Q==", "dev": true, "license": "MIT", "dependencies": { @@ -4416,9 +3834,9 @@ } }, "node_modules/mdast-util-to-markdown": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/mdast-util-to-markdown/-/mdast-util-to-markdown-2.1.0.tgz", - "integrity": "sha512-SR2VnIEdVNCJbP6y7kVTJgPLifdr8WEU440fQec7qHoHOUz/oJ2jmNRqdDQ3rbiStOXb2mCDGTuwsK5OPUgYlQ==", + "version": "2.1.2", + "resolved": "https://registry.npmjs.org/mdast-util-to-markdown/-/mdast-util-to-markdown-2.1.2.tgz", + "integrity": "sha512-xj68wMTvGXVOKonmog6LwyJKrYXZPvlwabaryTjLh9LuvovB/KAH+kvi8Gjj+7rJjsFi23nkUxRQv1KqSroMqA==", "dev": true, "license": "MIT", "dependencies": { @@ -4427,6 +3845,7 @@ "longest-streak": "^3.0.0", "mdast-util-phrasing": "^4.0.0", "mdast-util-to-string": "^4.0.0", + "micromark-util-classify-character": "^2.0.0", "micromark-util-decode-string": "^2.0.0", "unist-util-visit": "^5.0.0", "zwitch": "^2.0.0" @@ -4468,9 +3887,9 @@ } }, "node_modules/micromark": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/micromark/-/micromark-4.0.0.tgz", - "integrity": "sha512-o/sd0nMof8kYff+TqcDx3VSrgBTcZpSvYcAHIfHhv5VAuNmisCxjhx6YmxS8PFEpb9z5WKWKPdzf0jM23ro3RQ==", + "version": "4.0.2", + "resolved": "https://registry.npmjs.org/micromark/-/micromark-4.0.2.tgz", + "integrity": "sha512-zpe98Q6kvavpCr1NPVSCMebCKfD7CA2NqZ+rykeNhONIJBpc1tFKt9hucLGwha3jNTNI8lHpctWJWoimVF4PfA==", "dev": true, "funding": [ { @@ -4504,9 +3923,9 @@ } }, "node_modules/micromark-core-commonmark": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-core-commonmark/-/micromark-core-commonmark-2.0.1.tgz", - "integrity": "sha512-CUQyKr1e///ZODyD1U3xit6zXwy1a8q2a1S1HKtIlmgvurrEpaw/Y9y6KSIbF8P59cn/NjzHyO+Q2fAyYLQrAA==", + "version": "2.0.3", + "resolved": "https://registry.npmjs.org/micromark-core-commonmark/-/micromark-core-commonmark-2.0.3.tgz", + "integrity": "sha512-RDBrHEMSxVFLg6xvnXmb1Ayr2WzLAWjeSATAoxwKYJV94TeNavgoIdA0a9ytzDSVzBy2YKFK+emCPOEibLeCrg==", "dev": true, "funding": [ { @@ -4617,9 +4036,9 @@ } }, "node_modules/micromark-extension-gfm-table": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/micromark-extension-gfm-table/-/micromark-extension-gfm-table-2.1.0.tgz", - "integrity": "sha512-Ub2ncQv+fwD70/l4ou27b4YzfNaCJOvyX4HxXU15m7mpYY+rjuWzsLIPZHJL253Z643RpbcP1oeIJlQ/SKW67g==", + "version": "2.1.1", + "resolved": "https://registry.npmjs.org/micromark-extension-gfm-table/-/micromark-extension-gfm-table-2.1.1.tgz", + "integrity": "sha512-t2OU/dXXioARrC6yWfJ4hqB7rct14e8f7m0cbI5hUmDyyIlwv5vEtooptH8INkbLzOatzKuVbQmAYcbWoyz6Dg==", "dev": true, "license": "MIT", "dependencies": { @@ -4667,9 +4086,9 @@ } }, "node_modules/micromark-factory-destination": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-factory-destination/-/micromark-factory-destination-2.0.0.tgz", - "integrity": "sha512-j9DGrQLm/Uhl2tCzcbLhy5kXsgkHUrjJHg4fFAeoMRwJmJerT9aw4FEhIbZStWN8A3qMwOp1uzHr4UL8AInxtA==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-factory-destination/-/micromark-factory-destination-2.0.1.tgz", + "integrity": "sha512-Xe6rDdJlkmbFRExpTOmRj9N3MaWmbAgdpSrBQvCFqhezUn4AHqJHbaEnfbVYYiexVSs//tqOdY/DxhjdCiJnIA==", "dev": true, "funding": [ { @@ -4689,9 +4108,9 @@ } }, "node_modules/micromark-factory-label": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-factory-label/-/micromark-factory-label-2.0.0.tgz", - "integrity": "sha512-RR3i96ohZGde//4WSe/dJsxOX6vxIg9TimLAS3i4EhBAFx8Sm5SmqVfR8E87DPSR31nEAjZfbt91OMZWcNgdZw==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-factory-label/-/micromark-factory-label-2.0.1.tgz", + "integrity": "sha512-VFMekyQExqIW7xIChcXn4ok29YE3rnuyveW3wZQWWqF4Nv9Wk5rgJ99KzPvHjkmPXF93FXIbBp6YdW3t71/7Vg==", "dev": true, "funding": [ { @@ -4712,9 +4131,9 @@ } }, "node_modules/micromark-factory-space": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-factory-space/-/micromark-factory-space-2.0.0.tgz", - "integrity": "sha512-TKr+LIDX2pkBJXFLzpyPyljzYK3MtmllMUMODTQJIUfDGncESaqB90db9IAUcz4AZAJFdd8U9zOp9ty1458rxg==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-factory-space/-/micromark-factory-space-2.0.1.tgz", + "integrity": "sha512-zRkxjtBxxLd2Sc0d+fbnEunsTj46SWXgXciZmHq0kDYGnck/ZSGj9/wULTV95uoeYiK5hRXP2mJ98Uo4cq/LQg==", "dev": true, "funding": [ { @@ -4733,9 +4152,9 @@ } }, "node_modules/micromark-factory-title": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-factory-title/-/micromark-factory-title-2.0.0.tgz", - "integrity": "sha512-jY8CSxmpWLOxS+t8W+FG3Xigc0RDQA9bKMY/EwILvsesiRniiVMejYTE4wumNc2f4UbAa4WsHqe3J1QS1sli+A==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-factory-title/-/micromark-factory-title-2.0.1.tgz", + "integrity": "sha512-5bZ+3CjhAd9eChYTHsjy6TGxpOFSKgKKJPJxr293jTbfry2KDoWkhBb6TcPVB4NmzaPhMs1Frm9AZH7OD4Cjzw==", "dev": true, "funding": [ { @@ -4756,9 +4175,9 @@ } }, "node_modules/micromark-factory-whitespace": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-factory-whitespace/-/micromark-factory-whitespace-2.0.0.tgz", - "integrity": "sha512-28kbwaBjc5yAI1XadbdPYHX/eDnqaUFVikLwrO7FDnKG7lpgxnvk/XGRhX/PN0mOZ+dBSZ+LgunHS+6tYQAzhA==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-factory-whitespace/-/micromark-factory-whitespace-2.0.1.tgz", + "integrity": "sha512-Ob0nuZ3PKt/n0hORHyvoD9uZhr+Za8sFoP+OnMcnWK5lngSzALgQYKMr9RJVOWLqQYuyn6ulqGWSXdwf6F80lQ==", "dev": true, "funding": [ { @@ -4779,9 +4198,9 @@ } }, "node_modules/micromark-util-character": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/micromark-util-character/-/micromark-util-character-2.1.0.tgz", - "integrity": "sha512-KvOVV+X1yLBfs9dCBSopq/+G1PcgT3lAK07mC4BzXi5E7ahzMAF8oIupDDJ6mievI6F+lAATkbQQlQixJfT3aQ==", + "version": "2.1.1", + "resolved": "https://registry.npmjs.org/micromark-util-character/-/micromark-util-character-2.1.1.tgz", + "integrity": "sha512-wv8tdUTJ3thSFFFJKtpYKOYiGP2+v96Hvk4Tu8KpCAsTMs6yi+nVmGh1syvSCsaxz45J6Jbw+9DD6g97+NV67Q==", "dev": true, "funding": [ { @@ -4800,9 +4219,9 @@ } }, "node_modules/micromark-util-chunked": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-util-chunked/-/micromark-util-chunked-2.0.0.tgz", - "integrity": "sha512-anK8SWmNphkXdaKgz5hJvGa7l00qmcaUQoMYsBwDlSKFKjc6gjGXPDw3FNL3Nbwq5L8gE+RCbGqTw49FK5Qyvg==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-util-chunked/-/micromark-util-chunked-2.0.1.tgz", + "integrity": "sha512-QUNFEOPELfmvv+4xiNg2sRYeS/P84pTW0TCgP5zc9FpXetHY0ab7SxKyAQCNCc1eK0459uoLI1y5oO5Vc1dbhA==", "dev": true, "funding": [ { @@ -4820,9 +4239,9 @@ } }, "node_modules/micromark-util-classify-character": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-util-classify-character/-/micromark-util-classify-character-2.0.0.tgz", - "integrity": "sha512-S0ze2R9GH+fu41FA7pbSqNWObo/kzwf8rN/+IGlW/4tC6oACOs8B++bh+i9bVyNnwCcuksbFwsBme5OCKXCwIw==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-util-classify-character/-/micromark-util-classify-character-2.0.1.tgz", + "integrity": "sha512-K0kHzM6afW/MbeWYWLjoHQv1sgg2Q9EccHEDzSkxiP/EaagNzCm7T/WMKZ3rjMbvIpvBiZgwR3dKMygtA4mG1Q==", "dev": true, "funding": [ { @@ -4842,9 +4261,9 @@ } }, "node_modules/micromark-util-combine-extensions": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-util-combine-extensions/-/micromark-util-combine-extensions-2.0.0.tgz", - "integrity": "sha512-vZZio48k7ON0fVS3CUgFatWHoKbbLTK/rT7pzpJ4Bjp5JjkZeasRfrS9wsBdDJK2cJLHMckXZdzPSSr1B8a4oQ==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-util-combine-extensions/-/micromark-util-combine-extensions-2.0.1.tgz", + "integrity": "sha512-OnAnH8Ujmy59JcyZw8JSbK9cGpdVY44NKgSM7E9Eh7DiLS2E9RNQf0dONaGDzEG9yjEl5hcqeIsj4hfRkLH/Bg==", "dev": true, "funding": [ { @@ -4863,9 +4282,9 @@ } }, "node_modules/micromark-util-decode-numeric-character-reference": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-util-decode-numeric-character-reference/-/micromark-util-decode-numeric-character-reference-2.0.1.tgz", - "integrity": "sha512-bmkNc7z8Wn6kgjZmVHOX3SowGmVdhYS7yBpMnuMnPzDq/6xwVA604DuOXMZTO1lvq01g+Adfa0pE2UKGlxL1XQ==", + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/micromark-util-decode-numeric-character-reference/-/micromark-util-decode-numeric-character-reference-2.0.2.tgz", + "integrity": "sha512-ccUbYk6CwVdkmCQMyr64dXz42EfHGkPQlBj5p7YVGzq8I7CtjXZJrubAYezf7Rp+bjPseiROqe7G6foFd+lEuw==", "dev": true, "funding": [ { @@ -4883,9 +4302,9 @@ } }, "node_modules/micromark-util-decode-string": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-util-decode-string/-/micromark-util-decode-string-2.0.0.tgz", - "integrity": "sha512-r4Sc6leeUTn3P6gk20aFMj2ntPwn6qpDZqWvYmAG6NgvFTIlj4WtrAudLi65qYoaGdXYViXYw2pkmn7QnIFasA==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-util-decode-string/-/micromark-util-decode-string-2.0.1.tgz", + "integrity": "sha512-nDV/77Fj6eH1ynwscYTOsbK7rR//Uj0bZXBwJZRfaLEJ1iGBR6kIfNmlNqaqJf649EP0F3NWNdeJi03elllNUQ==", "dev": true, "funding": [ { @@ -4906,9 +4325,9 @@ } }, "node_modules/micromark-util-encode": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-util-encode/-/micromark-util-encode-2.0.0.tgz", - "integrity": "sha512-pS+ROfCXAGLWCOc8egcBvT0kf27GoWMqtdarNfDcjb6YLuV5cM3ioG45Ys2qOVqeqSbjaKg72vU+Wby3eddPsA==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-util-encode/-/micromark-util-encode-2.0.1.tgz", + "integrity": "sha512-c3cVx2y4KqUnwopcO9b/SCdo2O67LwJJ/UyqGfbigahfegL9myoEFoDYZgkT7f36T0bLrM9hZTAaAyH+PCAXjw==", "dev": true, "funding": [ { @@ -4923,9 +4342,9 @@ "license": "MIT" }, "node_modules/micromark-util-html-tag-name": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-util-html-tag-name/-/micromark-util-html-tag-name-2.0.0.tgz", - "integrity": "sha512-xNn4Pqkj2puRhKdKTm8t1YHC/BAjx6CEwRFXntTaRf/x16aqka6ouVoutm+QdkISTlT7e2zU7U4ZdlDLJd2Mcw==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-util-html-tag-name/-/micromark-util-html-tag-name-2.0.1.tgz", + "integrity": "sha512-2cNEiYDhCWKI+Gs9T0Tiysk136SnR13hhO8yW6BGNyhOC4qYFnwF1nKfD3HFAIXA5c45RrIG1ub11GiXeYd1xA==", "dev": true, "funding": [ { @@ -4940,9 +4359,9 @@ "license": "MIT" }, "node_modules/micromark-util-normalize-identifier": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-util-normalize-identifier/-/micromark-util-normalize-identifier-2.0.0.tgz", - "integrity": "sha512-2xhYT0sfo85FMrUPtHcPo2rrp1lwbDEEzpx7jiH2xXJLqBuy4H0GgXk5ToU8IEwoROtXuL8ND0ttVa4rNqYK3w==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-util-normalize-identifier/-/micromark-util-normalize-identifier-2.0.1.tgz", + "integrity": "sha512-sxPqmo70LyARJs0w2UclACPUUEqltCkJ6PhKdMIDuJ3gSf/Q+/GIe3WKl0Ijb/GyH9lOpUkRAO2wp0GVkLvS9Q==", "dev": true, "funding": [ { @@ -4960,9 +4379,9 @@ } }, "node_modules/micromark-util-resolve-all": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-util-resolve-all/-/micromark-util-resolve-all-2.0.0.tgz", - "integrity": "sha512-6KU6qO7DZ7GJkaCgwBNtplXCvGkJToU86ybBAUdavvgsCiG8lSSvYxr9MhwmQ+udpzywHsl4RpGJsYWG1pDOcA==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-util-resolve-all/-/micromark-util-resolve-all-2.0.1.tgz", + "integrity": "sha512-VdQyxFWFT2/FGJgwQnJYbe1jjQoNTS4RjglmSjTUlpUMa95Htx9NHeYW4rGDJzbjvCsl9eLjMQwGeElsqmzcHg==", "dev": true, "funding": [ { @@ -4980,9 +4399,9 @@ } }, "node_modules/micromark-util-sanitize-uri": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-util-sanitize-uri/-/micromark-util-sanitize-uri-2.0.0.tgz", - "integrity": "sha512-WhYv5UEcZrbAtlsnPuChHUAsu/iBPOVaEVsntLBIdpibO0ddy8OzavZz3iL2xVvBZOpolujSliP65Kq0/7KIYw==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-util-sanitize-uri/-/micromark-util-sanitize-uri-2.0.1.tgz", + "integrity": "sha512-9N9IomZ/YuGGZZmQec1MbgxtlgougxTodVwDzzEouPKo3qFWvymFHWcnDi2vzV1ff6kas9ucW+o3yzJK9YB1AQ==", "dev": true, "funding": [ { @@ -5002,9 +4421,9 @@ } }, "node_modules/micromark-util-subtokenize": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-util-subtokenize/-/micromark-util-subtokenize-2.0.1.tgz", - "integrity": "sha512-jZNtiFl/1aY73yS3UGQkutD0UbhTt68qnRpw2Pifmz5wV9h8gOVsN70v+Lq/f1rKaU/W8pxRe8y8Q9FX1AOe1Q==", + "version": "2.1.0", + "resolved": "https://registry.npmjs.org/micromark-util-subtokenize/-/micromark-util-subtokenize-2.1.0.tgz", + "integrity": "sha512-XQLu552iSctvnEcgXw6+Sx75GflAPNED1qx7eBJ+wydBb2KCbRZe+NwvIEEMM83uml1+2WSXpBAcp9IUCgCYWA==", "dev": true, "funding": [ { @@ -5025,9 +4444,9 @@ } }, "node_modules/micromark-util-symbol": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-util-symbol/-/micromark-util-symbol-2.0.0.tgz", - "integrity": "sha512-8JZt9ElZ5kyTnO94muPxIGS8oyElRJaiJO8EzV6ZSyGQ1Is8xwl4Q45qU5UOg+bGH4AikWziz0iN4sFLWs8PGw==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/micromark-util-symbol/-/micromark-util-symbol-2.0.1.tgz", + "integrity": "sha512-vs5t8Apaud9N28kgCrRUdEed4UJ+wWNvicHLPxCa9ENlYuAY31M0ETy5y1vA33YoNPDFTghEbnh6efaE8h4x0Q==", "dev": true, "funding": [ { @@ -5042,9 +4461,9 @@ "license": "MIT" }, "node_modules/micromark-util-types": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/micromark-util-types/-/micromark-util-types-2.0.0.tgz", - "integrity": "sha512-oNh6S2WMHWRZrmutsRmDDfkzKtxF+bc2VxLC9dvtrDIRFln627VsFP6fLMgTryGDljgLPjkrzQSDcPrjPyDJ5w==", + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/micromark-util-types/-/micromark-util-types-2.0.2.tgz", + "integrity": "sha512-Yw0ECSpJoViF1qTU4DC6NwtC4aWGt1EkzaQB8KPPyCRR8z9TWeV0HbEFGTO+ZY1wB22zmxnJqhPyTpOVCpeHTA==", "dev": true, "funding": [ { @@ -5072,27 +4491,33 @@ "node": ">=8.6" } }, - "node_modules/mimic-fn": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/mimic-fn/-/mimic-fn-2.1.0.tgz", - "integrity": "sha512-OqbOk5oEQeAZ8WXWydlu9HJjz9WVdEIvamMCcXmuqUYjTknH/sqsWvhQ3vgwKFRR1HpjvNBKQ37nbJgYzGqGcg==", + "node_modules/micromatch/node_modules/picomatch": { + "version": "2.3.1", + "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz", + "integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==", "dev": true, "license": "MIT", "engines": { - "node": ">=6" + "node": ">=8.6" + }, + "funding": { + "url": "https://github.com/sponsors/jonschlinkert" } }, "node_modules/minimatch": { - "version": "3.1.2", - "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz", - "integrity": "sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==", + "version": "9.0.5", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.5.tgz", + "integrity": "sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==", "dev": true, "license": "ISC", "dependencies": { - "brace-expansion": "^1.1.7" + "brace-expansion": "^2.0.1" }, "engines": { - "node": "*" + "node": ">=16 || 14 >=14.17" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" } }, "node_modules/minimist": { @@ -5116,19 +4541,12 @@ } }, "node_modules/ms": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz", - "integrity": "sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==", + "version": "2.1.3", + "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz", + "integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==", "dev": true, "license": "MIT" }, - "node_modules/mute-stream": { - "version": "0.0.8", - "resolved": "https://registry.npmjs.org/mute-stream/-/mute-stream-0.0.8.tgz", - "integrity": "sha512-nnbWWOkoWyUsTjKrhgD0dcz22mdkSnpYqbEjIm2nhwhuxlSkpywJmBo8h0ZqJdkp73mb90SssHkN4rsRaBAfAA==", - "dev": true, - "license": "ISC" - }, "node_modules/natural-compare": { "version": "1.4.0", "resolved": "https://registry.npmjs.org/natural-compare/-/natural-compare-1.4.0.tgz", @@ -5167,19 +4585,6 @@ "node": "^16.14.0 || >=18.0.0" } }, - "node_modules/normalize-package-data/node_modules/semver": { - "version": "7.6.3", - "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", - "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", - "dev": true, - "license": "ISC", - "bin": { - "semver": "bin/semver.js" - }, - "engines": { - "node": ">=10" - } - }, "node_modules/normalize-path": { "version": "3.0.0", "resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz", @@ -5203,19 +4608,6 @@ "node": "^14.17.0 || ^16.13.0 || >=18.0.0" } }, - "node_modules/npm-install-checks/node_modules/semver": { - "version": "7.6.3", - "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", - "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", - "dev": true, - "license": "ISC", - "bin": { - "semver": "bin/semver.js" - }, - "engines": { - "node": ">=10" - } - }, "node_modules/npm-normalize-package-bin": { "version": "3.0.1", "resolved": "https://registry.npmjs.org/npm-normalize-package-bin/-/npm-normalize-package-bin-3.0.1.tgz", @@ -5242,19 +4634,6 @@ "node": "^16.14.0 || >=18.0.0" } }, - "node_modules/npm-package-arg/node_modules/semver": { - "version": "7.6.3", - "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", - "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", - "dev": true, - "license": "ISC", - "bin": { - "semver": "bin/semver.js" - }, - "engines": { - "node": ">=10" - } - }, "node_modules/npm-pick-manifest": { "version": "9.1.0", "resolved": "https://registry.npmjs.org/npm-pick-manifest/-/npm-pick-manifest-9.1.0.tgz", @@ -5271,36 +4650,10 @@ "node": "^16.14.0 || >=18.0.0" } }, - "node_modules/npm-pick-manifest/node_modules/semver": { - "version": "7.6.3", - "resolved": "https://registry.npmjs.org/semver/-/semver-7.6.3.tgz", - "integrity": "sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==", - "dev": true, - "license": "ISC", - "bin": { - "semver": "bin/semver.js" - }, - "engines": { - "node": ">=10" - } - }, - "node_modules/nth-check": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/nth-check/-/nth-check-2.1.1.tgz", - "integrity": "sha512-lqjrjmaOoAnWfMmBPL+XNnynZh2+swxiX3WUE0s4yEHI6m+AwrK2UZOimIRl3X/4QctVqS8AiZjFqyOGrMXb/w==", - "dev": true, - "license": "BSD-2-Clause", - "dependencies": { - "boolbase": "^1.0.0" - }, - "funding": { - "url": "https://github.com/fb55/nth-check?sponsor=1" - } - }, "node_modules/object-inspect": { - "version": "1.13.2", - "resolved": "https://registry.npmjs.org/object-inspect/-/object-inspect-1.13.2.tgz", - "integrity": "sha512-IRZSRuzJiynemAXPYtPe5BoI/RESNYR7TYm50MC5Mqbd3Jmw5y790sErYw3V6SryFJD64b74qQQs9wn5Bg/k3g==", + "version": "1.13.4", + "resolved": "https://registry.npmjs.org/object-inspect/-/object-inspect-1.13.4.tgz", + "integrity": "sha512-W67iLl4J2EXEGTbfeHCffrjDfitvLANg0UlX3wFUUSTx92KXRFegMHUVgSqE+wvhAbi4WqjGg9czysTV2Epbew==", "dev": true, "license": "MIT", "engines": { @@ -5321,15 +4674,17 @@ } }, "node_modules/object.assign": { - "version": "4.1.5", - "resolved": "https://registry.npmjs.org/object.assign/-/object.assign-4.1.5.tgz", - "integrity": "sha512-byy+U7gp+FVwmyzKPYhW2h5l3crpmGsxl7X2s8y43IgxvG4g3QZ6CffDtsNQy1WsmZpQbO+ybo0AlW7TY6DcBQ==", + "version": "4.1.7", + "resolved": "https://registry.npmjs.org/object.assign/-/object.assign-4.1.7.tgz", + "integrity": "sha512-nK28WOo+QIjBkDduTINE4JkF/UJJKyf2EJxvJKfblDpyg0Q+pkOHNTL0Qwy6NP6FhE/EnzV73BxxqcJaXY9anw==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.5", + "call-bind": "^1.0.8", + "call-bound": "^1.0.3", "define-properties": "^1.2.1", - "has-symbols": "^1.0.3", + "es-object-atoms": "^1.0.0", + "has-symbols": "^1.1.0", "object-keys": "^1.1.1" }, "engines": { @@ -5374,13 +4729,14 @@ } }, "node_modules/object.values": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/object.values/-/object.values-1.2.0.tgz", - "integrity": "sha512-yBYjY9QX2hnRmZHAjG/f13MzmBzxzYgQhFrke06TTyKY5zSTEqkOeukBzIdVA3j3ulu8Qa3MbVFShV7T2RmGtQ==", + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/object.values/-/object.values-1.2.1.tgz", + "integrity": "sha512-gXah6aZrcUxjWg2zR2MwouP2eHlCBzdV4pygudehaKXSGW4v2AsRQUK+lwwXhii6KFZcunEnmSUoYp5CXibxtA==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.7", + "call-bind": "^1.0.8", + "call-bound": "^1.0.3", "define-properties": "^1.2.1", "es-object-atoms": "^1.0.0" }, @@ -5391,22 +4747,6 @@ "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/onetime": { - "version": "5.1.2", - "resolved": "https://registry.npmjs.org/onetime/-/onetime-5.1.2.tgz", - "integrity": "sha512-kbpaSSGJTWdAY5KPVeMOKXSrPtr8C8C7wodJbcsd51jRnmD+GZu8Y0VoU6Dm5Z4vWr0Ig/1NKuWRKf7j5aaYSg==", - "dev": true, - "license": "MIT", - "dependencies": { - "mimic-fn": "^2.1.0" - }, - "engines": { - "node": ">=6" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, "node_modules/optionator": { "version": "0.9.4", "resolved": "https://registry.npmjs.org/optionator/-/optionator-0.9.4.tgz", @@ -5425,38 +4765,22 @@ "node": ">= 0.8.0" } }, - "node_modules/ora": { - "version": "5.4.1", - "resolved": "https://registry.npmjs.org/ora/-/ora-5.4.1.tgz", - "integrity": "sha512-5b6Y85tPxZZ7QytO+BQzysW31HJku27cRIlkbAXaNx+BdcVi+LlRFmVXzeF6a7JCwJpyw5c4b+YSVImQIrBpuQ==", + "node_modules/own-keys": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/own-keys/-/own-keys-1.0.1.tgz", + "integrity": "sha512-qFOyK5PjiWZd+QQIh+1jhdb9LpxTF0qs7Pm8o5QHYZ0M3vKqSqzsZaEB6oWlxZ+q2sJBMI/Ktgd2N5ZwQoRHfg==", "dev": true, "license": "MIT", "dependencies": { - "bl": "^4.1.0", - "chalk": "^4.1.0", - "cli-cursor": "^3.1.0", - "cli-spinners": "^2.5.0", - "is-interactive": "^1.0.0", - "is-unicode-supported": "^0.1.0", - "log-symbols": "^4.1.0", - "strip-ansi": "^6.0.0", - "wcwidth": "^1.0.1" + "get-intrinsic": "^1.2.6", + "object-keys": "^1.1.1", + "safe-push-apply": "^1.0.0" }, "engines": { - "node": ">=10" + "node": ">= 0.4" }, "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/os-tmpdir": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/os-tmpdir/-/os-tmpdir-1.0.2.tgz", - "integrity": "sha512-D2FR03Vir7FIu45XBY20mTb+/ZSWB00sjU9jdQXt83gDrI4Ztz5Fs7/yy74g2N5SVQY4xY1qDr4rNddwYRVX0g==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=0.10.0" + "url": "https://github.com/sponsors/ljharb" } }, "node_modules/p-limit": { @@ -5512,14 +4836,13 @@ } }, "node_modules/parse-entities": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/parse-entities/-/parse-entities-4.0.1.tgz", - "integrity": "sha512-SWzvYcSJh4d/SGLIOQfZ/CoNv6BTlI6YEQ7Nj82oDVnRpwe/Z/F1EMx42x3JAOwGBlCjeCH0BRJQbQ/opHL17w==", + "version": "4.0.2", + "resolved": "https://registry.npmjs.org/parse-entities/-/parse-entities-4.0.2.tgz", + "integrity": "sha512-GG2AQYWoLgL877gQIKeRPGO1xF9+eG1ujIb5soS5gPvLQ1y2o8FL90w2QWNdf9I361Mpp7726c+lj3U0qK1uGw==", "dev": true, "license": "MIT", "dependencies": { "@types/unist": "^2.0.0", - "character-entities": "^2.0.0", "character-entities-legacy": "^3.0.0", "character-reference-invalid": "^2.0.0", "decode-named-character-reference": "^1.0.0", @@ -5552,58 +4875,12 @@ "url": "https://github.com/sponsors/sindresorhus" } }, - "node_modules/parse-json/node_modules/type-fest": { - "version": "3.13.1", - "resolved": "https://registry.npmjs.org/type-fest/-/type-fest-3.13.1.tgz", - "integrity": "sha512-tLq3bSNx+xSpwvAJnzrK0Ep5CLNWjvFTOp71URMaAEWBfRb9nnJiBoUe0tF8bI4ZFO3omgBR6NvnbzVUT3Ly4g==", - "dev": true, - "license": "(MIT OR CC0-1.0)", - "engines": { - "node": ">=14.16" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/parse5": { - "version": "7.2.0", - "resolved": "https://registry.npmjs.org/parse5/-/parse5-7.2.0.tgz", - "integrity": "sha512-ZkDsAOcxsUMZ4Lz5fVciOehNcJ+Gb8gTzcA4yl3wnc273BAybYWrQ+Ks/OjCjSEpjvQkDSeZbybK9qj2VHHdGA==", - "dev": true, - "license": "MIT", - "dependencies": { - "entities": "^4.5.0" - }, - "funding": { - "url": "https://github.com/inikulin/parse5?sponsor=1" - } - }, - "node_modules/parse5-htmlparser2-tree-adapter": { - "version": "7.1.0", - "resolved": "https://registry.npmjs.org/parse5-htmlparser2-tree-adapter/-/parse5-htmlparser2-tree-adapter-7.1.0.tgz", - "integrity": "sha512-ruw5xyKs6lrpo9x9rCZqZZnIUntICjQAd0Wsmp396Ul9lN/h+ifgVV1x1gZHi8euej6wTfpqX8j+BFQxF0NS/g==", - "dev": true, - "license": "MIT", - "dependencies": { - "domhandler": "^5.0.3", - "parse5": "^7.0.0" - }, - "funding": { - "url": "https://github.com/inikulin/parse5?sponsor=1" - } - }, - "node_modules/parse5-parser-stream": { - "version": "7.1.2", - "resolved": "https://registry.npmjs.org/parse5-parser-stream/-/parse5-parser-stream-7.1.2.tgz", - "integrity": "sha512-JyeQc9iwFLn5TbvvqACIF/VXG6abODeB3Fwmv/TGdLk2LfbWkaySGY72at4+Ty7EkPZj854u4CrICqNk2qIbow==", + "node_modules/parse-numeric-range": { + "version": "1.3.0", + "resolved": "https://registry.npmjs.org/parse-numeric-range/-/parse-numeric-range-1.3.0.tgz", + "integrity": "sha512-twN+njEipszzlMJd4ONUYgSfZPDxgHhT9Ahed5uTigpQn90FggW4SA/AIPq/6a149fTbE9qBEcSwE3FAEp6wQQ==", "dev": true, - "license": "MIT", - "dependencies": { - "parse5": "^7.0.0" - }, - "funding": { - "url": "https://github.com/inikulin/parse5?sponsor=1" - } + "license": "ISC" }, "node_modules/path-exists": { "version": "4.0.0", @@ -5657,13 +4934,13 @@ "license": "ISC" }, "node_modules/picomatch": { - "version": "2.3.1", - "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz", - "integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==", + "version": "4.0.2", + "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-4.0.2.tgz", + "integrity": "sha512-M7BAV6Rlcy5u+m6oPhAPFgJTzAioX/6B0DxyvDlo9l8+T3nLKbrczg2WLUyzd45L8RqfUMyGPzekbMvX2Ldkwg==", "dev": true, "license": "MIT", "engines": { - "node": ">=8.6" + "node": ">=12" }, "funding": { "url": "https://github.com/sponsors/jonschlinkert" @@ -5680,9 +4957,9 @@ } }, "node_modules/possible-typed-array-names": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/possible-typed-array-names/-/possible-typed-array-names-1.0.0.tgz", - "integrity": "sha512-d7Uw+eZoloe0EHDIYoe+bQ5WXnGMOpmiZFTuMWCwpjzzkL2nTjcKiAk4hh8TjnGye2TwWOk3UXucZ+3rbmBa8Q==", + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/possible-typed-array-names/-/possible-typed-array-names-1.1.0.tgz", + "integrity": "sha512-/+5VFTchJDoVj3bhoqi6UeymcD00DAwb1nJwamzPvHEszJ4FpF6SNNbUbOS8yI56qHzdV8eK0qEfOSiodkTdxg==", "dev": true, "license": "MIT", "engines": { @@ -5832,19 +5109,57 @@ "picomatch": "^2.2.1" }, "engines": { - "node": ">=8.10.0" + "node": ">=8.10.0" + } + }, + "node_modules/readdirp/node_modules/picomatch": { + "version": "2.3.1", + "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz", + "integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==", + "dev": true, + "license": "MIT", + "engines": { + "node": ">=8.6" + }, + "funding": { + "url": "https://github.com/sponsors/jonschlinkert" + } + }, + "node_modules/reflect.getprototypeof": { + "version": "1.0.10", + "resolved": "https://registry.npmjs.org/reflect.getprototypeof/-/reflect.getprototypeof-1.0.10.tgz", + "integrity": "sha512-00o4I+DVrefhv+nX0ulyi3biSHCPDe+yLv5o/p6d/UVlirijB8E16FtfwSAi4g3tcqrQ4lRAqQSoFEZJehYEcw==", + "dev": true, + "license": "MIT", + "dependencies": { + "call-bind": "^1.0.8", + "define-properties": "^1.2.1", + "es-abstract": "^1.23.9", + "es-errors": "^1.3.0", + "es-object-atoms": "^1.0.0", + "get-intrinsic": "^1.2.7", + "get-proto": "^1.0.1", + "which-builtin-type": "^1.2.1" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" } }, "node_modules/regexp.prototype.flags": { - "version": "1.5.3", - "resolved": "https://registry.npmjs.org/regexp.prototype.flags/-/regexp.prototype.flags-1.5.3.tgz", - "integrity": "sha512-vqlC04+RQoFalODCbCumG2xIOvapzVMHwsyIGM/SIE8fRhFFsXeH8/QQ+s0T0kDAhKc4k30s73/0ydkHQz6HlQ==", + "version": "1.5.4", + "resolved": "https://registry.npmjs.org/regexp.prototype.flags/-/regexp.prototype.flags-1.5.4.tgz", + "integrity": "sha512-dYqgNSZbDwkaJ2ceRd9ojCGjBq+mOm9LmtXnAnEGyHhN/5R7iDW2TRw3h+o/jCFxus3P2LfWIIiwowAjANm7IA==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.7", + "call-bind": "^1.0.8", "define-properties": "^1.2.1", "es-errors": "^1.3.0", + "get-proto": "^1.0.1", + "gopd": "^1.2.0", "set-function-name": "^2.0.2" }, "engines": { @@ -5871,6 +5186,39 @@ "url": "https://opencollective.com/unified" } }, + "node_modules/rehype-highlight": { + "version": "7.0.2", + "resolved": "https://registry.npmjs.org/rehype-highlight/-/rehype-highlight-7.0.2.tgz", + "integrity": "sha512-k158pK7wdC2qL3M5NcZROZ2tR/l7zOzjxXd5VGdcfIyoijjQqpHd3JKtYSBDpDZ38UI2WJWuFAtkMDxmx5kstA==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/hast": "^3.0.0", + "hast-util-to-text": "^4.0.0", + "lowlight": "^3.0.0", + "unist-util-visit": "^5.0.0", + "vfile": "^6.0.0" + }, + "funding": { + "type": "opencollective", + "url": "https://opencollective.com/unified" + } + }, + "node_modules/rehype-highlight-code-lines": { + "version": "1.1.3", + "resolved": "https://registry.npmjs.org/rehype-highlight-code-lines/-/rehype-highlight-code-lines-1.1.3.tgz", + "integrity": "sha512-Kq63wvBTkaQn5d5eqVJsqkpAW2fmqwbyGRervWtH32fTY6+cFqzVU5NTBZH/fe9PjjRUTyZfWinEDu7Ewvr+lw==", + "dev": true, + "license": "MIT", + "dependencies": { + "@types/hast": "^3.0.4", + "parse-numeric-range": "^1.3.0", + "unist-util-visit": "^5.0.0" + }, + "peerDependencies": { + "unified": "^11" + } + }, "node_modules/rehype-stringify": { "version": "10.0.1", "resolved": "https://registry.npmjs.org/rehype-stringify/-/rehype-stringify-10.0.1.tgz", @@ -5939,9 +5287,9 @@ } }, "node_modules/remark-gfm": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-gfm/-/remark-gfm-4.0.0.tgz", - "integrity": "sha512-U92vJgBPkbw4Zfu/IiW2oTZLSL3Zpv+uI7My2eq8JxKgqraFdU8YUGicEJCEgSbeaG+QDFqIcwwfMTOEelPxuA==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-gfm/-/remark-gfm-4.0.1.tgz", + "integrity": "sha512-1quofZ2RQ9EWdeN34S79+KExV1764+wCUGop5CPL1WGdD0ocPpu91lzPGbwWMECpEpd42kJGQwzRfyov9j4yNg==", "dev": true, "license": "MIT", "dependencies": { @@ -5999,9 +5347,9 @@ } }, "node_modules/remark-lint": { - "version": "10.0.0", - "resolved": "https://registry.npmjs.org/remark-lint/-/remark-lint-10.0.0.tgz", - "integrity": "sha512-E8yHHDOJ8b+qI0G49BRu24pe8t0fNNBWv8ENQJpCGNrVeTeyBIGEbaUe1yuF7OG8faA6PVpcN/pqWjzW9fcBWQ==", + "version": "10.0.1", + "resolved": "https://registry.npmjs.org/remark-lint/-/remark-lint-10.0.1.tgz", + "integrity": "sha512-1+PYGFziOg4pH7DDf1uMd4AR3YuO2EMnds/SdIWMPGT7CAfDRSnAmpxPsJD0Ds3IKpn97h3d5KPGf1WFOg6hXQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6015,9 +5363,9 @@ } }, "node_modules/remark-lint-blockquote-indentation": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-blockquote-indentation/-/remark-lint-blockquote-indentation-4.0.0.tgz", - "integrity": "sha512-hdUvn+KsJbBKpY9jLY01PmfpJ/WGhLu9GJMXQGU8ADXJc+F5DWSgKAr6GQ1IUKqvGYdEML/KZ61WomWFUuecVA==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-blockquote-indentation/-/remark-lint-blockquote-indentation-4.0.1.tgz", + "integrity": "sha512-7BhOsImFgTD7IIliu2tt+yJbx5gbMbXCOspc3VdYf/87iLJdWKqJoMy2V6DZG7kBjBlBsIZi38fDDngJttXt4w==", "dev": true, "license": "MIT", "dependencies": { @@ -6034,9 +5382,9 @@ } }, "node_modules/remark-lint-checkbox-character-style": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-checkbox-character-style/-/remark-lint-checkbox-character-style-5.0.0.tgz", - "integrity": "sha512-K0G/Nok59fb2q5KUxcemBVt+ymnhTkDVLJAatZ4PAh9At8y0DGctHdU27jWsuvO0Fs7Zy62Usk7IJE2VO89p1w==", + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-checkbox-character-style/-/remark-lint-checkbox-character-style-5.0.1.tgz", + "integrity": "sha512-6qilm7XQXOcTvjFEqqNY57Ki7md9rkSdpMIfIzVXdEnI4Npl2BnUff6ANrGRM7qTgJTrloaf8H0eQ91urcU6Og==", "dev": true, "license": "MIT", "dependencies": { @@ -6053,9 +5401,9 @@ } }, "node_modules/remark-lint-code-block-style": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-code-block-style/-/remark-lint-code-block-style-4.0.0.tgz", - "integrity": "sha512-LKBKMVruEO0tzDnnnqi1TfUcnwY6Mo7cVtZM4E4pKt3KMhtvgU2wD68/MxDOEJd0pmnLrEgIadv74bY0gWhZpg==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-code-block-style/-/remark-lint-code-block-style-4.0.1.tgz", + "integrity": "sha512-d4mHsEpv1yqXWl2dd+28tGRX0Lzk5qw7cfxAQVkOXPUONhsMFwXJEBeeqZokeG4lOKtkKdIJR7ezScDfWR0X4w==", "dev": true, "license": "MIT", "dependencies": { @@ -6072,9 +5420,9 @@ } }, "node_modules/remark-lint-definition-case": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-definition-case/-/remark-lint-definition-case-4.0.0.tgz", - "integrity": "sha512-XBmMmj8ii0KZUuJf7ZaVXDGp2+DWE02re9qn/6mV23rBpsDmpz7U1lQWRlwFQIE5q5bxIxP5pX7hDeTH0Egy9Q==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-definition-case/-/remark-lint-definition-case-4.0.1.tgz", + "integrity": "sha512-BItJMeXyEBKW/beM7gFLMt3flnyNoRDd8yNFq+7pIeFjO7KWGRxBWUaNgk/tFEPyQcGeCqrNS3nS0ic7qi7I2w==", "dev": true, "license": "MIT", "dependencies": { @@ -6089,9 +5437,9 @@ } }, "node_modules/remark-lint-definition-spacing": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-definition-spacing/-/remark-lint-definition-spacing-4.0.0.tgz", - "integrity": "sha512-t6nP8unz6z/DLBTWeOmDFHPFbX3E2PbNgt2fTazRbVnMC6z3o25hBzg5hI6DL0MPt2ZTRX++rJsGRjb+vgh/tQ==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-definition-spacing/-/remark-lint-definition-spacing-4.0.1.tgz", + "integrity": "sha512-ZjShKaBUGeHrZyIZWwOZOxX3guj/P7gRR5wbDADQctL4oK+ZLQfOvJFmAsF1nD4gNr0Ficjd0AuiWxQcc1qTMA==", "dev": true, "license": "MIT", "dependencies": { @@ -6108,9 +5456,9 @@ } }, "node_modules/remark-lint-emphasis-marker": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-emphasis-marker/-/remark-lint-emphasis-marker-4.0.0.tgz", - "integrity": "sha512-xIRiB4PFWUOyIslN/UOPL6Lh+J0VD4R11+jo+W4hpGMNsg58l+2SgtdbinlXzDeoBxmaaka9n/sYpJ7cJWEIPQ==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-emphasis-marker/-/remark-lint-emphasis-marker-4.0.1.tgz", + "integrity": "sha512-BF1WWsAxai3XoKk48sfiqT3L8m02AZLj3BnipWkHDRXuLfz6VwsHVaHWyNvvE0p6b2B3A5dSYbcfJu5RmPx4tQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6126,9 +5474,9 @@ } }, "node_modules/remark-lint-fenced-code-flag": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-fenced-code-flag/-/remark-lint-fenced-code-flag-4.0.0.tgz", - "integrity": "sha512-Zs0wJd4nRvBo/9NWQVfWg5Ykapbo0Zzw/SyZc3f0h73S1gTZZcfeU+bA5oDivlBdcUgLBsyHRE0QaoaVvN3/Wg==", + "version": "4.1.1", + "resolved": "https://registry.npmjs.org/remark-lint-fenced-code-flag/-/remark-lint-fenced-code-flag-4.1.1.tgz", + "integrity": "sha512-hKPqowc79jrJL47AfnqDThvE8Q249nHCleR5nxuf9ybriMqcAHYxragKzU5c4W1fNy20bTfFdZz/iAAQAk9kwg==", "dev": true, "license": "MIT", "dependencies": { @@ -6145,9 +5493,9 @@ } }, "node_modules/remark-lint-fenced-code-marker": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-fenced-code-marker/-/remark-lint-fenced-code-marker-4.0.0.tgz", - "integrity": "sha512-WFN88Rx78m4/HSbW3Kx2XAYbVfzYns4bJd9qpwDD90DA3nc59zciYd01xi6Bk3n9vSs5gIlmG7xkwxVHHJ8KCA==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-fenced-code-marker/-/remark-lint-fenced-code-marker-4.0.1.tgz", + "integrity": "sha512-uI91OcVPKjNxV+vpjDW9T64hkE0a/CRn3JhwdMxUAJYpVsKnA7PFPSFJOx/abNsVZHNSe7ZFGgGdaH/lqgSizA==", "dev": true, "license": "MIT", "dependencies": { @@ -6164,9 +5512,9 @@ } }, "node_modules/remark-lint-file-extension": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-file-extension/-/remark-lint-file-extension-3.0.0.tgz", - "integrity": "sha512-wrOKiGvcl/ftB7FkeX2/l13ALvhKXV77HGR8AXo86cVY2pD+K0WdOC52DV3ldgpUXpWzE9kcgF8bbkxwzKpFFg==", + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-file-extension/-/remark-lint-file-extension-3.0.1.tgz", + "integrity": "sha512-1Ca5Dgu9J/j1fb7nvzNXh2xy4ija03igiP5i4le64LfrlloGax4VWcG/M7uL+CpRTFVqEJMWw0iKDEZxYSgImg==", "dev": true, "license": "MIT", "dependencies": { @@ -6180,9 +5528,9 @@ } }, "node_modules/remark-lint-final-definition": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/remark-lint-final-definition/-/remark-lint-final-definition-4.0.1.tgz", - "integrity": "sha512-51T9oSdA7wuhjSdgGo0snO1BY39Igt9cJQi7XpgtgFsbfQk8zSSAUAc/rLabY6+YCTpcPs6qmwvLXZ4mPX6Qlg==", + "version": "4.0.2", + "resolved": "https://registry.npmjs.org/remark-lint-final-definition/-/remark-lint-final-definition-4.0.2.tgz", + "integrity": "sha512-fz3UAcFQef77Zb8rz4za2R6y7pdyJot22iGtFoNIKdtbcNa8IKKEVoY3NIfrsLfhrjwzcha1Sp3fFA9NF6lc4w==", "dev": true, "license": "MIT", "dependencies": { @@ -6201,9 +5549,9 @@ } }, "node_modules/remark-lint-final-newline": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-final-newline/-/remark-lint-final-newline-3.0.0.tgz", - "integrity": "sha512-NaPyn6FiOn3IV/6gIcwWfJmgraPT2IaVLjhakfPglZkKVfn/FrOfETyY8Bp+HLoSRI9967OH0yRDnK7/pPIWeQ==", + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-final-newline/-/remark-lint-final-newline-3.0.1.tgz", + "integrity": "sha512-q5diKHD6BMbzqWqgvYPOB8AJgLrMzEMBAprNXjcpKoZ/uCRqly+gxjco+qVUMtMWSd+P+KXZZEqoa7Y6QiOudw==", "dev": true, "license": "MIT", "dependencies": { @@ -6218,9 +5566,9 @@ } }, "node_modules/remark-lint-hard-break-spaces": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-hard-break-spaces/-/remark-lint-hard-break-spaces-4.0.0.tgz", - "integrity": "sha512-zCTq7/xfM0ZL3bMopXse9DH2nk38wE1LrxmYwnTrqASBLnEAJWE2U2//tRGVMEBfSAnNvmIo96twz6zkLWjbGA==", + "version": "4.1.1", + "resolved": "https://registry.npmjs.org/remark-lint-hard-break-spaces/-/remark-lint-hard-break-spaces-4.1.1.tgz", + "integrity": "sha512-AKDPDt39fvmr3yk38OKZEWJxxCOOUBE+96AsBfs+ExS5LW6oLa9041X5ahFDQHvHGzdoremEIaaElursaPEkNg==", "dev": true, "license": "MIT", "dependencies": { @@ -6235,9 +5583,9 @@ } }, "node_modules/remark-lint-heading-increment": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-heading-increment/-/remark-lint-heading-increment-4.0.0.tgz", - "integrity": "sha512-TARnsjXWzY/yLwxh/y4+KnDSXO3Koue8Crp55T8G9pjj3vw+XgTAG35zSpIIY9HmGiQ2a3R0SOj2pAxATpnckg==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-heading-increment/-/remark-lint-heading-increment-4.0.1.tgz", + "integrity": "sha512-uat7RTQn0hGlMv62p7yjLlg3tO3RljFbH6C+0M+5BNEF+s3NrA8jJgqW0UwLLNdCd3EABCKaWloHumT57ND7PQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6254,9 +5602,9 @@ } }, "node_modules/remark-lint-heading-style": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-heading-style/-/remark-lint-heading-style-4.0.0.tgz", - "integrity": "sha512-dQ6Jul5K0+aNUvrq4W7H0+osSoC9hsmwHZqBFq000+eMP/hWJqI8tuudw1rap8HHYuOsKLRbB5q+Fr7G+3Vw+Q==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-heading-style/-/remark-lint-heading-style-4.0.1.tgz", + "integrity": "sha512-+rUpJ/N2CGC5xPgZ18XgsCsUBtadgEhdTi0BJPrsFmHPzL22BUHajeg9im8Y7zphUcbi1qFiKuxZd2nzDgZSXQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6274,9 +5622,9 @@ } }, "node_modules/remark-lint-link-title-style": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-link-title-style/-/remark-lint-link-title-style-4.0.0.tgz", - "integrity": "sha512-cihTO5dkhjMj/evYIDAvRdQHD82OQeF4fNAq8FLb81HmFKo77VlSF6CK55H1bvlZogfJG58uN/5d1tSsOdcEbg==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-link-title-style/-/remark-lint-link-title-style-4.0.1.tgz", + "integrity": "sha512-MtmnYrhjhRXR0zeiyYf/7GBlUF5KAPypJb345KjyDluOhI4Wj4VAXvVQuov/MFc3y8p/1yVwv3QDYv6yue8/wQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6292,9 +5640,9 @@ } }, "node_modules/remark-lint-list-item-bullet-indent": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-list-item-bullet-indent/-/remark-lint-list-item-bullet-indent-5.0.0.tgz", - "integrity": "sha512-qq22QaxsDjfsL7aWGIPmP3P0N99CJBQQW1+iSrhYAMCDzqVlw6I3wPNAeR6s8mcoeHT8YlT6eQH3V8xJ0SlW6w==", + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-list-item-bullet-indent/-/remark-lint-list-item-bullet-indent-5.0.1.tgz", + "integrity": "sha512-LKuTxkw5aYChzZoF3BkfaBheSCHs0T8n8dPHLQEuOLo6iC5wy98iyryz0KZ61GD8stlZgQO2KdWSdnP6vr40Iw==", "dev": true, "license": "MIT", "dependencies": { @@ -6309,9 +5657,9 @@ } }, "node_modules/remark-lint-list-item-content-indent": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-list-item-content-indent/-/remark-lint-list-item-content-indent-4.0.0.tgz", - "integrity": "sha512-L4GZgWQQ54qWKbnDle3dbEOtnq+qdmZJ70lpM3yMFEMHs4xejqPKsIoiYeUtIV0rYHHCWS7IlLzcgYUK9vENQw==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-list-item-content-indent/-/remark-lint-list-item-content-indent-4.0.1.tgz", + "integrity": "sha512-KSopxxp64O6dLuTQ2sWaTqgjKWr1+AoB1QCTektMJ3mfHfn0QyZzC2CZbBU22KGzBhiYXv9cIxlJlxUtq2NqHg==", "dev": true, "license": "MIT", "dependencies": { @@ -6329,9 +5677,9 @@ } }, "node_modules/remark-lint-list-item-indent": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-list-item-indent/-/remark-lint-list-item-indent-4.0.0.tgz", - "integrity": "sha512-Yd6/g8CH9e4vlPAPNgl7F575uKhP+pTo/qwGkE61GOcgEVNJ/529hjumUhyQ4sOAX0YAPAjxvq6fJvb4AhVOOA==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-list-item-indent/-/remark-lint-list-item-indent-4.0.1.tgz", + "integrity": "sha512-gJd1Q+jOAeTgmGRsdMpnRh01DUrAm0O5PCQxE8ttv1QZOV015p/qJH+B4N6QSmcUuPokHLAh9USuq05C73qpiA==", "dev": true, "license": "MIT", "dependencies": { @@ -6348,9 +5696,9 @@ } }, "node_modules/remark-lint-list-item-spacing": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-list-item-spacing/-/remark-lint-list-item-spacing-5.0.0.tgz", - "integrity": "sha512-d6p+1tcwNE+Pp6Tu2DwiKlyC1zYY3f1igL6AlcBIH0RmROVEfZR4IDFH/LcVyTkzqh1lPMFAJXWK4bpScpcO3g==", + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-list-item-spacing/-/remark-lint-list-item-spacing-5.0.1.tgz", + "integrity": "sha512-AsxDL9U4qRmFGiz6lfsO833sJaHDlESjxM2rAvssPiXMZau3w/pZItaJyjowQBygDqGrj30sHvOfJzCHKbm1CA==", "dev": true, "license": "MIT", "dependencies": { @@ -6368,9 +5716,9 @@ } }, "node_modules/remark-lint-maximum-heading-length": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-maximum-heading-length/-/remark-lint-maximum-heading-length-4.0.0.tgz", - "integrity": "sha512-UCQxUd0zZyi6RUbpoK5KsxC50ppVqVk0hSgrSPot4wB6PHRgYMALU2fDkEcAjLDc/Y2TayG3IaZEKdqe+84Cwg==", + "version": "4.1.1", + "resolved": "https://registry.npmjs.org/remark-lint-maximum-heading-length/-/remark-lint-maximum-heading-length-4.1.1.tgz", + "integrity": "sha512-99yonukJ+e0uhx0zGH4uq6H9mhO7FA1ufmuToODH1N+X3ja61Grvlvvlq9UbP9+gbfbWgN97QGKPaTlE29FpaQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6387,9 +5735,9 @@ } }, "node_modules/remark-lint-maximum-line-length": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/remark-lint-maximum-line-length/-/remark-lint-maximum-line-length-4.0.1.tgz", - "integrity": "sha512-hQlh8UrRfhkO4FU7z7t1Bu5ethj1y2iBncO5AOWF38RAmlHaZdB2lQxNA8IvUZITGJYpT1aThdFTEf+58lv08Q==", + "version": "4.1.1", + "resolved": "https://registry.npmjs.org/remark-lint-maximum-line-length/-/remark-lint-maximum-line-length-4.1.1.tgz", + "integrity": "sha512-oIncZkI0oIXZk+1kJOMnE3WPbyMTUbds0q1E8WbCwtjN9pAZsQD2e+wK+xdi5VqOLPkvLER+yzbmi/A3Tp+XEg==", "dev": true, "license": "MIT", "dependencies": { @@ -6406,9 +5754,9 @@ } }, "node_modules/remark-lint-no-blockquote-without-marker": { - "version": "6.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-blockquote-without-marker/-/remark-lint-no-blockquote-without-marker-6.0.0.tgz", - "integrity": "sha512-fBhoTpkWcl5tG4FdwPdJIyb8XLrdr6MdLk1+K2BQ6Rom3rRsIYvuox4ohxOunNrXuth8xyw8kC6wDmODR44oFw==", + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-blockquote-without-marker/-/remark-lint-no-blockquote-without-marker-6.0.1.tgz", + "integrity": "sha512-b4IOkNcG7C16HYAdKUeAhO7qPt45m+v7SeYbVrqvbSFtlD3EUBL8fgHRgLK1mdujFXDP1VguOEMx+Txv8JOT4w==", "dev": true, "license": "MIT", "dependencies": { @@ -6428,9 +5776,9 @@ } }, "node_modules/remark-lint-no-consecutive-blank-lines": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-consecutive-blank-lines/-/remark-lint-no-consecutive-blank-lines-5.0.0.tgz", - "integrity": "sha512-HsDZbFlelBVO3mEJDXd9v4z0HLB8pqxWnsV+I4ILYFp5lKYf6NxJaLBWFtP1gAg1+95WxityGLkGtYqmicDjpg==", + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-consecutive-blank-lines/-/remark-lint-no-consecutive-blank-lines-5.0.1.tgz", + "integrity": "sha512-yLtYCrEBtGDao4ozmZruRzjMYAcBVFK69PoYjPfNwFO8pQ/LPt8KCq6oyg1ronNyRbDYEGqVdLIHcT/zL3LjPA==", "dev": true, "license": "MIT", "dependencies": { @@ -6449,9 +5797,9 @@ } }, "node_modules/remark-lint-no-duplicate-definitions": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-duplicate-definitions/-/remark-lint-no-duplicate-definitions-4.0.0.tgz", - "integrity": "sha512-21fcOACkCyhNsHkedKlpvqIywYx+5zGR507bW8e59gzdGhTbnBwQ9du4ACmN9jxPTfIBhUVMz0bWezkGrHE7Bg==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-duplicate-definitions/-/remark-lint-no-duplicate-definitions-4.0.1.tgz", + "integrity": "sha512-Ek+A/xDkv5Nn+BXCFmf+uOrFSajCHj6CjhsHjtROgVUeEPj726yYekDBoDRA0Y3+z+U30AsJoHgf/9Jj1IFSug==", "dev": true, "license": "MIT", "dependencies": { @@ -6468,9 +5816,9 @@ } }, "node_modules/remark-lint-no-duplicate-headings": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-duplicate-headings/-/remark-lint-no-duplicate-headings-4.0.0.tgz", - "integrity": "sha512-FgBU/JCdR5MitHM+hnOcgBGO5ZCNV8epzuHIglFlJeb8ow23YhhNgmGvyk7RGrZrYuU5R9uQq23N4dF0g9atCA==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-duplicate-headings/-/remark-lint-no-duplicate-headings-4.0.1.tgz", + "integrity": "sha512-6lggqnpIe5FepikjYF2me3ovKV4oD/rAz8WmwVbLR2cLkce1iH+PB7jyxk/A2gQQqrDcIlRMA5Ct2Yj56cEwhQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6488,9 +5836,9 @@ } }, "node_modules/remark-lint-no-emphasis-as-heading": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-emphasis-as-heading/-/remark-lint-no-emphasis-as-heading-4.0.0.tgz", - "integrity": "sha512-JViGYbuO/xzZThK+qVTNjtLM0v1xMTWFTWt2OJzAkDaGS6T9ZB5ZtRVSBFEMG0SF3dvpJwxe+3ABTsuPBdlYsA==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-emphasis-as-heading/-/remark-lint-no-emphasis-as-heading-4.0.1.tgz", + "integrity": "sha512-zzI/C330qdKO9FB3h6IUtOG36FSrS5nfJ7qxp0atXGYtHyg+Ag7dPC/0FzchOVsxofQm0QTstVoIARt/9TiN5g==", "dev": true, "license": "MIT", "dependencies": { @@ -6505,9 +5853,9 @@ } }, "node_modules/remark-lint-no-file-name-articles": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-articles/-/remark-lint-no-file-name-articles-3.0.0.tgz", - "integrity": "sha512-il4IseupahbV2TVfFjfDVL/EQw7jBWVlMVsv4K2cgl5uPIjiCjFGQypqKnWl6pZDN0oNOs/DE8gBdyuDjldJaA==", + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-articles/-/remark-lint-no-file-name-articles-3.0.1.tgz", + "integrity": "sha512-h31ZDDJV2T6g9WLBrXg1CJ1m8M170O/tlDPAEPGCa/rxwKvMcfum4yicaot0ZKbUZ1uEPjVSUPDeo3sU0zciCQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6520,9 +5868,9 @@ } }, "node_modules/remark-lint-no-file-name-consecutive-dashes": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-consecutive-dashes/-/remark-lint-no-file-name-consecutive-dashes-3.0.0.tgz", - "integrity": "sha512-3vSI1LOQlu8NSCpWLsKELa8dS9HU+YVZE0U43/DNkdEcnZmlJLpTHQjBTMZUHQipRgoOO+TOSyXFyN/H+2lbuQ==", + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-consecutive-dashes/-/remark-lint-no-file-name-consecutive-dashes-3.0.1.tgz", + "integrity": "sha512-qGJRZ81sowEjv1dBodbHZ29pDZbrFpxiQQ6gBvkkHkkoYPekdnr8iUxmV38HcqH8+JNW1O4ELr+m71AA9/34Mw==", "dev": true, "license": "MIT", "dependencies": { @@ -6535,9 +5883,9 @@ } }, "node_modules/remark-lint-no-file-name-irregular-characters": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-irregular-characters/-/remark-lint-no-file-name-irregular-characters-3.0.0.tgz", - "integrity": "sha512-DhGreliHNU7lLTARQujsaLAn8fUPY0V+H0LSmOUuowBZPtIRWeNdQhunSp96RvsuYdqAdERXe0WuH58i3pRqrg==", + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-irregular-characters/-/remark-lint-no-file-name-irregular-characters-3.0.1.tgz", + "integrity": "sha512-kNm16eDnPqbN05W0RLIedHi40YzHf1esPHbNKv12AljKWptdCTS72uGjAbqUSZ48dRoKtJzL0HJ0OAqXIWUyxA==", "dev": true, "license": "MIT", "dependencies": { @@ -6550,9 +5898,9 @@ } }, "node_modules/remark-lint-no-file-name-mixed-case": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-mixed-case/-/remark-lint-no-file-name-mixed-case-3.0.0.tgz", - "integrity": "sha512-MXXNHdGB6P46itkf8gRP0kxQL85KfAj9YOOBqNtGsgI/8J5rsyM/rz1Ac20Xe+5C5oGi71+7EO/TExKu/+7dfw==", + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-mixed-case/-/remark-lint-no-file-name-mixed-case-3.0.1.tgz", + "integrity": "sha512-cXVY0gM6DIHHK+mUhQVZ/WLh4cNfzEDpM54LNJBnflR9n9r6eNLR3JlWFRviTL4xRrQ5FXisBSlBa87BquiFVA==", "dev": true, "license": "MIT", "dependencies": { @@ -6565,9 +5913,9 @@ } }, "node_modules/remark-lint-no-file-name-outer-dashes": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-outer-dashes/-/remark-lint-no-file-name-outer-dashes-3.0.0.tgz", - "integrity": "sha512-3kgamCp39mdlCtqF/+JLwwS4VpSj5wvVwRythUfrpW7993I9kF67dBsaU545aEzWSK+UJZqjb40i0m2VfnBRfQ==", + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-file-name-outer-dashes/-/remark-lint-no-file-name-outer-dashes-3.0.1.tgz", + "integrity": "sha512-QIMrBPZKZ6BwQRPM65HhEHcJv6+wZnZ4z2ikvx2ht40cSmIN7ZTL7wKKJlnpF+4Ioi9XUj+cRHWqEhwJ9LCQIw==", "dev": true, "license": "MIT", "dependencies": { @@ -6580,9 +5928,9 @@ } }, "node_modules/remark-lint-no-heading-content-indent": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-heading-content-indent/-/remark-lint-no-heading-content-indent-5.0.0.tgz", - "integrity": "sha512-psYSlD2BjcVkgpeXOLwPcYFBrbtJWp8E8JX1J4vSfoHPeY6aIxgYxXkf57cjGTApfRL8xawBmMDiF1FgQvpZYg==", + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-heading-content-indent/-/remark-lint-no-heading-content-indent-5.0.1.tgz", + "integrity": "sha512-YIWktnZo7M9aw7PGnHdshvetSH3Y0qW+Fm143R66zsk5lLzn1XA5NEd/MtDzP8tSxxV+gcv+bDd5St1QUI4oSQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6599,9 +5947,9 @@ } }, "node_modules/remark-lint-no-heading-punctuation": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-heading-punctuation/-/remark-lint-no-heading-punctuation-4.0.0.tgz", - "integrity": "sha512-7V23C3Q4yX9zEOLZdbv6o8wVxxeWB/F+h9by55zPyk2AwbqF2t2xevnAmN3XFmKZABDTqLwjQxtK6bCVv/S1PQ==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-heading-punctuation/-/remark-lint-no-heading-punctuation-4.0.1.tgz", + "integrity": "sha512-lpSVFEHPDKGWi8YPeO51xmLNVON5A2cGz0Y8VRkW0f2l6LvEkPTMjQAvA84AQu/10TrxTbIzU/tQlRLpG96QUA==", "dev": true, "license": "MIT", "dependencies": { @@ -6617,9 +5965,9 @@ } }, "node_modules/remark-lint-no-literal-urls": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-literal-urls/-/remark-lint-no-literal-urls-4.0.0.tgz", - "integrity": "sha512-rl/3Ai4Ax9IH/fRpOJZuXk1HgYX6oFTauhmBOilpqbq/YT2kN3FuXaneXdRfKv1bgMdHaLKxHWxGj/mDyA2n8w==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-literal-urls/-/remark-lint-no-literal-urls-4.0.1.tgz", + "integrity": "sha512-RhTANFkFFXE6bM+WxWcPo2TTPEfkWG3lJZU50ycW7tJJmxUzDNzRed/z80EVJIdGwFa0NntVooLUJp3xrogalQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6636,9 +5984,9 @@ } }, "node_modules/remark-lint-no-multiple-toplevel-headings": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-multiple-toplevel-headings/-/remark-lint-no-multiple-toplevel-headings-4.0.0.tgz", - "integrity": "sha512-JW11iYxza7asDdhQuKfr8SH1u4NBOCQ4U7Ru0HrKCPcT4y/AB1C1il5uMQzbcervgYPBq69xzyQ24+AJeL0t3A==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-multiple-toplevel-headings/-/remark-lint-no-multiple-toplevel-headings-4.0.1.tgz", + "integrity": "sha512-8sepobIOu3PlDOuMH7jtri+LH4tFNVQU+aqKSkrlNRdp831fYz9S+jA2crTVqWqxVbTwiF96uJWePv8/9qmHnA==", "dev": true, "license": "MIT", "dependencies": { @@ -6655,9 +6003,9 @@ } }, "node_modules/remark-lint-no-shell-dollars": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-shell-dollars/-/remark-lint-no-shell-dollars-4.0.0.tgz", - "integrity": "sha512-ye2h8FzjsgqqQV0HHN2g9N4FqI3eD9Gpgu7tU5ADIJyQ3mUJdwBoFn7IlGnpmumR1fb/l6u/AhRavIZxXYqG+Q==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-shell-dollars/-/remark-lint-no-shell-dollars-4.0.1.tgz", + "integrity": "sha512-UPE1DNCIkLtnS3YFD065Gkq5lQqfndBDpX8Ct/Zjn7M0/hzCyf9B6tpwCU0I20m9jzhS/CSY6mxYnAiEg+KkFA==", "dev": true, "license": "MIT", "dependencies": { @@ -6673,9 +6021,9 @@ } }, "node_modules/remark-lint-no-shortcut-reference-image": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-shortcut-reference-image/-/remark-lint-no-shortcut-reference-image-4.0.0.tgz", - "integrity": "sha512-YEiCpW5F/8/LZyxlOuVK2L/n0NJ1AB0AJK7oP39OVyEk3Xl7w+JQi6nZ3KiH6REh+PWGqKn6M0KEPL9cT/iAOw==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-shortcut-reference-image/-/remark-lint-no-shortcut-reference-image-4.0.1.tgz", + "integrity": "sha512-hQhJ3Dr8ZWRdj7qm6+9vcPpqtGchhENA2UHOmcTraLf6dN1cFATCgY/HbTbRIN6NkG/EEClTgRC1QCokWR2Mmw==", "dev": true, "license": "MIT", "dependencies": { @@ -6689,9 +6037,9 @@ } }, "node_modules/remark-lint-no-shortcut-reference-link": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-shortcut-reference-link/-/remark-lint-no-shortcut-reference-link-4.0.0.tgz", - "integrity": "sha512-6jka2Zz3I6G2MvDcKrwADYhTOxHMFMK854u1cfBEIH5/XnCCXROtoqiiDtbZw+NJqbmwsBKvGL4t2gnmEJUmgg==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-shortcut-reference-link/-/remark-lint-no-shortcut-reference-link-4.0.1.tgz", + "integrity": "sha512-YxciuUZc90QaJYhayGO80lS3zxEOBgwwLW1MKYB7AfUdkrLcLVlS+DFloiq0MZ7EDVXuuGUEnIzyjyLSbI5BUA==", "dev": true, "license": "MIT", "dependencies": { @@ -6705,9 +6053,9 @@ } }, "node_modules/remark-lint-no-table-indentation": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-table-indentation/-/remark-lint-no-table-indentation-5.0.0.tgz", - "integrity": "sha512-MaLmnzgirpnRiRjWwrsyOX0RmP2eG4YAv169MtsxTVa6O3CpUDwTuTzivudE9L0kVvTlyF9DXEmdyjm85LDyVA==", + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-table-indentation/-/remark-lint-no-table-indentation-5.0.1.tgz", + "integrity": "sha512-LHw9MGsuilM+3HkbRFZmdSE4T+sziaQzULH5ImYkLH2MLF8GKnAm2mgtveLZcW01wqFV2oEbpF1Y/s/QloXT7w==", "dev": true, "license": "MIT", "dependencies": { @@ -6726,9 +6074,9 @@ } }, "node_modules/remark-lint-no-undefined-references": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-undefined-references/-/remark-lint-no-undefined-references-5.0.0.tgz", - "integrity": "sha512-O0q8bHpRHK1T85oqO+uep4BkvQnZZp3y+wahDeeLLq9dCJfF56sq6Tt5OOTt1BAOZlpobS3OPQHUiJWYP6hX1w==", + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-undefined-references/-/remark-lint-no-undefined-references-5.0.1.tgz", + "integrity": "sha512-j3qOk+jry1NPNbUmydGJpfbo1LeuZkvXOwr8ocxh1ymDzHf2GMCiToAiicDNaOuG85RkiIzLvnnCV5I7Mo5q8w==", "dev": true, "license": "MIT", "dependencies": { @@ -6747,9 +6095,9 @@ } }, "node_modules/remark-lint-no-unused-definitions": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-no-unused-definitions/-/remark-lint-no-unused-definitions-4.0.0.tgz", - "integrity": "sha512-YCZ6k575NCTx7mnN+9ls0G6YgMsZHi0LYQqfLW8MNVHBtbpTBvfmk8I39bmsvuKWeBD98weZoXSDqIiIGg+Q/g==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-no-unused-definitions/-/remark-lint-no-unused-definitions-4.0.1.tgz", + "integrity": "sha512-AdMbaCeMpj32HvDUuyI+bQyu/405Nby/rgFW8XDpI7U7ufPhHl+jj9J4NgeW7Z8DrODGr0iFgPNt6JtNLskFdA==", "dev": true, "license": "MIT", "dependencies": { @@ -6764,9 +6112,9 @@ } }, "node_modules/remark-lint-ordered-list-marker-style": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-ordered-list-marker-style/-/remark-lint-ordered-list-marker-style-4.0.0.tgz", - "integrity": "sha512-xZ7Xppy5fzACH4b9h1b4lTzVtNY2AlUkNTfl1Oe6cIKN8tk3juFxN0wL2RpktPtSZ7iRIabzFmg6l8WPhlASJA==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-ordered-list-marker-style/-/remark-lint-ordered-list-marker-style-4.0.1.tgz", + "integrity": "sha512-vZTAbstcBPbGwJacwldGzdGmKwy5/4r29SZ9nQkME4alEl5B1ReSBlYa8t7QnTSW7+tqvA9Sg71RPadgAKWa4w==", "dev": true, "license": "MIT", "dependencies": { @@ -6784,9 +6132,9 @@ } }, "node_modules/remark-lint-ordered-list-marker-value": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-ordered-list-marker-value/-/remark-lint-ordered-list-marker-value-4.0.0.tgz", - "integrity": "sha512-7UjNU2Nv9LGEONTU9GPmTVoNoGKD5aL1X2xHzMbSJiTc50bfcazYqZawO+qj1pQ04WPhto1qHnl0HRB5wwSVwA==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-ordered-list-marker-value/-/remark-lint-ordered-list-marker-value-4.0.1.tgz", + "integrity": "sha512-HQb1MrArvApREC1/I6bkiFlZVDjngsuII29n8E8StnAaHOMN3hVYy6wJ9Uk+O3+X9O8v7fDsZPqFUHSfJhERXQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6805,9 +6153,9 @@ } }, "node_modules/remark-lint-rule-style": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-rule-style/-/remark-lint-rule-style-4.0.0.tgz", - "integrity": "sha512-Kt7IHMB5IbLgRFKaFUmB895sV3PTD0MBgN9CvXKxr1wHFF43S6tabjFIBSoQqyJRlhH0S3rK6Lvopofa009gLg==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-rule-style/-/remark-lint-rule-style-4.0.1.tgz", + "integrity": "sha512-gl1Ft13oTS3dJUCsWZzxD/5dAwI1HON67KU7uNfODD5gXJ8Y11deOWbun190ma7XbYdD7P0l8VT2HeRtEQzrWg==", "dev": true, "license": "MIT", "dependencies": { @@ -6824,9 +6172,9 @@ } }, "node_modules/remark-lint-strong-marker": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-strong-marker/-/remark-lint-strong-marker-4.0.0.tgz", - "integrity": "sha512-YcvuzakYhQWdCH+1E30sUY+wyvq+PNa77NZAMAYO/cS/pZczFB+q4Ccttw4Q+No/chX8oMfe0GYtm8dDWLei/g==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-strong-marker/-/remark-lint-strong-marker-4.0.1.tgz", + "integrity": "sha512-KaGtj/OWEP4eoafevnlp3NsEVwC7yGEjBJ6uFMzfjNoXyjATdfZ2euB/AfKVt/A/FdZeeMeVoAUFH4DL+hScLQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6842,9 +6190,9 @@ } }, "node_modules/remark-lint-table-cell-padding": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-table-cell-padding/-/remark-lint-table-cell-padding-5.0.0.tgz", - "integrity": "sha512-LNyiHDQZBIOqcQGG1tYsZHW7g0v8OyRmRgDrD5WEsMaAYfM6EiECUokN/Q4py9h4oM/2KUSrdZbtfuZmy87/kA==", + "version": "5.1.1", + "resolved": "https://registry.npmjs.org/remark-lint-table-cell-padding/-/remark-lint-table-cell-padding-5.1.1.tgz", + "integrity": "sha512-6fgVA1iINBoAJaZMOnSsxrF9Qj9+hmCqrsrqZqgJJETjT1ODGH64iAN1/6vHR7dIwmy73d6ysB2WrGyKhVlK3A==", "dev": true, "license": "MIT", "dependencies": { @@ -6871,9 +6219,9 @@ "license": "MIT" }, "node_modules/remark-lint-table-pipe-alignment": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-table-pipe-alignment/-/remark-lint-table-pipe-alignment-4.0.0.tgz", - "integrity": "sha512-nx+xpEIWQRLOcq9hIbUIvhSE1NYRmDJmCY3cMoHJ1sIW7dRXMHyWfpWTgu7mpREKwSQdE0q4qnzk8McQQSkIcg==", + "version": "4.1.1", + "resolved": "https://registry.npmjs.org/remark-lint-table-pipe-alignment/-/remark-lint-table-pipe-alignment-4.1.1.tgz", + "integrity": "sha512-9VxivIJaDonrd/Jgkim1oYQ5MIqhWmyJggr2AqtiizwqxT4epRsWmLOz+/sk7PtTGoT/MtwndhlbM3lxuVXFow==", "dev": true, "license": "MIT", "dependencies": { @@ -6899,9 +6247,9 @@ "license": "MIT" }, "node_modules/remark-lint-table-pipes": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-table-pipes/-/remark-lint-table-pipes-5.0.0.tgz", - "integrity": "sha512-e7jzAScDrt5+eMomh099TZJBN2K9ldDxBu9iYhNu5C0YsdAvnckJkgilsuClxFpmx4LCVYaX0EGbt/hQ3LB3xg==", + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-table-pipes/-/remark-lint-table-pipes-5.0.1.tgz", + "integrity": "sha512-oOkRC0WRRDwvodfffGafoBFBTGwy9udQgKtxN53apmZpOmaUAxTi833ite0jMo078+LehNftO5bxrElZ9EQUlQ==", "dev": true, "license": "MIT", "dependencies": { @@ -6925,9 +6273,9 @@ "license": "MIT" }, "node_modules/remark-lint-unordered-list-marker-style": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/remark-lint-unordered-list-marker-style/-/remark-lint-unordered-list-marker-style-4.0.0.tgz", - "integrity": "sha512-XlP4Wr4KJNovyWVv0H5axfUlF23iE9Kt2SxaVq4+ieum5YcMmKE6KsL+aqt3kiJb60SH1u6a0bxKFvdM/9riOA==", + "version": "4.0.1", + "resolved": "https://registry.npmjs.org/remark-lint-unordered-list-marker-style/-/remark-lint-unordered-list-marker-style-4.0.1.tgz", + "integrity": "sha512-HMrVQC0Qbr8ktSy+1lJGRGU10qecL3T14L6s/THEQXR5Tk0wcsLLG0auNvB4r2+H+ClhVO/Vnm1TEosh1OCsfw==", "dev": true, "license": "MIT", "dependencies": { @@ -6978,9 +6326,9 @@ } }, "node_modules/remark-preset-lint-consistent": { - "version": "6.0.0", - "resolved": "https://registry.npmjs.org/remark-preset-lint-consistent/-/remark-preset-lint-consistent-6.0.0.tgz", - "integrity": "sha512-W3fwxajdietwjnFyTH5x2le63hxWGVOXxIs7KjRqU+5wkkN6ZQyuwPeeomblmS9wQr50fkidhXNHNDyCXtqgxQ==", + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/remark-preset-lint-consistent/-/remark-preset-lint-consistent-6.0.1.tgz", + "integrity": "sha512-SOLdA36UOU1hiGFm6HAqN9+DORGJPVWxU/EvPVkknTr9V4ULhlzHEJ8OVRMVX3jqoy4lrwb4IqiboVz0YLA7+Q==", "dev": true, "license": "MIT", "dependencies": { @@ -7006,9 +6354,9 @@ } }, "node_modules/remark-preset-lint-markdown-style-guide": { - "version": "6.0.0", - "resolved": "https://registry.npmjs.org/remark-preset-lint-markdown-style-guide/-/remark-preset-lint-markdown-style-guide-6.0.0.tgz", - "integrity": "sha512-izsfNTHeqrRP64VWV6OdJnSUDwKFSthMKiiDcu14ODpPV0t7YiotCQWzgc7L4eW9Ctcp4aB4nHNLSuDmwhEWrQ==", + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/remark-preset-lint-markdown-style-guide/-/remark-preset-lint-markdown-style-guide-6.0.1.tgz", + "integrity": "sha512-hVCRMC8PZlI9hnXkZdrvg4n4j1aD//xHWj26Q7iFAbDB3JKtW1Ne72P7QNVyppmdrR6Gj84zhG3qphOLo8/i8A==", "dev": true, "license": "MIT", "dependencies": { @@ -7063,9 +6411,9 @@ } }, "node_modules/remark-preset-lint-recommended": { - "version": "7.0.0", - "resolved": "https://registry.npmjs.org/remark-preset-lint-recommended/-/remark-preset-lint-recommended-7.0.0.tgz", - "integrity": "sha512-A9aPDL78OO12xG2a83DVd+M2QzdBMjn545fbXj40BFJdpt9t//MADkPAwRfpMCBkKi+iECPUTFCb3Jm8SsFG2w==", + "version": "7.0.1", + "resolved": "https://registry.npmjs.org/remark-preset-lint-recommended/-/remark-preset-lint-recommended-7.0.1.tgz", + "integrity": "sha512-j1CY5u48PtZl872BQ40uWSQMT3R4gXKp0FUgevMu5gW7hFMtvaCiDq+BfhzeR8XKKiW9nIMZGfIMZHostz5X4g==", "dev": true, "license": "MIT", "dependencies": { @@ -7090,201 +6438,34 @@ "url": "https://opencollective.com/unified" } }, - "node_modules/remark-rehype": { - "version": "11.1.1", - "resolved": "https://registry.npmjs.org/remark-rehype/-/remark-rehype-11.1.1.tgz", - "integrity": "sha512-g/osARvjkBXb6Wo0XvAeXQohVta8i84ACbenPpoSsxTOQH/Ae0/RGP4WZgnMH5pMLpsj4FG7OHmcIcXxpza8eQ==", - "dev": true, - "license": "MIT", - "dependencies": { - "@types/hast": "^3.0.0", - "@types/mdast": "^4.0.0", - "mdast-util-to-hast": "^13.0.0", - "unified": "^11.0.0", - "vfile": "^6.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/remark-stringify": { - "version": "11.0.0", - "resolved": "https://registry.npmjs.org/remark-stringify/-/remark-stringify-11.0.0.tgz", - "integrity": "sha512-1OSmLd3awB/t8qdoEOMazZkNsfVTeY4fTsgzcQFdXNq8ToTN4ZGwrMnlda4K6smTFKD+GRV6O48i6Z4iKgPPpw==", - "dev": true, - "license": "MIT", - "dependencies": { - "@types/mdast": "^4.0.0", - "mdast-util-to-markdown": "^2.0.0", - "unified": "^11.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/remark-torchlight": { - "version": "0.0.5", - "resolved": "https://registry.npmjs.org/remark-torchlight/-/remark-torchlight-0.0.5.tgz", - "integrity": "sha512-aFnnUfbIGYFYr1HQDT8AVHBVsRRswLBdOM4ht9YB8e+gyV9UKN64b9i7xwRqWu78bzXTmxhqcQxnIaVNQO4iWA==", - "dev": true, - "license": "MIT", - "dependencies": { - "@torchlight-api/torchlight-cli": "^0.1.7", - "hast-util-from-parse5": "^7.1.0", - "parse5": "^6.0.1", - "unist-util-map": "^3.0.0" - } - }, - "node_modules/remark-torchlight/node_modules/@types/hast": { - "version": "2.3.10", - "resolved": "https://registry.npmjs.org/@types/hast/-/hast-2.3.10.tgz", - "integrity": "sha512-McWspRw8xx8J9HurkVBfYj0xKoE25tOFlHGdx4MJ5xORQrMGZNqJhVQWaIbm6Oyla5kYOXtDiopzKRJzEOkwJw==", - "dev": true, - "license": "MIT", - "dependencies": { - "@types/unist": "^2" - } - }, - "node_modules/remark-torchlight/node_modules/hast-util-from-parse5": { - "version": "7.1.2", - "resolved": "https://registry.npmjs.org/hast-util-from-parse5/-/hast-util-from-parse5-7.1.2.tgz", - "integrity": "sha512-Nz7FfPBuljzsN3tCQ4kCBKqdNhQE2l0Tn+X1ubgKBPRoiDIu1mL08Cfw4k7q71+Duyaw7DXDN+VTAp4Vh3oCOw==", - "dev": true, - "license": "MIT", - "dependencies": { - "@types/hast": "^2.0.0", - "@types/unist": "^2.0.0", - "hastscript": "^7.0.0", - "property-information": "^6.0.0", - "vfile": "^5.0.0", - "vfile-location": "^4.0.0", - "web-namespaces": "^2.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/remark-torchlight/node_modules/hast-util-parse-selector": { - "version": "3.1.1", - "resolved": "https://registry.npmjs.org/hast-util-parse-selector/-/hast-util-parse-selector-3.1.1.tgz", - "integrity": "sha512-jdlwBjEexy1oGz0aJ2f4GKMaVKkA9jwjr4MjAAI22E5fM/TXVZHuS5OpONtdeIkRKqAaryQ2E9xNQxijoThSZA==", - "dev": true, - "license": "MIT", - "dependencies": { - "@types/hast": "^2.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/remark-torchlight/node_modules/hastscript": { - "version": "7.2.0", - "resolved": "https://registry.npmjs.org/hastscript/-/hastscript-7.2.0.tgz", - "integrity": "sha512-TtYPq24IldU8iKoJQqvZOuhi5CyCQRAbvDOX0x1eW6rsHSxa/1i2CCiptNTotGHJ3VoHRGmqiv6/D3q113ikkw==", - "dev": true, - "license": "MIT", - "dependencies": { - "@types/hast": "^2.0.0", - "comma-separated-tokens": "^2.0.0", - "hast-util-parse-selector": "^3.0.0", - "property-information": "^6.0.0", - "space-separated-tokens": "^2.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/remark-torchlight/node_modules/is-buffer": { - "version": "2.0.5", - "resolved": "https://registry.npmjs.org/is-buffer/-/is-buffer-2.0.5.tgz", - "integrity": "sha512-i2R6zNFDwgEHJyQUtJEk0XFi1i0dPFn/oqjK3/vPCcDeJvW5NQ83V8QbicfF1SupOaB0h8ntgBC2YiE7dfyctQ==", - "dev": true, - "funding": [ - { - "type": "github", - "url": "https://github.com/sponsors/feross" - }, - { - "type": "patreon", - "url": "https://www.patreon.com/feross" - }, - { - "type": "consulting", - "url": "https://feross.org/support" - } - ], - "license": "MIT", - "engines": { - "node": ">=4" - } - }, - "node_modules/remark-torchlight/node_modules/parse5": { - "version": "6.0.1", - "resolved": "https://registry.npmjs.org/parse5/-/parse5-6.0.1.tgz", - "integrity": "sha512-Ofn/CTFzRGTTxwpNEs9PP93gXShHcTq255nzRYSKe8AkVpZY7e1fpmTfOyoIvjP5HG7Z2ZM7VS9PPhQGW2pOpw==", - "dev": true, - "license": "MIT" - }, - "node_modules/remark-torchlight/node_modules/unist-util-stringify-position": { - "version": "3.0.3", - "resolved": "https://registry.npmjs.org/unist-util-stringify-position/-/unist-util-stringify-position-3.0.3.tgz", - "integrity": "sha512-k5GzIBZ/QatR8N5X2y+drfpWG8IDBzdnVj6OInRNWm1oXrzydiaAT2OQiA8DPRRZyAKb9b6I2a6PxYklZD0gKg==", - "dev": true, - "license": "MIT", - "dependencies": { - "@types/unist": "^2.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/remark-torchlight/node_modules/vfile": { - "version": "5.3.7", - "resolved": "https://registry.npmjs.org/vfile/-/vfile-5.3.7.tgz", - "integrity": "sha512-r7qlzkgErKjobAmyNIkkSpizsFPYiUPuJb5pNW1RB4JcYVZhs4lIbVqk8XPk033CV/1z8ss5pkax8SuhGpcG8g==", - "dev": true, - "license": "MIT", - "dependencies": { - "@types/unist": "^2.0.0", - "is-buffer": "^2.0.0", - "unist-util-stringify-position": "^3.0.0", - "vfile-message": "^3.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/remark-torchlight/node_modules/vfile-location": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/vfile-location/-/vfile-location-4.1.0.tgz", - "integrity": "sha512-YF23YMyASIIJXpktBa4vIGLJ5Gs88UB/XePgqPmTa7cDA+JeO3yclbpheQYCHjVHBn/yePzrXuygIL+xbvRYHw==", + "node_modules/remark-rehype": { + "version": "11.1.1", + "resolved": "https://registry.npmjs.org/remark-rehype/-/remark-rehype-11.1.1.tgz", + "integrity": "sha512-g/osARvjkBXb6Wo0XvAeXQohVta8i84ACbenPpoSsxTOQH/Ae0/RGP4WZgnMH5pMLpsj4FG7OHmcIcXxpza8eQ==", "dev": true, "license": "MIT", "dependencies": { - "@types/unist": "^2.0.0", - "vfile": "^5.0.0" + "@types/hast": "^3.0.0", + "@types/mdast": "^4.0.0", + "mdast-util-to-hast": "^13.0.0", + "unified": "^11.0.0", + "vfile": "^6.0.0" }, "funding": { "type": "opencollective", "url": "https://opencollective.com/unified" } }, - "node_modules/remark-torchlight/node_modules/vfile-message": { - "version": "3.1.4", - "resolved": "https://registry.npmjs.org/vfile-message/-/vfile-message-3.1.4.tgz", - "integrity": "sha512-fa0Z6P8HUrQN4BZaX05SIVXic+7kE3b05PWAtPuYP9QLHsLKYR7/AlLW3NtOrpXRLeawpDLMsVkmk5DG0NXgWw==", + "node_modules/remark-stringify": { + "version": "11.0.0", + "resolved": "https://registry.npmjs.org/remark-stringify/-/remark-stringify-11.0.0.tgz", + "integrity": "sha512-1OSmLd3awB/t8qdoEOMazZkNsfVTeY4fTsgzcQFdXNq8ToTN4ZGwrMnlda4K6smTFKD+GRV6O48i6Z4iKgPPpw==", "dev": true, "license": "MIT", "dependencies": { - "@types/unist": "^2.0.0", - "unist-util-stringify-position": "^3.0.0" + "@types/mdast": "^4.0.0", + "mdast-util-to-markdown": "^2.0.0", + "unified": "^11.0.0" }, "funding": { "type": "opencollective", @@ -7292,9 +6473,9 @@ } }, "node_modules/remark-validate-links": { - "version": "13.0.1", - "resolved": "https://registry.npmjs.org/remark-validate-links/-/remark-validate-links-13.0.1.tgz", - "integrity": "sha512-GWDZWJAQU0+Fsm1GCLNeJoVcE9L3XTVrWCgQZOYREfXqRFIYaSoIBbARZizLm/vBESq+a3GwEBnIflSCNw26tw==", + "version": "13.1.0", + "resolved": "https://registry.npmjs.org/remark-validate-links/-/remark-validate-links-13.1.0.tgz", + "integrity": "sha512-z+glZ4zoRyrWimQHtoqJEFJdPoIR1R1SDr/JoWjmS6EsYlyhxNuCHtIt165gmV7ltOSFJ+rGsipqRGfBPInd7A==", "dev": true, "license": "MIT", "dependencies": { @@ -7316,19 +6497,22 @@ } }, "node_modules/resolve": { - "version": "1.22.8", - "resolved": "https://registry.npmjs.org/resolve/-/resolve-1.22.8.tgz", - "integrity": "sha512-oKWePCxqpd6FlLvGV1VU0x7bkPmmCNolxzjMf4NczoDnQcIWrAF+cPtZn5i6n+RfD2d9i0tzpKnG6Yk168yIyw==", + "version": "1.22.10", + "resolved": "https://registry.npmjs.org/resolve/-/resolve-1.22.10.tgz", + "integrity": "sha512-NPRy+/ncIMeDlTAsuqwKIiferiawhefFJtkNSW0qZJEqMEb+qBt/77B/jGeeek+F0uOeN05CDa6HXbbIgtVX4w==", "dev": true, "license": "MIT", "dependencies": { - "is-core-module": "^2.13.0", + "is-core-module": "^2.16.0", "path-parse": "^1.0.7", "supports-preserve-symlinks-flag": "^1.0.0" }, "bin": { "resolve": "bin/resolve" }, + "engines": { + "node": ">= 0.4" + }, "funding": { "url": "https://github.com/sponsors/ljharb" } @@ -7343,20 +6527,6 @@ "node": ">=4" } }, - "node_modules/restore-cursor": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/restore-cursor/-/restore-cursor-3.1.0.tgz", - "integrity": "sha512-l+sSefzHpj5qimhFSE5a8nufZYAM3sBSVMAPtYkmC+4EH2anSGaEMXSD0izRQbu9nfyQ9y5JrVmp7E8oZrUjvA==", - "dev": true, - "license": "MIT", - "dependencies": { - "onetime": "^5.1.0", - "signal-exit": "^3.0.2" - }, - "engines": { - "node": ">=8" - } - }, "node_modules/retry": { "version": "0.12.0", "resolved": "https://registry.npmjs.org/retry/-/retry-0.12.0.tgz", @@ -7368,9 +6538,9 @@ } }, "node_modules/reusify": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/reusify/-/reusify-1.0.4.tgz", - "integrity": "sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw==", + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/reusify/-/reusify-1.1.0.tgz", + "integrity": "sha512-g6QUff04oZpHs0eG5p83rFLhHeV00ug/Yf9nZM6fLeUrPguBTkTQOdpAWWspMh55TZfVQDPaN3NQJfbVRAxdIw==", "dev": true, "license": "MIT", "engines": { @@ -7378,16 +6548,6 @@ "node": ">=0.10.0" } }, - "node_modules/run-async": { - "version": "2.4.1", - "resolved": "https://registry.npmjs.org/run-async/-/run-async-2.4.1.tgz", - "integrity": "sha512-tvVnVv01b8c1RrA6Ep7JkStj85Guv/YrMcwqYQnwjsAS2cTmmPGBBjAjpCW7RrSodNSoE2/qg9O4bceNvUuDgQ==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=0.12.0" - } - }, "node_modules/run-parallel": { "version": "1.2.0", "resolved": "https://registry.npmjs.org/run-parallel/-/run-parallel-1.2.0.tgz", @@ -7412,26 +6572,17 @@ "queue-microtask": "^1.2.2" } }, - "node_modules/rxjs": { - "version": "7.8.1", - "resolved": "https://registry.npmjs.org/rxjs/-/rxjs-7.8.1.tgz", - "integrity": "sha512-AA3TVj+0A2iuIoQkWEK/tqFjBq2j+6PO6Y0zJcvzLAFhEFIO3HL0vls9hWLncZbAAbK0mar7oZ4V079I/qPMxg==", - "dev": true, - "license": "Apache-2.0", - "dependencies": { - "tslib": "^2.1.0" - } - }, "node_modules/safe-array-concat": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/safe-array-concat/-/safe-array-concat-1.1.2.tgz", - "integrity": "sha512-vj6RsCsWBCf19jIeHEfkRMw8DPiBb+DMXklQ/1SGDHOMlHdPUkZXFQ2YdplS23zESTijAcurb1aSgJA3AgMu1Q==", + "version": "1.1.3", + "resolved": "https://registry.npmjs.org/safe-array-concat/-/safe-array-concat-1.1.3.tgz", + "integrity": "sha512-AURm5f0jYEOydBj7VQlVvDrjeFgthDdEF5H1dP+6mNpoXOMo1quQqJ4wvJDyRZ9+pO3kGWoOdmV08cSv2aJV6Q==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.7", - "get-intrinsic": "^1.2.4", - "has-symbols": "^1.0.3", + "call-bind": "^1.0.8", + "call-bound": "^1.0.2", + "get-intrinsic": "^1.2.6", + "has-symbols": "^1.1.0", "isarray": "^2.0.5" }, "engines": { @@ -7462,16 +6613,15 @@ ], "license": "MIT" }, - "node_modules/safe-regex-test": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/safe-regex-test/-/safe-regex-test-1.0.3.tgz", - "integrity": "sha512-CdASjNJPvRa7roO6Ra/gLYBTzYzzPyyBXxIMdGW3USQLyjWEls2RgW5UBTXaQVp+OrpeCK3bLem8smtmheoRuw==", + "node_modules/safe-push-apply": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/safe-push-apply/-/safe-push-apply-1.0.0.tgz", + "integrity": "sha512-iKE9w/Z7xCzUMIZqdBsp6pEQvwuEebH4vdpjcDWnyzaI6yl6O9FHvVpmGelvEHNsoY6wGblkxR6Zty/h00WiSA==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.6", "es-errors": "^1.3.0", - "is-regex": "^1.1.4" + "isarray": "^2.0.5" }, "engines": { "node": ">= 0.4" @@ -7480,21 +6630,35 @@ "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/safer-buffer": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/safer-buffer/-/safer-buffer-2.1.2.tgz", - "integrity": "sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==", + "node_modules/safe-regex-test": { + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/safe-regex-test/-/safe-regex-test-1.1.0.tgz", + "integrity": "sha512-x/+Cz4YrimQxQccJf5mKEbIa1NzeCRNI5Ecl/ekmlYaampdNLPalVyIcCZNNH3MvmqBugV5TMYZXv0ljslUlaw==", "dev": true, - "license": "MIT" + "license": "MIT", + "dependencies": { + "call-bound": "^1.0.2", + "es-errors": "^1.3.0", + "is-regex": "^1.2.1" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } }, "node_modules/semver": { - "version": "6.3.1", - "resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz", - "integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==", + "version": "7.7.1", + "resolved": "https://registry.npmjs.org/semver/-/semver-7.7.1.tgz", + "integrity": "sha512-hlq8tAfn0m/61p4BVRcPzIGr6LKiMwo4VM6dGi6pt4qcRkmNzTcWq6eCEjEh+qXjkMDvPlOFFSGwQjoEa6gyMA==", "dev": true, "license": "ISC", "bin": { "semver": "bin/semver.js" + }, + "engines": { + "node": ">=10" } }, "node_modules/set-function-length": { @@ -7531,6 +6695,21 @@ "node": ">= 0.4" } }, + "node_modules/set-proto": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/set-proto/-/set-proto-1.0.0.tgz", + "integrity": "sha512-RJRdvCo6IAnPdsvP/7m6bsQqNnn1FCBX5ZNtFL98MmFF/4xAIJTIg1YbHW5DC2W5SKZanrC6i4HsJqlajw/dZw==", + "dev": true, + "license": "MIT", + "dependencies": { + "dunder-proto": "^1.0.1", + "es-errors": "^1.3.0", + "es-object-atoms": "^1.0.0" + }, + "engines": { + "node": ">= 0.4" + } + }, "node_modules/shebang-command": { "version": "2.0.0", "resolved": "https://registry.npmjs.org/shebang-command/-/shebang-command-2.0.0.tgz", @@ -7555,16 +6734,73 @@ } }, "node_modules/side-channel": { - "version": "1.0.6", - "resolved": "https://registry.npmjs.org/side-channel/-/side-channel-1.0.6.tgz", - "integrity": "sha512-fDW/EZ6Q9RiO8eFG8Hj+7u/oW+XrPTIChwCOM2+th2A6OblDtYYIpve9m+KvI9Z4C9qSEXlaGR6bTEYHReuglA==", + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/side-channel/-/side-channel-1.1.0.tgz", + "integrity": "sha512-ZX99e6tRweoUXqR+VBrslhda51Nh5MTQwou5tnUDgbtyM0dBgmhEDtWGP/xbKn6hqfPRHujUNwz5fy/wbbhnpw==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.7", "es-errors": "^1.3.0", - "get-intrinsic": "^1.2.4", - "object-inspect": "^1.13.1" + "object-inspect": "^1.13.3", + "side-channel-list": "^1.0.0", + "side-channel-map": "^1.0.1", + "side-channel-weakmap": "^1.0.2" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/side-channel-list": { + "version": "1.0.0", + "resolved": "https://registry.npmjs.org/side-channel-list/-/side-channel-list-1.0.0.tgz", + "integrity": "sha512-FCLHtRD/gnpCiCHEiJLOwdmFP+wzCmDEkc9y7NsYxeF4u7Btsn1ZuwgwJGxImImHicJArLP4R0yX4c2KCrMrTA==", + "dev": true, + "license": "MIT", + "dependencies": { + "es-errors": "^1.3.0", + "object-inspect": "^1.13.3" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/side-channel-map": { + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/side-channel-map/-/side-channel-map-1.0.1.tgz", + "integrity": "sha512-VCjCNfgMsby3tTdo02nbjtM/ewra6jPHmpThenkTYh8pG9ucZ/1P8So4u4FGBek/BjpOVsDCMoLA/iuBKIFXRA==", + "dev": true, + "license": "MIT", + "dependencies": { + "call-bound": "^1.0.2", + "es-errors": "^1.3.0", + "get-intrinsic": "^1.2.5", + "object-inspect": "^1.13.3" + }, + "engines": { + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" + } + }, + "node_modules/side-channel-weakmap": { + "version": "1.0.2", + "resolved": "https://registry.npmjs.org/side-channel-weakmap/-/side-channel-weakmap-1.0.2.tgz", + "integrity": "sha512-WPS/HvHQTYnHisLo9McqBHOJk2FkHO/tlpvldyrnem4aeQp4hai3gythswg6p01oSoTl58rcpiFAjF2br2Ak2A==", + "dev": true, + "license": "MIT", + "dependencies": { + "call-bound": "^1.0.2", + "es-errors": "^1.3.0", + "get-intrinsic": "^1.2.5", + "object-inspect": "^1.13.3", + "side-channel-map": "^1.0.1" }, "engines": { "node": ">= 0.4" @@ -7574,11 +6810,17 @@ } }, "node_modules/signal-exit": { - "version": "3.0.7", - "resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-3.0.7.tgz", - "integrity": "sha512-wnD2ZE+l+SPC/uoS0vXeE9L1+0wuaMqKlfz9AMUo38JsyLSBWSFcHR1Rri62LZc12vLr1gb3jl7iwQhgwpAbGQ==", + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-4.1.0.tgz", + "integrity": "sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw==", "dev": true, - "license": "ISC" + "license": "ISC", + "engines": { + "node": ">=14" + }, + "funding": { + "url": "https://github.com/sponsors/isaacs" + } }, "node_modules/space-separated-tokens": { "version": "2.0.2", @@ -7621,9 +6863,9 @@ } }, "node_modules/spdx-license-ids": { - "version": "3.0.20", - "resolved": "https://registry.npmjs.org/spdx-license-ids/-/spdx-license-ids-3.0.20.tgz", - "integrity": "sha512-jg25NiDV/1fLtSgEgyvVyDunvaNHbuwF9lfNV17gSmPFAlYzdfNBlLtLzXTevwkPj7DhGbmN9VnmJIgLnhvaBw==", + "version": "3.0.21", + "resolved": "https://registry.npmjs.org/spdx-license-ids/-/spdx-license-ids-3.0.21.tgz", + "integrity": "sha512-Bvg/8F5XephndSK3JffaRqdT+gyhfqIPwDHpX80tJrF8QQRYMo8sNMeaZ2Dp5+jhwKnUmIOyFFQfHRkjJm5nXg==", "dev": true, "license": "CC0-1.0" }, @@ -7638,18 +6880,21 @@ } }, "node_modules/string-width": { - "version": "4.2.3", - "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz", - "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==", + "version": "5.1.2", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-5.1.2.tgz", + "integrity": "sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==", "dev": true, "license": "MIT", "dependencies": { - "emoji-regex": "^8.0.0", - "is-fullwidth-code-point": "^3.0.0", - "strip-ansi": "^6.0.1" + "eastasianwidth": "^0.2.0", + "emoji-regex": "^9.2.2", + "strip-ansi": "^7.0.1" }, "engines": { - "node": ">=8" + "node": ">=12" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" } }, "node_modules/string-width-cjs": { @@ -7668,17 +6913,50 @@ "node": ">=8" } }, + "node_modules/string-width-cjs/node_modules/ansi-regex": { + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz", + "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==", + "dev": true, + "license": "MIT", + "engines": { + "node": ">=8" + } + }, + "node_modules/string-width-cjs/node_modules/emoji-regex": { + "version": "8.0.0", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz", + "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==", + "dev": true, + "license": "MIT" + }, + "node_modules/string-width-cjs/node_modules/strip-ansi": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", + "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "dev": true, + "license": "MIT", + "dependencies": { + "ansi-regex": "^5.0.1" + }, + "engines": { + "node": ">=8" + } + }, "node_modules/string.prototype.trim": { - "version": "1.2.9", - "resolved": "https://registry.npmjs.org/string.prototype.trim/-/string.prototype.trim-1.2.9.tgz", - "integrity": "sha512-klHuCNxiMZ8MlsOihJhJEBJAiMVqU3Z2nEXWfWnIqjN0gEFS9J9+IxKozWWtQGcgoa1WUZzLjKPTr4ZHNFTFxw==", + "version": "1.2.10", + "resolved": "https://registry.npmjs.org/string.prototype.trim/-/string.prototype.trim-1.2.10.tgz", + "integrity": "sha512-Rs66F0P/1kedk5lyYyH9uBzuiI/kNRmwJAR9quK6VOtIpZ2G+hMZd+HQbbv25MgCA6gEffoMZYxlTod4WcdrKA==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.7", + "call-bind": "^1.0.8", + "call-bound": "^1.0.2", + "define-data-property": "^1.1.4", "define-properties": "^1.2.1", - "es-abstract": "^1.23.0", - "es-object-atoms": "^1.0.0" + "es-abstract": "^1.23.5", + "es-object-atoms": "^1.0.0", + "has-property-descriptors": "^1.0.2" }, "engines": { "node": ">= 0.4" @@ -7688,16 +6966,20 @@ } }, "node_modules/string.prototype.trimend": { - "version": "1.0.8", - "resolved": "https://registry.npmjs.org/string.prototype.trimend/-/string.prototype.trimend-1.0.8.tgz", - "integrity": "sha512-p73uL5VCHCO2BZZ6krwwQE3kCzM7NKmis8S//xEC6fQonchbum4eP6kR4DLEjQFO3Wnj3Fuo8NM0kOSjVdHjZQ==", + "version": "1.0.9", + "resolved": "https://registry.npmjs.org/string.prototype.trimend/-/string.prototype.trimend-1.0.9.tgz", + "integrity": "sha512-G7Ok5C6E/j4SGfyLCloXTrngQIQU3PWtXGst3yM7Bea9FRURf1S42ZHlZZtsNque2FN2PoUhfZXYLNWwEr4dLQ==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.7", + "call-bind": "^1.0.8", + "call-bound": "^1.0.2", "define-properties": "^1.2.1", "es-object-atoms": "^1.0.0" }, + "engines": { + "node": ">= 0.4" + }, "funding": { "url": "https://github.com/sponsors/ljharb" } @@ -7736,16 +7018,19 @@ } }, "node_modules/strip-ansi": { - "version": "6.0.1", - "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", - "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "version": "7.1.0", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz", + "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==", "dev": true, "license": "MIT", "dependencies": { - "ansi-regex": "^5.0.1" + "ansi-regex": "^6.0.1" }, "engines": { - "node": ">=8" + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/strip-ansi?sponsor=1" } }, "node_modules/strip-ansi-cjs": { @@ -7762,6 +7047,16 @@ "node": ">=8" } }, + "node_modules/strip-ansi-cjs/node_modules/ansi-regex": { + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz", + "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==", + "dev": true, + "license": "MIT", + "engines": { + "node": ">=8" + } + }, "node_modules/strip-bom": { "version": "3.0.0", "resolved": "https://registry.npmjs.org/strip-bom/-/strip-bom-3.0.0.tgz", @@ -7818,26 +7113,6 @@ "dev": true, "license": "MIT" }, - "node_modules/through": { - "version": "2.3.8", - "resolved": "https://registry.npmjs.org/through/-/through-2.3.8.tgz", - "integrity": "sha512-w89qg7PI8wAdvX60bMDP+bFoD5Dvhm9oLheFp5O4a2QF0cSBGsBX4qZmadPMvVqlLJBBci+WqGGOAPvcDeNSVg==", - "dev": true, - "license": "MIT" - }, - "node_modules/tmp": { - "version": "0.0.33", - "resolved": "https://registry.npmjs.org/tmp/-/tmp-0.0.33.tgz", - "integrity": "sha512-jRCJlojKnZ3addtTOjdIqoRuPEKBvNXcGYqzO6zWZX8KfKEpnGY5jfggJQ3EjKuu8D4bJRr0y+cYJFmYbImXGw==", - "dev": true, - "license": "MIT", - "dependencies": { - "os-tmpdir": "~1.0.2" - }, - "engines": { - "node": ">=0.6.0" - } - }, "node_modules/to-regex-range": { "version": "5.0.1", "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz", @@ -7874,16 +7149,16 @@ } }, "node_modules/ts-api-utils": { - "version": "1.3.0", - "resolved": "https://registry.npmjs.org/ts-api-utils/-/ts-api-utils-1.3.0.tgz", - "integrity": "sha512-UQMIo7pb8WRomKR1/+MFVLTroIvDVtMX3K6OUir8ynLyzB8Jeriont2bTAtmNPa1ekAgN7YPDyf6V+ygrdU+eQ==", + "version": "2.0.1", + "resolved": "https://registry.npmjs.org/ts-api-utils/-/ts-api-utils-2.0.1.tgz", + "integrity": "sha512-dnlgjFSVetynI8nzgJ+qF62efpglpWRk8isUEWZGWlJYySCTD6aKvbUDu+zbPeDakk3bg5H4XpitHukgfL1m9w==", "dev": true, "license": "MIT", "engines": { - "node": ">=16" + "node": ">=18.12" }, "peerDependencies": { - "typescript": ">=4.2.0" + "typescript": ">=4.8.4" } }, "node_modules/tsconfig-paths": { @@ -7899,13 +7174,6 @@ "strip-bom": "^3.0.0" } }, - "node_modules/tslib": { - "version": "2.8.0", - "resolved": "https://registry.npmjs.org/tslib/-/tslib-2.8.0.tgz", - "integrity": "sha512-jWVzBLplnCmoaTr13V9dYbiQ99wvZRd0vNWaDRg+aVYRcjDF3nDksxFDE/+fkXnKhpnUUkmx5pK/v8mCtLVqZA==", - "dev": true, - "license": "0BSD" - }, "node_modules/type-check": { "version": "0.4.0", "resolved": "https://registry.npmjs.org/type-check/-/type-check-0.4.0.tgz", @@ -7919,33 +7187,46 @@ "node": ">= 0.8.0" } }, + "node_modules/type-fest": { + "version": "3.13.1", + "resolved": "https://registry.npmjs.org/type-fest/-/type-fest-3.13.1.tgz", + "integrity": "sha512-tLq3bSNx+xSpwvAJnzrK0Ep5CLNWjvFTOp71URMaAEWBfRb9nnJiBoUe0tF8bI4ZFO3omgBR6NvnbzVUT3Ly4g==", + "dev": true, + "license": "(MIT OR CC0-1.0)", + "engines": { + "node": ">=14.16" + }, + "funding": { + "url": "https://github.com/sponsors/sindresorhus" + } + }, "node_modules/typed-array-buffer": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/typed-array-buffer/-/typed-array-buffer-1.0.2.tgz", - "integrity": "sha512-gEymJYKZtKXzzBzM4jqa9w6Q1Jjm7x2d+sh19AdsD4wqnMPDYyvwpsIc2Q/835kHuo3BEQ7CjelGhfTsoBb2MQ==", + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/typed-array-buffer/-/typed-array-buffer-1.0.3.tgz", + "integrity": "sha512-nAYYwfY3qnzX30IkA6AQZjVbtK6duGontcQm1WSG1MD94YLqK0515GNApXkoxKOWMusVssAHWLh9SeaoefYFGw==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.7", + "call-bound": "^1.0.3", "es-errors": "^1.3.0", - "is-typed-array": "^1.1.13" + "is-typed-array": "^1.1.14" }, "engines": { "node": ">= 0.4" } }, "node_modules/typed-array-byte-length": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/typed-array-byte-length/-/typed-array-byte-length-1.0.1.tgz", - "integrity": "sha512-3iMJ9q0ao7WE9tWcaYKIptkNBuOIcZCCT0d4MRvuuH88fEoEH62IuQe0OtraD3ebQEoTRk8XCBoknUNc1Y67pw==", + "version": "1.0.3", + "resolved": "https://registry.npmjs.org/typed-array-byte-length/-/typed-array-byte-length-1.0.3.tgz", + "integrity": "sha512-BaXgOuIxz8n8pIq3e7Atg/7s+DpiYrxn4vdot3w9KbnBhcRQq6o3xemQdIfynqSeXeDrF32x+WvfzmOjPiY9lg==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.7", + "call-bind": "^1.0.8", "for-each": "^0.3.3", - "gopd": "^1.0.1", - "has-proto": "^1.0.3", - "is-typed-array": "^1.1.13" + "gopd": "^1.2.0", + "has-proto": "^1.2.0", + "is-typed-array": "^1.1.14" }, "engines": { "node": ">= 0.4" @@ -7955,18 +7236,19 @@ } }, "node_modules/typed-array-byte-offset": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/typed-array-byte-offset/-/typed-array-byte-offset-1.0.2.tgz", - "integrity": "sha512-Ous0vodHa56FviZucS2E63zkgtgrACj7omjwd/8lTEMEPFFyjfixMZ1ZXenpgCFBBt4EC1J2XsyVS2gkG0eTFA==", + "version": "1.0.4", + "resolved": "https://registry.npmjs.org/typed-array-byte-offset/-/typed-array-byte-offset-1.0.4.tgz", + "integrity": "sha512-bTlAFB/FBYMcuX81gbL4OcpH5PmlFHqlCCpAl8AlEzMz5k53oNDvN8p1PNOWLEmI2x4orp3raOFB51tv9X+MFQ==", "dev": true, "license": "MIT", "dependencies": { "available-typed-arrays": "^1.0.7", - "call-bind": "^1.0.7", + "call-bind": "^1.0.8", "for-each": "^0.3.3", - "gopd": "^1.0.1", - "has-proto": "^1.0.3", - "is-typed-array": "^1.1.13" + "gopd": "^1.2.0", + "has-proto": "^1.2.0", + "is-typed-array": "^1.1.15", + "reflect.getprototypeof": "^1.0.9" }, "engines": { "node": ">= 0.4" @@ -7976,18 +7258,18 @@ } }, "node_modules/typed-array-length": { - "version": "1.0.6", - "resolved": "https://registry.npmjs.org/typed-array-length/-/typed-array-length-1.0.6.tgz", - "integrity": "sha512-/OxDN6OtAk5KBpGb28T+HZc2M+ADtvRxXrKKbUwtsLgdoxgX13hyy7ek6bFRl5+aBs2yZzB0c4CnQfAtVypW/g==", + "version": "1.0.7", + "resolved": "https://registry.npmjs.org/typed-array-length/-/typed-array-length-1.0.7.tgz", + "integrity": "sha512-3KS2b+kL7fsuk/eJZ7EQdnEmQoaho/r6KUef7hxvltNA5DR8NAUM+8wJMbJyZ4G9/7i3v5zPBIMN5aybAh2/Jg==", "dev": true, "license": "MIT", "dependencies": { "call-bind": "^1.0.7", "for-each": "^0.3.3", "gopd": "^1.0.1", - "has-proto": "^1.0.3", "is-typed-array": "^1.1.13", - "possible-typed-array-names": "^1.0.0" + "possible-typed-array-names": "^1.0.0", + "reflect.getprototypeof": "^1.0.6" }, "engines": { "node": ">= 0.4" @@ -8004,9 +7286,9 @@ "license": "MIT" }, "node_modules/typescript": { - "version": "5.6.3", - "resolved": "https://registry.npmjs.org/typescript/-/typescript-5.6.3.tgz", - "integrity": "sha512-hjcS1mhfuyi4WW8IWtjP7brDrG2cuDZukyrYrSauoXGNgx0S7zceP07adYkJycEr56BOUTNPzbInooiN3fn1qw==", + "version": "5.8.2", + "resolved": "https://registry.npmjs.org/typescript/-/typescript-5.8.2.tgz", + "integrity": "sha512-aJn6wq13/afZp/jT9QZmwEjDqqvSGp1VT5GVg+f/t6/oVyrgXM6BY1h9BRh/O5p3PlUPAe+WuiEZOmb/49RqoQ==", "dev": true, "license": "Apache-2.0", "peer": true, @@ -8019,35 +7301,28 @@ } }, "node_modules/unbox-primitive": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/unbox-primitive/-/unbox-primitive-1.0.2.tgz", - "integrity": "sha512-61pPlCD9h51VoreyJ0BReideM3MDKMKnh6+V9L08331ipq6Q8OFXZYiqP6n/tbHx4s5I9uRhcye6BrbkizkBDw==", + "version": "1.1.0", + "resolved": "https://registry.npmjs.org/unbox-primitive/-/unbox-primitive-1.1.0.tgz", + "integrity": "sha512-nWJ91DjeOkej/TA8pXQ3myruKpKEYgqvpw9lz4OPHj/NWFNluYrjbz9j01CJ8yKQd2g4jFoOkINCTW2I5LEEyw==", "dev": true, "license": "MIT", "dependencies": { - "call-bind": "^1.0.2", + "call-bound": "^1.0.3", "has-bigints": "^1.0.2", - "has-symbols": "^1.0.3", - "which-boxed-primitive": "^1.0.2" + "has-symbols": "^1.1.0", + "which-boxed-primitive": "^1.1.1" + }, + "engines": { + "node": ">= 0.4" }, "funding": { "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/undici": { - "version": "6.20.1", - "resolved": "https://registry.npmjs.org/undici/-/undici-6.20.1.tgz", - "integrity": "sha512-AjQF1QsmqfJys+LXfGTNum+qw4S88CojRInG/6t31W/1fk6G59s92bnAvGz5Cmur+kQv2SURXEvvudLmbrE8QA==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=18.17" - } - }, "node_modules/undici-types": { - "version": "6.19.8", - "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-6.19.8.tgz", - "integrity": "sha512-ve2KP6f/JnbPBFyobGHuerC9g1FYGn/F8n1LWTwNxCEzd6IfqTwUQcNXgEtmmQ6DlRrC1hrSrBnCZPokRrDHjw==", + "version": "6.20.0", + "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-6.20.0.tgz", + "integrity": "sha512-Ny6QZ2Nju20vw1SRHe3d9jVu6gJ+4e3+MMpqu7pqE5HT6WsTSlce++GQmK5UXS8mzV8DSYHrQH+Xrf2jVcuKNg==", "dev": true, "license": "MIT" }, @@ -8093,23 +7368,10 @@ "url": "https://opencollective.com/unified" } }, - "node_modules/unified-args/node_modules/ansi-regex": { - "version": "6.1.0", - "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.1.0.tgz", - "integrity": "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/chalk/ansi-regex?sponsor=1" - } - }, "node_modules/unified-args/node_modules/chalk": { - "version": "5.3.0", - "resolved": "https://registry.npmjs.org/chalk/-/chalk-5.3.0.tgz", - "integrity": "sha512-dLitG79d+GV1Nb/VYcCDFivJeK1hiukt9QjRNVOsUtTy1rR1YJsmpGGTZ3qJos+uw7WmWF4wUwBd9jxjocFC2w==", + "version": "5.4.1", + "resolved": "https://registry.npmjs.org/chalk/-/chalk-5.4.1.tgz", + "integrity": "sha512-zgVZuo2WcZgfUEmsn6eO3kINexW8RAE4maiQ8QNs8CtpPCSyMiYsULR3HQYkm3w8FIA3SberyMJMSldGsW+U3w==", "dev": true, "license": "MIT", "engines": { @@ -8132,39 +7394,23 @@ "node": ">=6" } }, - "node_modules/unified-args/node_modules/strip-ansi": { - "version": "7.1.0", - "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz", - "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==", - "dev": true, - "license": "MIT", - "dependencies": { - "ansi-regex": "^6.0.1" - }, - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/chalk/strip-ansi?sponsor=1" - } - }, "node_modules/unified-engine": { - "version": "11.2.1", - "resolved": "https://registry.npmjs.org/unified-engine/-/unified-engine-11.2.1.tgz", - "integrity": "sha512-xBAdZ8UY2X4R9Hm6X6kMne4Nz0PlpOc1oE6DPeqJnewr5Imkb8uT5Eyvy1h7xNekPL3PSWh3ZJyNrMW6jnNQBg==", + "version": "11.2.2", + "resolved": "https://registry.npmjs.org/unified-engine/-/unified-engine-11.2.2.tgz", + "integrity": "sha512-15g/gWE7qQl9tQ3nAEbMd5h9HV1EACtFs6N9xaRBZICoCwnNGbal1kOs++ICf4aiTdItZxU2s/kYWhW7htlqJg==", "dev": true, "license": "MIT", "dependencies": { "@types/concat-stream": "^2.0.0", "@types/debug": "^4.0.0", "@types/is-empty": "^1.0.0", - "@types/node": "^20.0.0", + "@types/node": "^22.0.0", "@types/unist": "^3.0.0", "concat-stream": "^2.0.0", "debug": "^4.0.0", "extend": "^3.0.0", "glob": "^10.0.0", - "ignore": "^5.0.0", + "ignore": "^6.0.0", "is-empty": "^1.0.0", "is-plain-obj": "^4.0.0", "load-plugin": "^6.0.0", @@ -8189,57 +7435,20 @@ "dev": true, "license": "MIT" }, - "node_modules/unified-engine/node_modules/brace-expansion": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz", - "integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==", + "node_modules/unified-engine/node_modules/ignore": { + "version": "6.0.2", + "resolved": "https://registry.npmjs.org/ignore/-/ignore-6.0.2.tgz", + "integrity": "sha512-InwqeHHN2XpumIkMvpl/DCJVrAHgCsG5+cn1XlnLWGwtZBm8QJfSusItfrwx81CTp5agNZqpKU2J/ccC5nGT4A==", "dev": true, "license": "MIT", - "dependencies": { - "balanced-match": "^1.0.0" - } - }, - "node_modules/unified-engine/node_modules/glob": { - "version": "10.4.5", - "resolved": "https://registry.npmjs.org/glob/-/glob-10.4.5.tgz", - "integrity": "sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==", - "dev": true, - "license": "ISC", - "dependencies": { - "foreground-child": "^3.1.0", - "jackspeak": "^3.1.2", - "minimatch": "^9.0.4", - "minipass": "^7.1.2", - "package-json-from-dist": "^1.0.0", - "path-scurry": "^1.11.1" - }, - "bin": { - "glob": "dist/esm/bin.mjs" - }, - "funding": { - "url": "https://github.com/sponsors/isaacs" - } - }, - "node_modules/unified-engine/node_modules/minimatch": { - "version": "9.0.5", - "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.5.tgz", - "integrity": "sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==", - "dev": true, - "license": "ISC", - "dependencies": { - "brace-expansion": "^2.0.1" - }, "engines": { - "node": ">=16 || 14 >=14.17" - }, - "funding": { - "url": "https://github.com/sponsors/isaacs" + "node": ">= 4" } }, "node_modules/unified-lint-rule": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/unified-lint-rule/-/unified-lint-rule-3.0.0.tgz", - "integrity": "sha512-Sz96ILLsTy3djsG3H44zFb2b77MFf9CQVYnV3PWkxgRX8/n31fFrr+JnzUaJ6cbOHTtZnL1A71+YodsTjzwAew==", + "version": "3.0.1", + "resolved": "https://registry.npmjs.org/unified-lint-rule/-/unified-lint-rule-3.0.1.tgz", + "integrity": "sha512-HxIeQOmwL19DGsxHXbeyzKHBsoSCFO7UtRVUvT2v61ptw/G+GbysWcrpHdfs5jqbIFDA11MoKngIhQK0BeTVjA==", "dev": true, "license": "MIT", "dependencies": { @@ -8402,20 +7611,6 @@ "dev": true, "license": "MIT" }, - "node_modules/unist-util-map": { - "version": "3.1.3", - "resolved": "https://registry.npmjs.org/unist-util-map/-/unist-util-map-3.1.3.tgz", - "integrity": "sha512-4/mDauoxqZ6geK97lJ6n2kDk6JK88Vh+hWMSJqyaaP/7eqN1dDhjcjnNxKNm3YU6Sw7PVJtcFMUbnmHvYzb6Vg==", - "dev": true, - "license": "MIT", - "dependencies": { - "@types/unist": "^2.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, "node_modules/unist-util-position": { "version": "5.0.0", "resolved": "https://registry.npmjs.org/unist-util-position/-/unist-util-position-5.0.0.tgz", @@ -8503,16 +7698,6 @@ "dev": true, "license": "MIT" }, - "node_modules/universalify": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/universalify/-/universalify-2.0.1.tgz", - "integrity": "sha512-gptHNQghINnc/vTGIk0SOFGFNXw7JVrlRUtConJRlvaw6DuX0wO5Jeko9sWrMBhh+PsYAZ7oXAiOnf/UKogyiw==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">= 10.0.0" - } - }, "node_modules/uri-js": { "version": "4.4.1", "resolved": "https://registry.npmjs.org/uri-js/-/uri-js-4.4.1.tgz", @@ -8631,19 +7816,6 @@ "url": "https://opencollective.com/unified" } }, - "node_modules/vfile-reporter/node_modules/ansi-regex": { - "version": "6.1.0", - "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.1.0.tgz", - "integrity": "sha512-7HSX4QQb4CspciLpVFwyRe79O3xsIZDDLER21kERQ71oaPodF8jL725AgJMFAYbooIqolJoRLuM81SpeUkpkvA==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/chalk/ansi-regex?sponsor=1" - } - }, "node_modules/vfile-reporter/node_modules/emoji-regex": { "version": "10.4.0", "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-10.4.0.tgz", @@ -8669,22 +7841,6 @@ "url": "https://github.com/sponsors/sindresorhus" } }, - "node_modules/vfile-reporter/node_modules/strip-ansi": { - "version": "7.1.0", - "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz", - "integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==", - "dev": true, - "license": "MIT", - "dependencies": { - "ansi-regex": "^6.0.1" - }, - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/chalk/strip-ansi?sponsor=1" - } - }, "node_modules/vfile-reporter/node_modules/supports-color": { "version": "9.4.0", "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-9.4.0.tgz", @@ -8742,94 +7898,102 @@ "dev": true, "license": "ISC" }, - "node_modules/wcwidth": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/wcwidth/-/wcwidth-1.0.1.tgz", - "integrity": "sha512-XHPEwS0q6TaxcvG85+8EYkbiCux2XtWG2mkc47Ng2A77BQu9+DqIOJldST4HgPkuea7dvKSj5VgX3P1d4rW8Tg==", + "node_modules/which": { + "version": "2.0.2", + "resolved": "https://registry.npmjs.org/which/-/which-2.0.2.tgz", + "integrity": "sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==", "dev": true, - "license": "MIT", + "license": "ISC", "dependencies": { - "defaults": "^1.0.3" - } - }, - "node_modules/web-namespaces": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/web-namespaces/-/web-namespaces-2.0.1.tgz", - "integrity": "sha512-bKr1DkiNa2krS7qxNtdrtHAmzuYGFQLiQ13TsorsdT6ULTkPLKuu5+GsFpDlg6JFjUTwX2DyhMPG2be8uPrqsQ==", - "dev": true, - "license": "MIT", - "funding": { - "type": "github", - "url": "https://github.com/sponsors/wooorm" + "isexe": "^2.0.0" + }, + "bin": { + "node-which": "bin/node-which" + }, + "engines": { + "node": ">= 8" } }, - "node_modules/whatwg-encoding": { - "version": "3.1.1", - "resolved": "https://registry.npmjs.org/whatwg-encoding/-/whatwg-encoding-3.1.1.tgz", - "integrity": "sha512-6qN4hJdMwfYBtE3YBTTHhoeuUrDBPZmbQaxWAqSALV/MeEnR5z1xd8UKud2RAkFoPkmB+hli1TZSnyi84xz1vQ==", + "node_modules/which-boxed-primitive": { + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/which-boxed-primitive/-/which-boxed-primitive-1.1.1.tgz", + "integrity": "sha512-TbX3mj8n0odCBFVlY8AxkqcHASw3L60jIuF8jFP78az3C2YhmGvqbHBpAjTRH2/xqYunrJ9g1jSyjCjpoWzIAA==", "dev": true, "license": "MIT", "dependencies": { - "iconv-lite": "0.6.3" + "is-bigint": "^1.1.0", + "is-boolean-object": "^1.2.1", + "is-number-object": "^1.1.1", + "is-string": "^1.1.1", + "is-symbol": "^1.1.1" }, "engines": { - "node": ">=18" + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/whatwg-mimetype": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/whatwg-mimetype/-/whatwg-mimetype-4.0.0.tgz", - "integrity": "sha512-QaKxh0eNIi2mE9p2vEdzfagOKHCcj1pJ56EEHGQOVxp8r9/iszLUUV7v89x9O1p/T+NlTM5W7jW6+cz4Fq1YVg==", + "node_modules/which-builtin-type": { + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/which-builtin-type/-/which-builtin-type-1.2.1.tgz", + "integrity": "sha512-6iBczoX+kDQ7a3+YJBnh3T+KZRxM/iYNPXicqk66/Qfm1b93iu+yOImkg0zHbj5LNOcNv1TEADiZ0xa34B4q6Q==", "dev": true, "license": "MIT", - "engines": { - "node": ">=18" - } - }, - "node_modules/which": { - "version": "2.0.2", - "resolved": "https://registry.npmjs.org/which/-/which-2.0.2.tgz", - "integrity": "sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==", - "dev": true, - "license": "ISC", "dependencies": { - "isexe": "^2.0.0" - }, - "bin": { - "node-which": "bin/node-which" + "call-bound": "^1.0.2", + "function.prototype.name": "^1.1.6", + "has-tostringtag": "^1.0.2", + "is-async-function": "^2.0.0", + "is-date-object": "^1.1.0", + "is-finalizationregistry": "^1.1.0", + "is-generator-function": "^1.0.10", + "is-regex": "^1.2.1", + "is-weakref": "^1.0.2", + "isarray": "^2.0.5", + "which-boxed-primitive": "^1.1.0", + "which-collection": "^1.0.2", + "which-typed-array": "^1.1.16" }, "engines": { - "node": ">= 8" + "node": ">= 0.4" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" } }, - "node_modules/which-boxed-primitive": { + "node_modules/which-collection": { "version": "1.0.2", - "resolved": "https://registry.npmjs.org/which-boxed-primitive/-/which-boxed-primitive-1.0.2.tgz", - "integrity": "sha512-bwZdv0AKLpplFY2KZRX6TvyuN7ojjr7lwkg6ml0roIy9YeuSr7JS372qlNW18UQYzgYK9ziGcerWqZOmEn9VNg==", + "resolved": "https://registry.npmjs.org/which-collection/-/which-collection-1.0.2.tgz", + "integrity": "sha512-K4jVyjnBdgvc86Y6BkaLZEN933SwYOuBFkdmBu9ZfkcAbdVbpITnDmjvZ/aQjRXQrv5EPkTnD1s39GiiqbngCw==", "dev": true, "license": "MIT", "dependencies": { - "is-bigint": "^1.0.1", - "is-boolean-object": "^1.1.0", - "is-number-object": "^1.0.4", - "is-string": "^1.0.5", - "is-symbol": "^1.0.3" + "is-map": "^2.0.3", + "is-set": "^2.0.3", + "is-weakmap": "^2.0.2", + "is-weakset": "^2.0.3" + }, + "engines": { + "node": ">= 0.4" }, "funding": { "url": "https://github.com/sponsors/ljharb" } }, "node_modules/which-typed-array": { - "version": "1.1.15", - "resolved": "https://registry.npmjs.org/which-typed-array/-/which-typed-array-1.1.15.tgz", - "integrity": "sha512-oV0jmFtUky6CXfkqehVvBP/LSWJ2sy4vWMioiENyJLePrBO/yKyV9OyJySfAKosh+RYkIl5zJCNZ8/4JncrpdA==", + "version": "1.1.19", + "resolved": "https://registry.npmjs.org/which-typed-array/-/which-typed-array-1.1.19.tgz", + "integrity": "sha512-rEvr90Bck4WZt9HHFC4DJMsjvu7x+r6bImz0/BrbWb7A2djJ8hnZMrWnHo9F8ssv0OMErasDhftrfROTyqSDrw==", "dev": true, "license": "MIT", "dependencies": { "available-typed-arrays": "^1.0.7", - "call-bind": "^1.0.7", - "for-each": "^0.3.3", - "gopd": "^1.0.1", + "call-bind": "^1.0.8", + "call-bound": "^1.0.4", + "for-each": "^0.3.5", + "get-proto": "^1.0.1", + "gopd": "^1.2.0", "has-tostringtag": "^1.0.2" }, "engines": { @@ -8850,18 +8014,21 @@ } }, "node_modules/wrap-ansi": { - "version": "6.2.0", - "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-6.2.0.tgz", - "integrity": "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA==", + "version": "8.1.0", + "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-8.1.0.tgz", + "integrity": "sha512-si7QWI6zUMq56bESFvagtmzMdGOtoxfR+Sez11Mobfc7tm+VkUckk9bW2UeffTGVUbOksxmSw0AA2gs8g71NCQ==", "dev": true, "license": "MIT", "dependencies": { - "ansi-styles": "^4.0.0", - "string-width": "^4.1.0", - "strip-ansi": "^6.0.0" + "ansi-styles": "^6.1.0", + "string-width": "^5.0.1", + "strip-ansi": "^7.0.1" }, "engines": { - "node": ">=8" + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/wrap-ansi?sponsor=1" } }, "node_modules/wrap-ansi-cjs": { @@ -8883,10 +8050,68 @@ "url": "https://github.com/chalk/wrap-ansi?sponsor=1" } }, + "node_modules/wrap-ansi-cjs/node_modules/ansi-regex": { + "version": "5.0.1", + "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz", + "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==", + "dev": true, + "license": "MIT", + "engines": { + "node": ">=8" + } + }, + "node_modules/wrap-ansi-cjs/node_modules/emoji-regex": { + "version": "8.0.0", + "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz", + "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==", + "dev": true, + "license": "MIT" + }, + "node_modules/wrap-ansi-cjs/node_modules/string-width": { + "version": "4.2.3", + "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz", + "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==", + "dev": true, + "license": "MIT", + "dependencies": { + "emoji-regex": "^8.0.0", + "is-fullwidth-code-point": "^3.0.0", + "strip-ansi": "^6.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/wrap-ansi-cjs/node_modules/strip-ansi": { + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz", + "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==", + "dev": true, + "license": "MIT", + "dependencies": { + "ansi-regex": "^5.0.1" + }, + "engines": { + "node": ">=8" + } + }, + "node_modules/wrap-ansi/node_modules/ansi-styles": { + "version": "6.2.1", + "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-6.2.1.tgz", + "integrity": "sha512-bN798gFfQX+viw3R7yrGWRqnrN2oRkEkUjjl4JNn4E8GxxbjtG3FbrEIIY3l8/hrwUwIeCZvi4QuOTP4MErVug==", + "dev": true, + "license": "MIT", + "engines": { + "node": ">=12" + }, + "funding": { + "url": "https://github.com/chalk/ansi-styles?sponsor=1" + } + }, "node_modules/yaml": { - "version": "2.6.0", - "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.6.0.tgz", - "integrity": "sha512-a6ae//JvKDEra2kdi1qzCyrJW/WZCgFi8ydDV+eXExl95t+5R+ijnqHJbz9tmMh8FUjx3iv2fCQ4dclAQlO2UQ==", + "version": "2.7.0", + "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.7.0.tgz", + "integrity": "sha512-+hSoy/QHluxmC9kCIJyL/uyFmLmc+e5CFR5Wa+bpIhIj85LVb9ZH2nVnqrHoSvKogwODv0ClqZkmiSSaIH5LTA==", "dev": true, "license": "ISC", "bin": { diff --git a/package.json b/package.json index 34b5f129..b7a625b6 100644 --- a/package.json +++ b/package.json @@ -11,7 +11,6 @@ "license": "MIT", "devDependencies": { "@stylistic/eslint-plugin": "^2.9.0", - "dotenv": "^16.4.5", "eslint": "^9.13.0", "eslint-import-resolver-node": "^0.3.9", "eslint-plugin-import": "^2.31.0", @@ -19,6 +18,8 @@ "mdast-util-find-and-replace": "^3.0.1", "mdast-util-to-string": "^4.0.0", "rehype-document": "^7.0.3", + "rehype-highlight": "^7.0.2", + "rehype-highlight-code-lines": "^1.1.3", "rehype-stringify": "^10.0.1", "remark-cli": "^12.0.1", "remark-flexible-containers": "^1.2.1", @@ -28,7 +29,6 @@ "remark-preset-lint-markdown-style-guide": "^6.0.0", "remark-preset-lint-recommended": "^7.0.0", "remark-rehype": "^11.1.1", - "remark-torchlight": "^0.0.5", "remark-validate-links": "^13.0.1" } } diff --git a/specs/.remarkrc-build.js b/specs/.remarkrc-build.js index e73b10ad..089e2cce 100644 --- a/specs/.remarkrc-build.js +++ b/specs/.remarkrc-build.js @@ -1,7 +1,8 @@ import { readFileSync } from "node:fs"; import { resolve } from "node:path"; -import dotenv from "dotenv"; -import remarkTorchLight from "remark-torchlight"; +import rehypeHighlight from "rehype-highlight"; +import { all } from "lowlight"; +import rehypeHighlightCodeLines from "rehype-highlight-code-lines"; import remarkRehype from "remark-rehype"; import rehypeStringify from "rehype-stringify"; import rehypeDocument from "rehype-document"; @@ -9,16 +10,18 @@ import specsPreset from "./.remarkrc-specs.js"; import rehypeLinkTransformer from "../remark/rehype-link-transformer.js"; -dotenv.config(); - export default { plugins: [ specsPreset, - remarkTorchLight, remarkRehype, + [rehypeHighlight, { languages: all }], + [rehypeHighlightCodeLines, { showLineNumbers: true }], rehypeLinkTransformer, [rehypeDocument, { - css: ["https://cdn.jsdelivr.net/npm/water.css@2/out/dark.css"], + css: [ + "https://cdn.jsdelivr.net/npm/water.css@2/out/dark.css", + "https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.11.0/styles/github-dark-dimmed.min.css" + ], style: readFileSync(resolve(import.meta.dirname, "spec.css"), "utf8") }], rehypeStringify, diff --git a/specs/spec.css b/specs/spec.css index 06e9b041..6a32bdc6 100644 --- a/specs/spec.css +++ b/specs/spec.css @@ -92,3 +92,30 @@ pre.torchlight code .summary-caret { .remark-container-title.experimental { background-image: url("data:image/svg+xml,%3Csvg version='1.1' id='designs' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' viewBox='0 0 32 32' xml:space='preserve' fill='%23ffffff'%3E%3Cg id='SVGRepo_bgCarrier' stroke-width='0'%3E%3C/g%3E%3Cg id='SVGRepo_tracerCarrier' stroke-linecap='round' stroke-linejoin='round'%3E%3C/g%3E%3Cg id='SVGRepo_iconCarrier'%3E%3Cstyle type='text/css'%3E .sketchy_een%7Bfill:%23ffffff;%7D %3C/style%3E%3Cpath class='sketchy_een' d='M27.958,26.693c-0.023-0.207-0.066-0.377-0.22-0.531c-0.006-0.006-0.015-0.008-0.021-0.014 c0.06-0.187,0.051-0.395-0.057-0.573c-0.326-0.538-0.64-1.08-0.942-1.631c-0.345-0.629-0.716-1.241-1.059-1.87 c-0.351-0.642-0.676-1.296-1.016-1.942c-0.352-0.675-0.773-1.309-1.142-1.974c-0.506-0.907-0.961-1.842-1.47-2.749 c-0.494-0.88-0.958-1.772-1.422-2.667c0.008-0.161-0.007-0.328-0.012-0.488c-0.004-0.168-0.009-0.337-0.017-0.506 c-0.015-0.364-0.042-0.726-0.064-1.087c-0.045-0.722-0.102-1.444-0.133-2.167c-0.062-1.561-0.036-3.121,0.043-4.68 c0.159,0.001,0.318,0.002,0.478,0.001c0.26-0.004,0.519-0.023,0.779-0.011c0.485,0.023,0.89-0.422,0.89-0.89 c0-0.235-0.095-0.462-0.261-0.629c-0.176-0.178-0.386-0.242-0.629-0.261C21.443,2.005,21.202,2,20.96,2 c-0.264,0-0.528,0.006-0.789,0.008C20.05,2.01,19.929,2.01,19.808,2.01c-0.201,0-0.402,0-0.602,0.002 c-0.347,0.004-0.695,0.026-1.042,0.034c-0.39,0.006-0.782,0.002-1.173,0.01c-0.402,0.01-0.803,0.028-1.203,0.042 c-0.769,0.025-1.536,0.068-2.308,0.068c-0.441,0-0.883,0.004-1.322,0c-0.5-0.004-0.998-0.045-1.499-0.066 c-0.445-0.021-0.818,0.386-0.818,0.818c0,0.458,0.373,0.805,0.818,0.82c0.12,0.004,0.24,0.003,0.36,0.006 c0.038,0.704,0.098,1.408,0.133,2.114c0.036,0.722,0.028,1.444,0.049,2.165c0.021,0.68,0.04,1.362,0.061,2.042 c0.019,0.608,0.055,1.214,0.07,1.822c-0.354,0.653-0.68,1.32-1.049,1.964c-0.195,0.341-0.385,0.682-0.563,1.031 c-0.172,0.333-0.316,0.68-0.468,1.023c-0.15,0.337-0.296,0.676-0.46,1.006c-0.165,0.328-0.333,0.656-0.489,0.987 c-0.165,0.352-0.324,0.708-0.493,1.061c-0.155,0.33-0.328,0.652-0.489,0.979c-0.263,0.534-0.496,1.082-0.746,1.622 c-0.267,0.58-0.525,1.165-0.777,1.752c-0.241,0.561-0.519,1.104-0.758,1.665c-0.225,0.529-0.428,1.068-0.647,1.6 c-0.039,0.093-0.079,0.184-0.118,0.278c-0.052,0.117-0.081,0.229-0.091,0.344c-0.087,0.136-0.152,0.288-0.159,0.459 c-0.019,0.46-0.019,0.911,0.218,1.324c0.159,0.281,0.358,0.478,0.618,0.663c0.135,0.095,0.305,0.14,0.457,0.199 c0.241,0.095,0.519,0.097,0.777,0.114c0.368,0.023,0.733,0.002,1.101-0.009c0.402-0.013,0.801-0.034,1.203-0.062 c0.405-0.03,0.813-0.036,1.218-0.047c0.801-0.025,1.605-0.019,2.406-0.004c0.762,0.013,1.519,0.038,2.279,0.1 c0.765,0.064,1.525,0.066,2.292,0.064c0.159,0,0.32,0,0.479,0c0.64,0.002,1.281,0.002,1.923-0.032 c0.756-0.042,1.514-0.053,2.271-0.085c0.392-0.017,0.781-0.055,1.169-0.093c0.377-0.036,0.756-0.047,1.133-0.062 c0.686-0.027,1.37-0.023,2.05-0.117c0.138-0.019,0.277-0.042,0.415-0.07c0.195-0.042,0.369-0.116,0.551-0.195 c0.282-0.121,0.527-0.314,0.748-0.525c0.275-0.261,0.421-0.599,0.53-0.957c0.097-0.314,0.138-0.656,0.114-0.983 C27.973,26.817,27.965,26.756,27.958,26.693z M15.375,3.768c0.449-0.004,0.9-0.002,1.351,0.002c0.322,0.002,0.644,0.006,0.966,0.004 c0.385-0.001,0.77,0.01,1.154,0.021c-0.028,0.789-0.017,1.581-0.015,2.372c0,0.754-0.009,1.51,0.01,2.264 c0.019,0.716,0.047,1.434,0.1,2.15c0.019,0.259,0.042,0.521,0.062,0.782c-0.342,0.013-0.685,0.025-1.027,0.039 c-0.572,0.021-1.146,0.025-1.718,0.068c-1.152,0.088-2.305,0.091-3.46,0.077c-0.036-0.807-0.057-1.615-0.065-2.424 c0.384-0.011,0.768-0.021,1.152-0.032c0.424-0.013,0.781-0.345,0.781-0.781c0-0.42-0.352-0.781-0.774-0.781 c-0.002,0-0.004,0-0.007,0c-0.389,0.004-0.779,0.008-1.168,0.011c-0.002-0.539,0.001-1.077-0.023-1.615 c-0.032-0.719-0.05-1.437-0.076-2.154C13.537,3.779,14.456,3.778,15.375,3.768z M26.457,27.054c-0.021,0.106-0.049,0.21-0.085,0.312 c-0.036,0.076-0.077,0.15-0.122,0.221c-0.054,0.056-0.112,0.108-0.172,0.159c-0.078,0.053-0.159,0.1-0.243,0.141 c-0.225,0.079-0.462,0.123-0.698,0.158c-0.307,0.032-0.615,0.033-0.922,0.049c-0.311,0.015-0.62,0.043-0.928,0.059 c-0.771,0.034-1.535,0.121-2.306,0.154c-0.758,0.032-1.519,0.034-2.279,0.061c-0.803,0.028-1.608,0.028-2.412,0.019 c-0.377-0.004-0.754-0.002-1.131-0.011c-0.366-0.008-0.729-0.034-1.095-0.059c-0.779-0.049-1.557-0.042-2.338-0.03 c-0.799,0.011-1.599,0.04-2.398,0.057c-0.798,0.017-1.591,0.055-2.389,0.055c-0.263,0.002-0.525-0.011-0.786-0.034 c-0.09-0.015-0.179-0.033-0.266-0.059c-0.03-0.015-0.059-0.032-0.087-0.049c-0.01-0.01-0.021-0.02-0.031-0.03 c-0.011-0.018-0.022-0.036-0.032-0.054c-0.005-0.17,0.01-0.342,0.017-0.511c0.005-0.097-0.021-0.188-0.051-0.275 c0.126-0.329,0.26-0.655,0.383-0.984c0.13-0.346,0.26-0.691,0.401-1.033c0.134-0.304,0.277-0.606,0.412-0.91 c0.007-0.015,0.013-0.031,0.02-0.046c0.333,0.005,0.668,0.002,1-0.004c0.582-0.008,1.165-0.017,1.749,0.021 c0.404,0.027,0.741-0.356,0.741-0.741c0-0.411-0.337-0.731-0.741-0.741c-0.692-0.016-1.384-0.045-2.076-0.07 c0.233-0.516,0.471-1.031,0.707-1.547c0.116-0.252,0.241-0.499,0.365-0.746c0.093,0.037,0.192,0.061,0.296,0.058 c0.36-0.008,0.722-0.021,1.082-0.04c0.258-0.013,0.523-0.049,0.782-0.032c0.436,0.03,0.801-0.386,0.801-0.801 c0-0.458-0.366-0.777-0.801-0.803c-0.023-0.002-0.045-0.002-0.068-0.002c-0.083,0-0.165,0.009-0.249,0.014 c-0.15,0.006-0.301,0.006-0.451,0.008c-0.209,0.002-0.419,0.003-0.628,0.004c0.099-0.22,0.198-0.441,0.301-0.66 c0.157-0.33,0.32-0.654,0.468-0.987c0.078-0.177,0.155-0.354,0.232-0.532c0.057,0.012,0.111,0.034,0.171,0.031 c0.754-0.044,1.506-0.097,2.262-0.14c0.419-0.023,0.771-0.333,0.771-0.771c0-0.426-0.35-0.765-0.771-0.773 c-0.067-0.001-0.133-0.001-0.2-0.001c-0.495,0-0.991,0.026-1.486,0.054c0.052-0.101,0.095-0.206,0.15-0.305 c0.34-0.613,0.68-1.226,1.023-1.838c0.055,0.013,0.107,0.034,0.166,0.034c1.25,0.002,2.497-0.082,3.745-0.146 c0.572-0.028,1.146-0.036,1.718-0.049c0.246-0.006,0.494-0.002,0.741,0c0.059,0.002,0.119,0.002,0.18,0.002 c0.034,0,0.069,0.003,0.103,0.003c0,0.14,0.021,0.28,0.091,0.41c0.383,0.71,0.799,1.404,1.203,2.101 c0.385,0.669,0.763,1.338,1.122,2.021c0.356,0.676,0.709,1.355,1.097,2.012c0.189,0.318,0.4,0.623,0.584,0.945 c0.188,0.324,0.358,0.657,0.53,0.991c0.466,0.89,0.949,1.77,1.47,2.631c0.241,0.398,0.468,0.803,0.703,1.205 c0.21,0.356,0.441,0.705,0.629,1.072c0.021,0.042,0.058,0.068,0.088,0.103c-0.04,0.091-0.062,0.19-0.059,0.295 C26.462,26.814,26.465,26.934,26.457,27.054z M24.139,25.03c0.191,0.358,0.093,0.807-0.267,1.017 c-0.172,0.1-0.381,0.129-0.572,0.076c-0.172-0.047-0.368-0.174-0.445-0.341c-0.481-1.029-1.029-2.027-1.555-3.031 c-0.286-0.546-0.557-1.099-0.852-1.641c-0.313-0.576-0.61-1.157-0.894-1.747c-0.093-0.193-0.136-0.383-0.078-0.593 c0.053-0.193,0.182-0.36,0.354-0.46c0.117-0.069,0.253-0.105,0.389-0.105c0.069,0,0.137,0.009,0.204,0.027 c0.178,0.049,0.379,0.182,0.458,0.354c0.28,0.593,0.557,1.186,0.851,1.771c0.277,0.551,0.54,1.11,0.832,1.654 c0.28,0.521,0.57,1.038,0.839,1.565c0.131,0.26,0.26,0.519,0.396,0.773C23.917,24.575,24.02,24.807,24.139,25.03z'%3E%3C/path%3E%3C/g%3E%3C/svg%3E"); } + +/* remark-highlight-code-lines */ + +.code-line.inserted { + background-color: var(--color-inserted-line); /* inserted code-line (+) */ +} + +.code-line.deleted { + background-color: var(--color-deleted-line); /* deleted code-line (-) */ +} + +.highlighted-code-line { + background-color: var(--color-highlighted-line); + border-left: 4px solid var(--color-highlighted-line-indicator); +} + +.numbered-code-line::before { + content: attr(data-line-number); + + margin-left: -8px; + margin-right: 16px; + width: 1rem; + color: var(--color-text-weak); + text-align: right; + + display: inline-block; +} From cdbe78619a8cc7c8454e91b079628b3f0eef6bf0 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Tue, 18 Mar 2025 15:06:47 -0700 Subject: [PATCH 733/780] Upgrade python dependencies --- requirements.txt | 52 +++++++++++++++++++----------------------------- 1 file changed, 20 insertions(+), 32 deletions(-) diff --git a/requirements.txt b/requirements.txt index 2663a587..5b414e3d 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,56 +1,44 @@ # -# This file is autogenerated by pip-compile with python 3.9 -# To update, run: +# This file is autogenerated by pip-compile with Python 3.13 +# by the following command: # -# pip-compile requirements.in +# pip-compile # -appdirs==1.4.4 - # via xml2rfc -certifi==2023.7.22 +certifi==2025.1.31 # via requests -charset-normalizer==2.1.0 +charset-normalizer==3.4.1 # via requests -configargparse==1.5.3 - # via xml2rfc -google-i18n-address==2.5.2 +configargparse==1.7 # via xml2rfc -html5lib==1.1 +google-i18n-address==3.1.1 # via xml2rfc -idna==3.3 +idna==3.10 # via requests intervaltree==3.1.0 # via xml2rfc -jinja2==2.11.3 +jinja2==3.1.6 # via xml2rfc -kitchen==1.2.6 +lxml==5.3.1 # via xml2rfc -lxml==4.9.1 - # via xml2rfc -markupsafe==2.0.1 - # via - # jinja2 - # xml2rfc -pycountry==22.3.5 +markupsafe==3.0.2 + # via jinja2 +platformdirs==4.3.6 # via xml2rfc -pyflakes==2.4.0 +pycountry==24.6.1 # via xml2rfc -pyyaml==6.0 +pyyaml==6.0.2 # via xml2rfc -requests==2.31.0 +requests==2.32.3 # via # google-i18n-address # xml2rfc -six==1.16.0 - # via - # html5lib - # xml2rfc sortedcontainers==2.4.0 # via intervaltree -urllib3==1.26.18 +urllib3==2.3.0 # via requests -webencodings==0.5.1 - # via html5lib -xml2rfc==3.12.4 +wcwidth==0.2.13 + # via xml2rfc +xml2rfc==3.28.0 # via -r requirements.in # The following packages are considered to be unsafe in a requirements file: From de8ed3004a4e39b54b8a9d2d8bc546c6c5521573 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 19 Jan 2025 20:18:03 +1300 Subject: [PATCH 734/780] keywords only exhibit the behaviors they're defined with --- specs/jsonschema-core.md | 58 +++++++++++++++++++++++----------- specs/jsonschema-validation.md | 17 +++++++++- 2 files changed, 56 insertions(+), 19 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 3154ae5e..74244c86 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -415,20 +415,37 @@ keywords MUST NOT begin with this prefix. Implementations MUST refuse to evaluate schemas which contain keywords which they do not know how to process or explicitly choose not to process. -## Keyword Behaviors +## Keyword Behaviors {#keyword-behaviors} -JSON Schema keywords fall into several general behavior categories. Assertions -validate that an instance satisfies constraints, producing a boolean result. -Annotations attach information that applications may use in any way they see -fit. Applicators apply subschemas to parts of the instance and combine their -results. +JSON Schema keywords may exhibit one or more behaviors. This specification +defines three such behaviors: + +- Assertions validate that an instance satisfies constraints, producing a + boolean result: `true` if the constraints are satisfied; `false` otherwise. +- Annotations attach information that applications may use in any way they see + fit. +- Applicators apply subschemas to parts of the instance and combine their + results. -Extension keywords SHOULD stay within these categories, keeping in mind that +Extension keywords SHOULD be defined using these behaviors, keeping in mind that annotations in particular are extremely flexible. Complex behavior is usually better delegated to applications on the basis of annotation data than implemented directly as schema keywords. However, extension keywords MAY define other behaviors for specialized purposes. +Keywords which are not defined to exhibit a particular behavior MUST NOT affect +that aspect of evalution. For example, a keyword which does not act as an +assertion MUST NOT affect the validation result. + +For the purposes of this document, an instance "validating against a keyword" +means that the keyword produces an assertion result of `true` if the instance +satisfies the given constraint; otherwise an assertion result of `false` is +produced. + + + Evaluating an instance against a schema involves processing all of the keywords in the schema against the appropriate locations within the instance. Typically, applicator keywords are processed until a schema object with no applicators (and @@ -569,11 +586,11 @@ the keyword's value. Alternatively, an applicator may refer to a schema elsewhere in the same schema document, or in a different one. The mechanism for identifying such referenced schemas is defined by the keyword. -Applicator keywords also define how subschema or referenced schema boolean -[assertion](#assertions) results are modified and/or combined to produce the -boolean result of the applicator. Applicators may apply any boolean logic -operation to the assertion results of subschemas, but MUST NOT introduce new -assertion conditions of their own. +Applicator keywords also behave as assertions by defining how subschema or +referenced schema boolean [assertion](#assertions) results are modified and/or +combined to produce the boolean result of the applicator. Applicators may apply +any boolean logic operation to the assertion results of subschemas, but MUST NOT +introduce new assertion conditions of their own. [Annotation](#annotations) results from subschemas are preserved in accordance with {{collect}} so that applications can decide how to interpret multiple @@ -1001,11 +1018,16 @@ identified schema. Its results are the results of the referenced schema.[^5] [^5]: Note that this definition of how the results are determined means that other keywords can appear alongside of `$ref` in the same schema object. +The value of the `$ref` keyword MUST be a string which is an IRI reference. The value of the `$ref` keyword MUST be a string which is an IRI reference. Resolved against the current IRI base, it produces the IRI of the schema to apply. This resolution is safe to perform on schema load, as the process of evaluating an instance cannot change how the reference resolves. +The resolved IRI produced by `$ref` is not necessarily a network locator, only +an identifier. A schema need not be downloadable from the address if it is a +network-addressable URL. Implementations which can access the network SHOULD +default to operating offline. The resolved IRI produced by `$ref` is not necessarily a network locator, only an identifier. A schema need not be downloadable from the address if it is a network-addressable URL. Implementations which can access the network SHOULD @@ -1476,8 +1498,8 @@ operators can contact the owner of a potentially misbehaving script. ## Keywords for Applying Subschemas -This section defines a set of keywords that enable schema combinations and -composition. +This section defines a set of applicator keywords that enable schema +combinations and composition. ### Keywords for Applying Subschemas in Place {#in-place} @@ -1737,8 +1759,8 @@ The value of this keyword MUST be a non-negative integer. This keyword modifies the behavior of `contains` within the same schema object, as described below in the section for that keyword. -Validation MUST always succeed against this keyword. The value of this keyword -is used as its annotation result. +This keyword produces no assertion result. The value of this keyword is used as +its annotation result. ##### `minContains` @@ -1747,8 +1769,8 @@ The value of this keyword MUST be a non-negative integer. This keyword modifies the behavior of `contains` within the same schema object, as described below in the section for that keyword. -Validation MUST always succeed against this keyword. The value of this keyword -is used as its annotation result. +This keyword produces no assertion result. The value of this keyword is used as +its annotation result. Per {{default-behaviors}}, omitted keywords MUST NOT produce annotation results. However, as described in {{contains}}, the absence of this keyword's annotation diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 3f43797c..d81bac1e 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -62,6 +62,21 @@ information. The {{format}} keyword is intended primarily as an annotation, but can optionally be used as an assertion. The {{content}} keywords are annotations for working with documents embedded as JSON strings. +## Keyword Behaviors + +The keywords defined by this document exhibit one or more behaviors as defined by +the [JSON Schema Core Specification](./jsonschema-core.md#keyword-behaviors). + +Keywords which are not defined to exhibit a particular behavior MUST NOT affect +that aspect of the evalution outcome. In particular, the keywords defined in +{{annotations}} produce no assertion result and therefore are not considered +during validation. + +For the purposes of this document, an instance "validating against a keyword" +means that the keyword produces an assertion result of `true` if the instance +satisfies the given constraint; otherwise an assertion result of `false` is +produced. + ## Interoperability Considerations ### Validation of String Instances @@ -642,7 +657,7 @@ structures: first the header, and then the payload. Since the JWT media type ensures that the JWT can be represented in a JSON string, there is no need for further encoding or decoding. -## Keywords for Basic Meta-Data Annotations +## Keywords for Basic Meta-Data Annotations {#annotations} These general-purpose annotation keywords provide commonly used information for documentation and user interface display purposes. They are not intended to form From 2058d3ef64d39b293d5bb1b770f45b94a7fc6e9b Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 2 Feb 2025 13:29:19 +1300 Subject: [PATCH 735/780] Update specs/jsonschema-core.md Co-authored-by: Jason Desrosiers --- specs/jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 74244c86..070c27fe 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -434,7 +434,7 @@ implemented directly as schema keywords. However, extension keywords MAY define other behaviors for specialized purposes. Keywords which are not defined to exhibit a particular behavior MUST NOT affect -that aspect of evalution. For example, a keyword which does not act as an +that aspect of evaluation. For example, a keyword which does not act as an assertion MUST NOT affect the validation result. For the purposes of this document, an instance "validating against a keyword" From a695c40d893a64724ef17dcfa2726203bb2be5f8 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 2 Feb 2025 13:30:29 +1300 Subject: [PATCH 736/780] Apply suggestions from code review Co-authored-by: Jason Desrosiers --- specs/jsonschema-core.md | 2 +- specs/jsonschema-validation.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 070c27fe..d35bf66b 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -442,7 +442,7 @@ means that the keyword produces an assertion result of `true` if the instance satisfies the given constraint; otherwise an assertion result of `false` is produced. - diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index d81bac1e..e5a29105 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -68,7 +68,7 @@ The keywords defined by this document exhibit one or more behaviors as defined b the [JSON Schema Core Specification](./jsonschema-core.md#keyword-behaviors). Keywords which are not defined to exhibit a particular behavior MUST NOT affect -that aspect of the evalution outcome. In particular, the keywords defined in +that aspect of the evaluation outcome. In particular, the keywords defined in {{annotations}} produce no assertion result and therefore are not considered during validation. From 1a7a34af7c2f8607bef67bc0569494e06dfa9753 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 12 Apr 2025 13:09:47 +1200 Subject: [PATCH 737/780] added some notes to add context --- specs/jsonschema-core.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index d35bf66b..110cf326 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -418,7 +418,7 @@ they do not know how to process or explicitly choose not to process. ## Keyword Behaviors {#keyword-behaviors} JSON Schema keywords may exhibit one or more behaviors. This specification -defines three such behaviors: +defines three such behaviors[^7]: - Assertions validate that an instance satisfies constraints, producing a boolean result: `true` if the constraints are satisfied; `false` otherwise. @@ -427,6 +427,12 @@ defines three such behaviors: - Applicators apply subschemas to parts of the instance and combine their results. +[^7]: This specification also defines several operational directive keywords, +such as `$id` and `$schema`. As such, these keywords do not exhibit these +behaviors. However, it is recommended that extensions avoid defining additional +directive keywords as they could interfere with schema processing and produce +unexpected or undesirable results. + Extension keywords SHOULD be defined using these behaviors, keeping in mind that annotations in particular are extremely flexible. Complex behavior is usually better delegated to applications on the basis of annotation data than @@ -589,8 +595,14 @@ identifying such referenced schemas is defined by the keyword. Applicator keywords also behave as assertions by defining how subschema or referenced schema boolean [assertion](#assertions) results are modified and/or combined to produce the boolean result of the applicator. Applicators may apply -any boolean logic operation to the assertion results of subschemas, but MUST NOT -introduce new assertion conditions of their own. +any boolean logic operation to the assertion results of subschemas, but SHOULD +NOT introduce new assertion conditions of their own.[^2] + +[^2]: It is recommended that keywords have a single resposibility. An example of +this in action is the separation between `properties`, which verifies object +property values have the right data _if_ they exist, and `required`, which +verifies that object properties exist. Separating these concerns allows for more +reusable components. [Annotation](#annotations) results from subschemas are preserved in accordance with {{collect}} so that applications can decide how to interpret multiple From d5914b2e0619419658cf4b273e4090ef324f2125 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Mon, 24 Feb 2025 06:53:34 +1300 Subject: [PATCH 738/780] initial scopes updates --- specs/jsonschema-core.md | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 3154ae5e..9b9004de 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -450,21 +450,31 @@ further change the assertion result. While most JSON Schema keywords can be evaluated on their own, or at most need to take into account the values or results of adjacent keywords in the same -schema object, a few have more complex behavior. +schema object, a few have more complex behavior. This behavior is generally +governed by the scope of the keyword. + +This specification defines two such scopes: lexical and dynamic. + +#### Lexical Scope The lexical scope of a keyword is determined by the nested JSON data structure of objects and arrays. The largest such scope is an entire schema document. The smallest scope is a single schema object with no subschemas. -Keywords MAY be defined with a partial value, such as a IRI reference, which -must be resolved against another value, such as another IRI reference or a full -IRI, which is found through the lexical structure of the JSON document. The -`$id`, `$ref`, and `$dynamicRef` core keywords, and the "base" JSON Hyper-Schema -keyword, are examples of this sort of behavior. +Keywords MAY be defined with a partial value which must be resolved against +another value found within the lexical structure of the JSON document. The +`$id`, `$schema`, and `$ref` core keywords, and the `base` JSON Hyper-Schema +keyword, are some such keywords. For example, an `$id` keyword found in an +embedded schema resource may have a value that is a relative IRI. This value +must be resolved against another `$id` keyword found in an ancestor subschema, +or the root schema, to produce an absolute IRI which fully identifies that +embedded schema resource. Note that some keywords, such as `$schema`, apply to the lexical scope of the entire schema resource, and therefore MUST only appear in a schema resource's -root schema. +root object. + +#### Dynamic Scope Other keywords may take into account the dynamic scope that exists during the evaluation of a schema, typically together with an instance document. The @@ -894,8 +904,10 @@ If this IRI identifies a retrievable resource, that resource SHOULD be of media type `application/schema+json`. The `$schema` keyword SHOULD be used in the document root schema object, and MAY -be used in the root schema objects of embedded schema resources. When the -keyword appears in a non-resource root schema object, the behavior is undefined. +be used in the root schema objects of embedded schema resources. This keyword +MUST NOT appear in a subschema that is not also the root object of a schema +resource (see {{id-keyword}} for more information regarding defining embedded +schema resources.) Values for this property are defined elsewhere in this and other documents, and by other parties. @@ -917,8 +929,9 @@ to establish a base IRI in order to resolve the reference. #### The `$id` Keyword {#id-keyword} An `$id` keyword in a schema or subschema identifies that schema or subschema as -a distinct schema resource. The value for this keyword MUST be a string, and -MUST represent a valid IRI reference without a fragment. +a distinct schema resource and defines a new lexical scope. The value for this +keyword MUST be a string, and MUST represent a valid IRI reference without a +fragment. When the value of this keyword is resolved against the current base IRI, the resulting absolute IRI then serves as the identifier for the schema resource and From 9e8bf380128d74a36d4f62752681cba1b5bff990 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 25 Feb 2025 10:55:49 +1300 Subject: [PATCH 739/780] tweaks for both scope types --- specs/jsonschema-core.md | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 9b9004de..cfd20aee 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -458,8 +458,9 @@ This specification defines two such scopes: lexical and dynamic. #### Lexical Scope The lexical scope of a keyword is determined by the nested JSON data structure -of objects and arrays. The largest such scope is an entire schema document. The -smallest scope is a single schema object with no subschemas. +of objects and arrays. The smallest such scope is a single schema object with no +subschemas. The largest scope is an entire schema document, recursively +including all of its subschemas. Keywords MAY be defined with a partial value which must be resolved against another value found within the lexical structure of the JSON document. The @@ -476,12 +477,13 @@ root object. #### Dynamic Scope -Other keywords may take into account the dynamic scope that exists during the -evaluation of a schema, typically together with an instance document. The -outermost dynamic scope is the schema object at which processing begins, even if -it is not a schema resource root. The path from this root schema to any -particular keyword (that includes any `$ref` and `$dynamicRef` keywords that may -have been resolved) is considered the keyword's "evaluation path." +The dynamic scope is the ordered collection of schema objects navigated during +evaluation, starting at the root and ending at the subschema under evaluation. +The outermost dynamic scope is the schema object at which processing begins, +even if it is not a schema resource root. The path that evaluation takes, +starting from this root schema to any particular subschema (including any `$ref` +and `$dynamicRef` keywords that may have been resolved), is considered the +"evaluation path". Lexical and dynamic scopes align until a reference keyword is encountered. While following the reference keyword moves processing from one lexical scope into a @@ -489,7 +491,7 @@ different one, from the perspective of dynamic scope, following a reference is no different from descending into a subschema present as a value. A keyword on the far side of that reference that resolves information through the dynamic scope will consider the originating side of the reference to be their dynamic -parent, rather than examining the local lexically enclosing parent. +parent rather than examining the local lexically enclosing parent. The concept of dynamic scope is primarily used with `$dynamicRef` and `$dynamicAnchor`, and should be considered an advanced feature and used with @@ -929,9 +931,9 @@ to establish a base IRI in order to resolve the reference. #### The `$id` Keyword {#id-keyword} An `$id` keyword in a schema or subschema identifies that schema or subschema as -a distinct schema resource and defines a new lexical scope. The value for this -keyword MUST be a string, and MUST represent a valid IRI reference without a -fragment. +a distinct schema resource and applies to the entire lexical scope of that +schema resource. The value for this keyword MUST be a string, and MUST represent +a valid IRI reference without a fragment. When the value of this keyword is resolved against the current base IRI, the resulting absolute IRI then serves as the identifier for the schema resource and From 767debd285cb426b7f2519030593f2601d9a3afc Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 12 Apr 2025 13:48:23 +1200 Subject: [PATCH 740/780] minor tweaks to wording --- specs/jsonschema-core.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index cfd20aee..31475b12 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -486,11 +486,11 @@ and `$dynamicRef` keywords that may have been resolved), is considered the "evaluation path". Lexical and dynamic scopes align until a reference keyword is encountered. While -following the reference keyword moves processing from one lexical scope into a +following the reference moves processing from one lexical scope into a different one, from the perspective of dynamic scope, following a reference is no different from descending into a subschema present as a value. A keyword on the far side of that reference that resolves information through the dynamic -scope will consider the originating side of the reference to be their dynamic +scope will consider the originating side of the reference to be its dynamic parent rather than examining the local lexically enclosing parent. The concept of dynamic scope is primarily used with `$dynamicRef` and From e49690476d994f0f618b538a5f63db08345161f0 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 16 Apr 2025 18:08:44 +1200 Subject: [PATCH 741/780] update dynamic scope to be defined by resources --- specs/jsonschema-core.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 31475b12..183f1466 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -477,27 +477,27 @@ root object. #### Dynamic Scope -The dynamic scope is the ordered collection of schema objects navigated during -evaluation, starting at the root and ending at the subschema under evaluation. -The outermost dynamic scope is the schema object at which processing begins, -even if it is not a schema resource root. The path that evaluation takes, -starting from this root schema to any particular subschema (including any `$ref` +The dynamic scope is the ordered collection of schema resources navigated during +evaluation, starting at the root and ending at the schema resource which +contains the subschema under evaluation. The outermost dynamic scope is the +schema resource at which processing begins. The path that evaluation takes, +starting from the subschema to any particular subschema (including any `$ref` and `$dynamicRef` keywords that may have been resolved), is considered the "evaluation path". Lexical and dynamic scopes align until a reference keyword is encountered. While -following the reference moves processing from one lexical scope into a -different one, from the perspective of dynamic scope, following a reference is -no different from descending into a subschema present as a value. A keyword on -the far side of that reference that resolves information through the dynamic -scope will consider the originating side of the reference to be its dynamic -parent rather than examining the local lexically enclosing parent. +following the reference moves processing from one lexical scope into a different +one, from the perspective of dynamic scope, following a reference is no +different from descending into a subschema. A keyword on the far side of the +reference that resolves information through the dynamic scope will consider the +originating side of the reference to be its dynamic parent rather than examining +the local lexically enclosing parent. The concept of dynamic scope is primarily used with `$dynamicRef` and `$dynamicAnchor`, and should be considered an advanced feature and used with caution when defining additional keywords. It also appears when reporting errors and collected annotations, as it may be possible to revisit the same lexical -scope repeatedly with different dynamic scopes. In such cases, it is important +scope repeatedly with different dynamic scopes. For this reason, it is important to inform the user of the evaluation path that produced the error or annotation. ### Keyword Interactions From 50e9aca23cdfae3146ab2cbe41345a32102e9ea8 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 16 Apr 2025 20:37:14 +1200 Subject: [PATCH 742/780] be more specific on annotation targets Co-authored-by: Jason Desrosiers --- specs/jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 110cf326..a4f9c8f6 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -422,7 +422,7 @@ defines three such behaviors[^7]: - Assertions validate that an instance satisfies constraints, producing a boolean result: `true` if the constraints are satisfied; `false` otherwise. -- Annotations attach information that applications may use in any way they see +- Annotations attach information to instance locations that applications may use in any way they see fit. - Applicators apply subschemas to parts of the instance and combine their results. From b272d131e35af3d9436664b568f0c4e0e23e886c Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 15 Jan 2025 21:44:33 +1300 Subject: [PATCH 743/780] add format registry file --- specs/format-registry.json | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 specs/format-registry.json diff --git a/specs/format-registry.json b/specs/format-registry.json new file mode 100644 index 00000000..5dd9950d --- /dev/null +++ b/specs/format-registry.json @@ -0,0 +1,37 @@ +{ + "int32": { + "definingBody": "OpenAPI", + "definition": "https://spec.openapis.org/oas/latest.html#data-type-format", + "types": ["number"], + "examples": [ -2147483648, -1, 0, 1, 2147483647 ], + "supportedBy": [] + }, + "int64": { + "definingBody": "OpenAPI", + "definition": "https://spec.openapis.org/oas/latest.html#data-type-format", + "types": ["number"], + "examples": [ -9223372036854775808, -1, 0, 1, 9223372036854775807 ], + "supportedBy": [] + }, + "float": { + "definingBody": "OpenAPI", + "definition": "https://spec.openapis.org/oas/latest.html#data-type-format", + "types": ["number"], + "examples": [ -3.40282347e+38, -1, -1.17549435e-38, 0, 1.17549435e-38, 1, 3.40282347e+38 ], + "supportedBy": [] + }, + "double": { + "definingBody": "OpenAPI", + "definition": "https://spec.openapis.org/oas/latest.html#data-type-format", + "types": ["number"], + "examples": [ -1.7976931348623157e+308, -1, -4.9406564584124654e-324, 0, 4.9406564584124654e-324, 1, 1.7976931348623157e+308 ], + "supportedBy": [] + }, + "password": { + "definingBody": "OpenAPI", + "definition": "https://spec.openapis.org/oas/latest.html#data-type-format", + "types": ["string"], + "examples": ["can be any string", "this format is just an annotation"], + "supportedBy": [] + } +} \ No newline at end of file From f0983422b42c27b0bda8823bda15ca265a3f12ff Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 15 Jan 2025 21:59:37 +1300 Subject: [PATCH 744/780] add section for format registry; add requirements to support those formats as well --- specs/jsonschema-validation.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 3f43797c..4faa8338 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -334,10 +334,10 @@ an annotation. Implementations: -- SHOULD provide validation for each format attribute defined in this - document; -- MAY support format values not defined in this document, but such support MUST - be configurable and disabled by default; +- SHOULD provide validation for each format attribute defined in this document + and listed in the {{format-registry}}; +- MAY support format values not defined in this document or listed in the + registry, but such support MUST be configurable and disabled by default; - SHOULD use a common parsing library or a well-known regular expression for each format; - SHOULD clearly document how and to what degree each format attribute is @@ -348,7 +348,13 @@ syntactic checking; implementations SHOULD NOT attempt to send an email, connect to a URL, or otherwise check the existence of an entity identified by a format instance. -#### Custom format values +#### Format Registry {#format-registry} + +In addition to the formats defined by this document, JSON Schema also maintains a registry of formats defined by other specifications and organizations. As of the publication of this document, the format registry can be found at https://github.com/json-schema-org/json-schema-spec/blob/main/specs/format-registry.json. + +Implementations SHOULD support the formats listed in this registry as if they were defined by this document. + +#### Custom `format` Values Implementations MAY support custom format values. Save for agreement between parties, schema authors SHALL NOT expect a peer implementation to support such From ae5759129b0bbaeeb11f193fdb066df1826c6b7d Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 15 Jan 2025 22:01:49 +1300 Subject: [PATCH 745/780] permalink oas urls --- specs/format-registry.json | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/specs/format-registry.json b/specs/format-registry.json index 5dd9950d..e8b3c5a1 100644 --- a/specs/format-registry.json +++ b/specs/format-registry.json @@ -1,35 +1,35 @@ { "int32": { "definingBody": "OpenAPI", - "definition": "https://spec.openapis.org/oas/latest.html#data-type-format", + "definition": "https://spec.openapis.org/oas/v3.1.1.html#data-type-format", "types": ["number"], "examples": [ -2147483648, -1, 0, 1, 2147483647 ], "supportedBy": [] }, "int64": { "definingBody": "OpenAPI", - "definition": "https://spec.openapis.org/oas/latest.html#data-type-format", + "definition": "https://spec.openapis.org/oas/v3.1.1.html#data-type-format", "types": ["number"], "examples": [ -9223372036854775808, -1, 0, 1, 9223372036854775807 ], "supportedBy": [] }, "float": { "definingBody": "OpenAPI", - "definition": "https://spec.openapis.org/oas/latest.html#data-type-format", + "definition": "https://spec.openapis.org/oas/v3.1.1.html#data-type-format", "types": ["number"], "examples": [ -3.40282347e+38, -1, -1.17549435e-38, 0, 1.17549435e-38, 1, 3.40282347e+38 ], "supportedBy": [] }, "double": { "definingBody": "OpenAPI", - "definition": "https://spec.openapis.org/oas/latest.html#data-type-format", + "definition": "https://spec.openapis.org/oas/v3.1.1.html#data-type-format", "types": ["number"], "examples": [ -1.7976931348623157e+308, -1, -4.9406564584124654e-324, 0, 4.9406564584124654e-324, 1, 1.7976931348623157e+308 ], "supportedBy": [] }, "password": { "definingBody": "OpenAPI", - "definition": "https://spec.openapis.org/oas/latest.html#data-type-format", + "definition": "https://spec.openapis.org/oas/v3.1.1.html#data-type-format", "types": ["string"], "examples": ["can be any string", "this format is just an annotation"], "supportedBy": [] From 59619ad253d365b8db4c5b78545f321b4a21d0b3 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 31 Jan 2025 20:50:42 +1300 Subject: [PATCH 746/780] move registry into dedicated folder to potentially support multiple registries in the future --- specs/{format-registry.json => registries/format.json} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename specs/{format-registry.json => registries/format.json} (100%) diff --git a/specs/format-registry.json b/specs/registries/format.json similarity index 100% rename from specs/format-registry.json rename to specs/registries/format.json From 38c8e6a38507b15498d9938f89cdc9483277dcf9 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 31 Jan 2025 22:38:42 +1300 Subject: [PATCH 747/780] import all formats from openapi's registry --- specs/registries/format.json | 360 +++++++++++++++++++++++++++++++++-- 1 file changed, 349 insertions(+), 11 deletions(-) diff --git a/specs/registries/format.json b/specs/registries/format.json index e8b3c5a1..d085096c 100644 --- a/specs/registries/format.json +++ b/specs/registries/format.json @@ -1,37 +1,375 @@ { + "base64url": { + "description": "Binary data encoded as a url-safe string as defined in RFC4648", + "types": ["string"], + "examples": ["U3dhZ2dlciByb2Nrcw"], + "deprecated": true, + "supportedBy": [] + }, + "binary": { + "description": "Any sequence of octets", + "definingBody": "OpenAPI", + "definition": "https://spec.openapis.org/oas/v3.0.3.html#data-types", + "types": ["string"], + "examples": ["binary data"], + "deprecated": true, + "supportedBy": [] + }, + "byte": { + "description": "Base64 encoded data as defined in RFC4648", + "definingBody": "OpenAPI", + "definition": "https://spec.openapis.org/oas/v3.0.3.html#data-types", + "types": ["string"], + "examples": ["U3dhZ2dlciByb2Nrcw=="], + "deprecated": true, + "supportedBy": [] + }, + "char": { + "description": "A single character", + "types": ["string"], + "examples": ["a"], + "deprecated": false, + "supportedBy": [] + }, + "commonmark": { + "description": "Commonmark-formatted text", + "definingBody": "OpenAPI", + "definition": "https://spec.openapis.org/oas/latest.html#data-types", + "types": ["string"], + "examples": ["# Heading\n\nSome **bold** text."], + "deprecated": false, + "supportedBy": [] + }, + "date": { + "description": "Date as defined by full-date - RFC3339", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-dates-times-and-duration", + "types": ["string"], + "examples": ["2017-07-21"], + "deprecated": false, + "supportedBy": [] + }, + "date-time": { + "description": "Date and time as defined by date-time - RFC3339", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-dates-times-and-duration", + "types": ["string"], + "examples": ["2017-07-21T17:32:28Z"], + "deprecated": false, + "supportedBy": [] + }, + "decimal": { + "description": "A fixed point decimal number of unspecified precision and range", + "types": ["string", "number"], + "examples": ["123.45"], + "deprecated": false, + "supportedBy": [] + }, + "decimal128": { + "description": "A decimal floating-point number with 34 significant decimal digits", + "types": ["string", "number"], + "examples": ["123.4567890123456789012345678901234"], + "deprecated": false, + "supportedBy": [] + }, + "double": { + "description": "Double precision floating point number", + "definingBody": "OpenAPI", + "definition": "https://spec.openapis.org/oas/latest.html#data-types", + "types": ["number"], + "examples": [-1.7976931348623157e+308, -1, -4.9406564584124654e-324, 0, 4.9406564584124654e-324, 1, 1.7976931348623157e+308], + "deprecated": false, + "supportedBy": [] + }, + "double-int": { + "description": "An integer that can be stored in an IEEE 754 double-precision number without loss of precision", + "types": ["number"], + "examples": [9007199254740991], + "deprecated": false, + "supportedBy": [] + }, + "duration": { + "description": "Duration as defined by duration - RFC3339", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-dates-times-and-duration", + "types": ["string"], + "examples": ["P3Y6M4DT12H30M5S"], + "deprecated": false, + "supportedBy": [] + }, + "email": { + "description": "An email address as defined as Mailbox in RFC5321", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-email-addresses", + "types": ["string"], + "examples": ["user@example.com"], + "deprecated": false, + "supportedBy": [] + }, + "float": { + "description": "Single precision floating point number", + "definingBody": "OpenAPI", + "definition": "https://spec.openapis.org/oas/latest.html#data-types", + "types": ["number"], + "examples": [-3.40282347e+38, -1, -1.17549435e-38, 0, 1.17549435e-38, 1, 3.40282347e+38], + "deprecated": false, + "supportedBy": [] + }, + "hostname": { + "description": "A host name as defined by RFC1123", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-hostnames", + "types": ["string"], + "examples": ["example.com"], + "deprecated": false, + "supportedBy": [] + }, + "html": { + "description": "HTML-formatted text", + "definingBody": "OpenAPI", + "definition": "https://spec.openapis.org/oas/latest.html#data-types", + "types": ["string"], + "examples": ["

This is a paragraph.

"], + "deprecated": false, + "supportedBy": [] + }, + "http-date": { + "description": "Date and time as defined by HTTP-date - RFC7231", + "types": ["string"], + "examples": ["Sun, 06 Nov 1994 08:49:37 GMT"], + "deprecated": false, + "supportedBy": [] + }, + "idn-email": { + "description": "An email address as defined as Mailbox in RFC6531", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-email-addresses", + "types": ["string"], + "examples": ["user@exämple.com"], + "deprecated": false, + "supportedBy": [] + }, + "idn-hostname": { + "description": "An internationalized host name as defined by RFC5890", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-hostnames", + "types": ["string"], + "examples": ["exämple.com"], + "deprecated": false, + "supportedBy": [] + }, + "int16": { + "description": "Signed 16-bit integer", + "types": ["number"], + "examples": [-32768, -1, 0, 1, 32767], + "deprecated": false, + "supportedBy": [] + }, "int32": { + "description": "Signed 32-bit integer", "definingBody": "OpenAPI", "definition": "https://spec.openapis.org/oas/v3.1.1.html#data-type-format", "types": ["number"], - "examples": [ -2147483648, -1, 0, 1, 2147483647 ], + "examples": [-2147483648, -1, 0, 1, 2147483647], + "deprecated": false, "supportedBy": [] }, "int64": { + "description": "Signed 64-bit integer", "definingBody": "OpenAPI", "definition": "https://spec.openapis.org/oas/v3.1.1.html#data-type-format", "types": ["number"], - "examples": [ -9223372036854775808, -1, 0, 1, 9223372036854775807 ], + "examples": [-9223372036854775808, -1, 0, 1, 9223372036854775807], + "deprecated": false, "supportedBy": [] }, - "float": { + "int8": { + "description": "Signed 8-bit integer", "definingBody": "OpenAPI", - "definition": "https://spec.openapis.org/oas/v3.1.1.html#data-type-format", + "definition": "https://spec.openapis.org/oas/latest.html#data-types", "types": ["number"], - "examples": [ -3.40282347e+38, -1, -1.17549435e-38, 0, 1.17549435e-38, 1, 3.40282347e+38 ], + "examples": [-128, -1, 0, 1, 127], + "deprecated": false, "supportedBy": [] }, - "double": { + "ipv4": { + "description": "An IPv4 address as defined as dotted-quad by RFC2673", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-ip-addresses", + "types": ["string"], + "examples": ["192.168.0.1"], + "deprecated": false, + "supportedBy": [] + }, + "ipv6": { + "description": "An IPv6 address as defined by RFC4673", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-ip-addresses", + "types": ["string"], + "examples": ["2001:0db8:85a3:0000:0000:8a2e:0370:7334"], + "deprecated": false, + "supportedBy": [] + }, + "iri": { + "description": "An Internationalized Resource Identifier as defined in RFC3987", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-resource-identifiers", + "types": ["string"], + "examples": ["https://example.com/rosé"], + "deprecated": false, + "supportedBy": [] + }, + "iri-reference": { + "description": "An Internationalized Resource Identifier as defined in RFC3987", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-resource-identifiers", + "types": ["string"], + "examples": ["../resource.json"], + "deprecated": false, + "supportedBy": [] + }, + "json-pointer": { + "description": "A JSON string representation of a JSON Pointer as defined in RFC6901", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-json-pointers", + "types": ["string"], + "examples": ["/foo/bar"], + "deprecated": false, + "supportedBy": [] + }, + "media-range": { + "description": "A media type as defined by the media-range ABNF production in RFC9110.", "definingBody": "OpenAPI", - "definition": "https://spec.openapis.org/oas/v3.1.1.html#data-type-format", + "definition": "https://www.rfc-editor.org/rfc/rfc9110#field.accept", + "types": ["string"], + "examples": ["text/html"], + "deprecated": false, + "supportedBy": [] + }, + "regex": { + "description": "A regular expression as defined in ECMA-262", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-regex", + "types": ["string"], + "examples": ["^[a-zA-Z0-9]+$"], + "deprecated": false, + "supportedBy": [] + }, + "relative-json-pointer": { + "description": "A JSON string representation of a relative JSON Pointer as defined in draft RFC 01", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-json-pointers", + "types": ["string"], + "examples": ["1/0"], + "deprecated": false, + "supportedBy": [] + }, + "sf-binary": { + "description": "Structured fields byte sequence as defined in RFC8941", + "definingBody": "RFC 8941", + "definition": "https://www.rfc-editor.org/rfc/rfc8941#name-byte-sequences", + "types": ["string"], + "examples": ["U3dhZ2dlciByb2Nrcw=="], + "deprecated": false, + "supportedBy": [] + }, + "sf-boolean": { + "description": "Structured fields boolean as defined in RFC8941", + "definingBody": "RFC 8941", + "definition": "https://www.rfc-editor.org/rfc/rfc8941#name-booleans", + "types": ["string"], + "examples": ["true", "false"], + "deprecated": false, + "supportedBy": [] + }, + "sf-decimal": { + "description": "Structured fields decimal as defined in RFC8941", + "definingBody": "RFC 8941", + "definition": "https://www.rfc-editor.org/rfc/rfc8941#name-decimals", + "types": ["number"], + "examples": ["123.45"], + "deprecated": false, + "supportedBy": [] + }, + "sf-integer": { + "description": "Structured fields integer as defined in RFC8941", + "definingBody": "RFC 8941", + "definition": "https://www.rfc-editor.org/rfc/rfc8941#name-integers", "types": ["number"], - "examples": [ -1.7976931348623157e+308, -1, -4.9406564584124654e-324, 0, 4.9406564584124654e-324, 1, 1.7976931348623157e+308 ], + "examples": [123], + "deprecated": false, + "supportedBy": [] + }, + "sf-string": { + "description": "Structured fields string as defined in RFC8941", + "definingBody": "RFC 8941", + "definition": "https://www.rfc-editor.org/rfc/rfc8941#name-strings", + "types": ["string"], + "examples": ["example"], + "deprecated": false, "supportedBy": [] }, - "password": { + "sf-token": { + "description": "Structured fields token as defined in RFC8941", + "definingBody": "RFC 8941", + "definition": "https://www.rfc-editor.org/rfc/rfc8941#name-tokens", + "types": ["string"], + "examples": ["token"], + "deprecated": false, + "supportedBy": [] + }, + "time": { + "description": "Time as defined by full-time - RFC3339", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-dates-times-and-duration", + "types": ["string"], + "examples": ["13:45:30"], + "deprecated": false, + "supportedBy": [] + }, + "uint8": { + "description": "Unsigned 8-bit integer", "definingBody": "OpenAPI", - "definition": "https://spec.openapis.org/oas/v3.1.1.html#data-type-format", + "definition": "https://spec.openapis.org/oas/latest.html#data-types", + "types": ["number"], + "examples": [0, 1, 255], + "deprecated": false, + "supportedBy": [] + }, + "uri": { + "description": "A Uniform Resource Identifier as defined in RFC3986", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-resource-identifiers", + "types": ["string"], + "examples": ["https://example.com"], + "deprecated": false, + "supportedBy": [] + }, + "uri-reference": { + "description": "A URI reference as defined in RFC3986", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-resource-identifiers", + "types": ["string"], + "examples": ["../resource.json"], + "deprecated": false, + "supportedBy": [] + }, + "uri-template": { + "description": "A URI Template as defined in RFC6570", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-uri-template", + "types": ["string"], + "examples": ["https://example.com/{id}"], + "deprecated": false, + "supportedBy": [] + }, + "uuid": { + "description": "A Universally Unique IDentifier as defined in RFC4122", + "definingBody": "JSON Schema", + "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-resource-identifiers", "types": ["string"], - "examples": ["can be any string", "this format is just an annotation"], + "examples": ["f81d4fae-7dec-11d0-a765-00a0c91e6bf6"], + "deprecated": false, "supportedBy": [] } } \ No newline at end of file From b860ef8aa5c191b8dfb37161087833e4184ebff0 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 31 Jan 2025 22:43:17 +1300 Subject: [PATCH 748/780] fix validation spec link to format registry file --- specs/jsonschema-validation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 4faa8338..b0ccef89 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -350,7 +350,7 @@ instance. #### Format Registry {#format-registry} -In addition to the formats defined by this document, JSON Schema also maintains a registry of formats defined by other specifications and organizations. As of the publication of this document, the format registry can be found at https://github.com/json-schema-org/json-schema-spec/blob/main/specs/format-registry.json. +In addition to the formats defined by this document, JSON Schema also maintains a registry of formats defined by other specifications and organizations. As of the publication of this document, the format registry can be found at . Implementations SHOULD support the formats listed in this registry as if they were defined by this document. From 177580f86a8931108fd62d62f7f327cba29ea025 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 12 Apr 2025 13:25:33 +1200 Subject: [PATCH 749/780] update examples for full-time --- specs/registries/format.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/registries/format.json b/specs/registries/format.json index d085096c..b1426b16 100644 --- a/specs/registries/format.json +++ b/specs/registries/format.json @@ -323,7 +323,7 @@ "definingBody": "JSON Schema", "definition": "https://json-schema.org/draft/2020-12/json-schema-validation.html#name-dates-times-and-duration", "types": ["string"], - "examples": ["13:45:30"], + "examples": ["13:45:30Z", "13:45:30+01:00"], "deprecated": false, "supportedBy": [] }, From 9484293c540c84a47f874a2e691429a40c92c40b Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 16 Apr 2025 20:47:41 +1200 Subject: [PATCH 750/780] wrap lines properly --- specs/jsonschema-validation.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index b0ccef89..83e14e3e 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -325,9 +325,9 @@ from previous iterations of this specification. Previously, `format` was an annotation-only keyword by default and implementations that supported assertion were required to offer some configuration that allowed users to explicitly enable assertion. Assertion is now a requirement in order to meet user -expectations. See [json-schema-org/json-schema-spec -#1520](https://github.com/json-schema-org/json-schema-spec/issues/1520) for -more. +expectations. See +[json-schema-org/json-schema-spec #1520](https://github.com/json-schema-org/json-schema-spec/issues/1520) +for more. In addition to the assertion behavior, this keyword also produces its value as an annotation. @@ -350,9 +350,13 @@ instance. #### Format Registry {#format-registry} -In addition to the formats defined by this document, JSON Schema also maintains a registry of formats defined by other specifications and organizations. As of the publication of this document, the format registry can be found at . +In addition to the formats defined by this document, JSON Schema also maintains +a registry of formats defined by other specifications and organizations. As of +the publication of this document, the format registry can be found at +. -Implementations SHOULD support the formats listed in this registry as if they were defined by this document. +Implementations SHOULD support the formats listed in this registry as if they +were defined by this document. #### Custom `format` Values From ae1edc7bb8f9f09446d011f2b0afc9e2c1cdb8c6 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 18 Apr 2025 15:19:31 +1200 Subject: [PATCH 751/780] update requirement level for registry formats; should document limitations --- specs/jsonschema-validation.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 83e14e3e..d8687b7c 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -334,14 +334,14 @@ an annotation. Implementations: -- SHOULD provide validation for each format attribute defined in this document - and listed in the {{format-registry}}; +- SHOULD provide validation for each format attribute defined in this document; +- are encouraged to provide validation for format attributes listed in the + {{format-registry}}; - MAY support format values not defined in this document or listed in the registry, but such support MUST be configurable and disabled by default; - SHOULD use a common parsing library or a well-known regular expression for each format; -- SHOULD clearly document how and to what degree each format attribute is - validated. +- SHOULD clearly document any limitations regarding format validation. The requirement for validation of format values in general is limited to syntactic checking; implementations SHOULD NOT attempt to send an email, connect From b48cf7129bbfa2240c2037ce00a61cee1357acb0 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 19 Apr 2025 16:33:18 +1200 Subject: [PATCH 752/780] revisit 'directive' behaviors text; add requirement about extensions redefining keywords --- specs/jsonschema-core.md | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index a4f9c8f6..9fe2be79 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -394,6 +394,18 @@ Additional schema keywords MAY be defined by any entity. Save for explicit agreement, schema authors SHALL NOT expect these additional keywords to be supported by implementations that do not explicitly document such support. +Extension keywords MUST NOT interfere with the operation of keywords defined by +this document or the companion JSON Schema Validation specificiation, and SHOULD +NOT interfere with the operation of keywords defined by other extension +documents.[^11] + +[^11]: JSON Schema currently does not have a namespacing mechanism, which would +allow multiple extensions to define the same keyword differently while also +giving the schema author the ability to declare which definition is intended. +Such a feature is planned for future releases. See the +[Vocabularies / Extensions project](https://github.com/orgs/json-schema-org/projects/28/views/2) +in GitHub for more information. + Implementations MAY provide the ability to register or load handlers for keywords that they do not support directly. The exact mechanism for registering and implementing such handlers is implementation-dependent. @@ -422,16 +434,15 @@ defines three such behaviors[^7]: - Assertions validate that an instance satisfies constraints, producing a boolean result: `true` if the constraints are satisfied; `false` otherwise. -- Annotations attach information to instance locations that applications may use in any way they see - fit. +- Annotations attach information to instance locations that applications may use + in any way they see fit. - Applicators apply subschemas to parts of the instance and combine their results. [^7]: This specification also defines several operational directive keywords, -such as `$id` and `$schema`. As such, these keywords do not exhibit these -behaviors. However, it is recommended that extensions avoid defining additional -directive keywords as they could interfere with schema processing and produce -unexpected or undesirable results. +such as `$id` and `$schema`, which do not exhibit these behaviors. Instead, +these keywords provide metadata that instruct implementations on how to +interpret and process the schema. Extension keywords SHOULD be defined using these behaviors, keeping in mind that annotations in particular are extremely flexible. Complex behavior is usually @@ -439,9 +450,7 @@ better delegated to applications on the basis of annotation data than implemented directly as schema keywords. However, extension keywords MAY define other behaviors for specialized purposes. -Keywords which are not defined to exhibit a particular behavior MUST NOT affect -that aspect of evaluation. For example, a keyword which does not act as an -assertion MUST NOT affect the validation result. +Implementations SHOULD NOT add unspecified behaviors to keywords. For the purposes of this document, an instance "validating against a keyword" means that the keyword produces an assertion result of `true` if the instance From 78ca35dede021e63f3b7df3ce3d502ce289ab736 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 23 Apr 2025 10:04:35 +1200 Subject: [PATCH 753/780] remove duplicate text Co-authored-by: Jason Desrosiers --- specs/jsonschema-core.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 9fe2be79..c9042461 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -1039,16 +1039,11 @@ identified schema. Its results are the results of the referenced schema.[^5] [^5]: Note that this definition of how the results are determined means that other keywords can appear alongside of `$ref` in the same schema object. -The value of the `$ref` keyword MUST be a string which is an IRI reference. The value of the `$ref` keyword MUST be a string which is an IRI reference. Resolved against the current IRI base, it produces the IRI of the schema to apply. This resolution is safe to perform on schema load, as the process of evaluating an instance cannot change how the reference resolves. -The resolved IRI produced by `$ref` is not necessarily a network locator, only -an identifier. A schema need not be downloadable from the address if it is a -network-addressable URL. Implementations which can access the network SHOULD -default to operating offline. The resolved IRI produced by `$ref` is not necessarily a network locator, only an identifier. A schema need not be downloadable from the address if it is a network-addressable URL. Implementations which can access the network SHOULD From 20fe3e129c97140bf26110f0b38ebb50e31490e0 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 26 Apr 2025 20:27:47 +1200 Subject: [PATCH 754/780] use behavior language Co-authored-by: Jason Desrosiers --- specs/jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index c9042461..77a4c2e2 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -1785,7 +1785,7 @@ The value of this keyword MUST be a non-negative integer. This keyword modifies the behavior of `contains` within the same schema object, as described below in the section for that keyword. -This keyword produces no assertion result. The value of this keyword is used as +This keyword has no assertion behavior. The value of this keyword is used as its annotation result. Per {{default-behaviors}}, omitted keywords MUST NOT produce annotation results. From 784ad8b25790db99cda76b61c7159c2f2e83debc Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 26 Apr 2025 20:30:32 +1200 Subject: [PATCH 755/780] Clean up applicator assertion language Co-authored-by: Ethan <133719+notEthan@users.noreply.github.com> --- specs/jsonschema-core.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 77a4c2e2..691ecdbd 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -601,9 +601,11 @@ the keyword's value. Alternatively, an applicator may refer to a schema elsewhere in the same schema document, or in a different one. The mechanism for identifying such referenced schemas is defined by the keyword. -Applicator keywords also behave as assertions by defining how subschema or -referenced schema boolean [assertion](#assertions) results are modified and/or -combined to produce the boolean result of the applicator. Applicators may apply +Applicator keywords also behave as assertions, using the assertion results of +each subschema or referenced schema of the keyword. These boolean results are +modified (e.g. the `not` keyword negates its subschema's assertion) and/or +combined (e.g. `allOf` takes the conjunction of its subschemas' assertions) +to produce the boolean result of the applicator. any boolean logic operation to the assertion results of subschemas, but SHOULD NOT introduce new assertion conditions of their own.[^2] From ced9c21a9d30432b5588cbd4a9e316d62348ba76 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 26 Apr 2025 21:04:02 +1200 Subject: [PATCH 756/780] clarify the relationship between resources and docs; clarify that external docs should specify their usage of json schema --- specs/jsonschema-core.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 3154ae5e..80110bc5 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -252,13 +252,13 @@ is identical to the primary resource. This can occur with the empty fragment, or when one schema resource is embedded in another. Any such IRIs with fragments are considered to be non-canonical. -The root schema is the schema that comprises the entire JSON document in -question. The root schema is always a schema resource, where the IRI is -determined as described in {{initial-base}}.[^1] +A root schema, which may comprise the entire JSON document, is the top-level +schema that is identified by the absolute IRI. The root schema is always a +schema resource, where the IRI is determined as described in {{initial-base}}. -[^1]: Note that documents that embed schemas in another format will not have a -root schema resource in this sense. Exactly how such usages fit with the JSON -Schema document and resource concepts will be clarified in a future draft. +Documents formats which embed JSON Schemas within them will not necessarily have +a single root schema in this sense. How root schemas are identified within such +documents SHOULD be defined by the specifications which govern them. Some keywords take schemas themselves, allowing JSON Schemas to be nested: From 3445c0dea29e0779b8156c82ad3378525b6609e6 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 27 Apr 2025 07:20:07 +1200 Subject: [PATCH 757/780] Update specs/jsonschema-core.md Co-authored-by: Karen Etheridge --- specs/jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 80110bc5..5a578e41 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -256,7 +256,7 @@ A root schema, which may comprise the entire JSON document, is the top-level schema that is identified by the absolute IRI. The root schema is always a schema resource, where the IRI is determined as described in {{initial-base}}. -Documents formats which embed JSON Schemas within them will not necessarily have +Document formats which embed JSON Schemas within them will not necessarily have a single root schema in this sense. How root schemas are identified within such documents SHOULD be defined by the specifications which govern them. From 030f022cc4571c6b68a3595a807d639f20617630 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 27 Apr 2025 08:24:33 +1200 Subject: [PATCH 758/780] reintroduce removed text --- specs/jsonschema-core.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 691ecdbd..a9e6b9f2 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -604,10 +604,10 @@ identifying such referenced schemas is defined by the keyword. Applicator keywords also behave as assertions, using the assertion results of each subschema or referenced schema of the keyword. These boolean results are modified (e.g. the `not` keyword negates its subschema's assertion) and/or -combined (e.g. `allOf` takes the conjunction of its subschemas' assertions) -to produce the boolean result of the applicator. -any boolean logic operation to the assertion results of subschemas, but SHOULD -NOT introduce new assertion conditions of their own.[^2] +combined (e.g. `allOf` takes the conjunction of its subschemas' assertions) to +produce the boolean result of the applicator. Applicators may apply any boolean +logic operation to the assertion results of subschemas, but SHOULD NOT introduce +new assertion conditions of their own.[^2] [^2]: It is recommended that keywords have a single resposibility. An example of this in action is the separation between `properties`, which verifies object From 6272ae880fc2fb2eb78a60123c229522e0afeea5 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Thu, 8 May 2025 09:28:21 +1200 Subject: [PATCH 759/780] use 'directly modify' instead of 'interfere with' Co-authored-by: Ben Hutton --- specs/jsonschema-core.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index a9e6b9f2..cb8b06c2 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -394,9 +394,9 @@ Additional schema keywords MAY be defined by any entity. Save for explicit agreement, schema authors SHALL NOT expect these additional keywords to be supported by implementations that do not explicitly document such support. -Extension keywords MUST NOT interfere with the operation of keywords defined by +Extension keywords MUST NOT directly modify the operation of keywords defined by this document or the companion JSON Schema Validation specificiation, and SHOULD -NOT interfere with the operation of keywords defined by other extension +NOT directly modify the operation of keywords defined by other extension documents.[^11] [^11]: JSON Schema currently does not have a namespacing mechanism, which would From 4412afcce7187cc606be27117d7dbbb752ed2a48 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Tue, 4 Mar 2025 18:26:47 +1300 Subject: [PATCH 760/780] dollar sign has markdown significance --- specs/jsonschema-core.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 04efe9d2..f9367678 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -873,16 +873,17 @@ default to using the current location if a default is desireable. ## The JSON Schema Core Keywords {#core} -Keywords declared in this section, which all begin with "$", are essential to -processing JSON Schema. These keywords inform implementations how to process any -schema or meta-schema, including those split across multiple documents, or exist -to reserve keywords for purposes that require guaranteed interoperability. +Keywords declared in this section, which all begin with a dollar sign (`$`), are +essential to processing JSON Schema. These keywords inform implementations how +to process any schema or meta-schema, including those split across multiple +documents, or exist to reserve keywords for purposes that require guaranteed +interoperability. Support for these keywords MUST be considered mandatory at all times as they are necessary to navigate and process any schema. -The "$" prefix is reserved for use by this specification. Extensions MUST NOT -define new keywords that begin with "$". +The `$` prefix is reserved for use by this specification. Extensions MUST NOT +define new keywords that begin with `$`. ### Meta-Schemas From 599449ea445f2e95be21687c0a8ec12cba03cea5 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 9 Mar 2025 12:37:43 +1300 Subject: [PATCH 761/780] pushing to back up --- specs/jsonschema-core.md | 6 ++++++ specs/jsonschema-validation.md | 27 +++++++++++++++++++++------ 2 files changed, 27 insertions(+), 6 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index f9367678..a7e5b38b 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -427,6 +427,12 @@ keywords MUST NOT begin with this prefix. Implementations MUST refuse to evaluate schemas which contain keywords which they do not know how to process or explicitly choose not to process. +## Specification Versioning and Compatibility + +This specification is versioned by two values: iteration and release year. + +A schema written to conform with the requirements of a given version (iteration and release year) is compatible with specifications published with the same iteration value and either the same or greater release year value. Thus, JSON Schema provides a guarantee of compatibility for future releases within an iteration. + ## Keyword Behaviors {#keyword-behaviors} JSON Schema keywords may exhibit one or more behaviors. This specification diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 234e0884..c853946c 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -103,16 +103,31 @@ specification. ## Meta-Schema {#meta-schema} The current IRI for the default JSON Schema dialect meta-schema is -`https://json-schema.org/draft/next/schema`. For schema author convenience, this -meta-schema describes a dialect consisting of all keywords defined in this +`https://json-schema.org/1/2025`. This IRI encodes the specifications iteration +value and release year. Because all schemas written to conform to a given +version are guaranteed to be compatible with later releases within the same +iteration, the meta-schema IRI `https://json-schema.org/1` is also recognized to +represent the latest release within the indicated iteration. + +The meta-schema describes a dialect consisting of all keywords defined in this specification and the JSON Schema Core specification. Certain keywords specify some functionality which is optional to support and is explained in detail in the relevant sections. -Updated meta-schema IRIs MAY be published between specification drafts in order -to correct errors. Implementations SHOULD consider IRIs dated after this -specification draft and before the next to indicate the same syntax and -semantics as those listed here. +Where the meta-schema conflicts with either this specification or the JSON +Schema Core specification, the specifications take precedence, and the +meta-schema is to be considered in error. The meta-schema may be occasionally +updated to correct any such errors. + +Although the IRI for the default JSON Schema dialect meta-schema is also a valid +URL, implementations MUST NOT assume that a document is provided at this +location. Rather than performing a network request to retrieve the meta-schema, +implementations SHOULD include a copy of the meta-schema and MAY encode it as +required by the language or framework used by the implementation. + +## Specification Versioning + +The meta-schema IRI format encodes two values that will assist users in determining compatibiility between releases of the JSON Schema specifications. ## Keywords for Structural Validation From 784b1793ecedb03b56679bd6a5668c50dabcdcd7 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 12 Apr 2025 22:26:14 +1200 Subject: [PATCH 762/780] update other meta-schema iris --- specs/jsonschema-core.md | 4 ++-- specs/jsonschema-validation.md | 14 +++++--------- 2 files changed, 7 insertions(+), 11 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index a7e5b38b..3286d1a0 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -2250,7 +2250,7 @@ and only allows the "data" and "children" properties. An example instance with ```jsonschema "Tree schema, extensible" { - "$schema": "https://json-schema.org/draft/next/schema", + "$schema": "https://json-schema.org/1/2025", "$id": "https://example.com/tree", "$dynamicAnchor": "node", @@ -2269,7 +2269,7 @@ and only allows the "data" and "children" properties. An example instance with ```jsonschema "Strict-tree schema, guards against misspelled properties" { - "$schema": "https://json-schema.org/draft/next/schema", + "$schema": "https://json-schema.org/1/2025", "$id": "https://example.com/strict-tree", "$dynamicAnchor": "node", diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index c853946c..f3767d0f 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -103,11 +103,11 @@ specification. ## Meta-Schema {#meta-schema} The current IRI for the default JSON Schema dialect meta-schema is -`https://json-schema.org/1/2025`. This IRI encodes the specifications iteration -value and release year. Because all schemas written to conform to a given -version are guaranteed to be compatible with later releases within the same -iteration, the meta-schema IRI `https://json-schema.org/1` is also recognized to -represent the latest release within the indicated iteration. +`https://json-schema.org/1/2025`. This IRI encodes the specifications version +and release year. Because all schemas written to conform to a given version are +guaranteed to be compatible with later releases within the same iteration, the +meta-schema IRI `https://json-schema.org/1` is also recognized to represent the +latest release within the indicated iteration. The meta-schema describes a dialect consisting of all keywords defined in this specification and the JSON Schema Core specification. Certain keywords specify @@ -125,10 +125,6 @@ location. Rather than performing a network request to retrieve the meta-schema, implementations SHOULD include a copy of the meta-schema and MAY encode it as required by the language or framework used by the implementation. -## Specification Versioning - -The meta-schema IRI format encodes two values that will assist users in determining compatibiility between releases of the JSON Schema specifications. - ## Keywords for Structural Validation Validation keywords in a schema impose requirements for successful validation of From f057ff48203704aa90e9e6508bdaf496f472901e Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 16 Apr 2025 18:32:24 +1200 Subject: [PATCH 763/780] Update specs/jsonschema-validation.md Co-authored-by: Jason Desrosiers --- specs/jsonschema-validation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index f3767d0f..bb403a68 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -103,7 +103,7 @@ specification. ## Meta-Schema {#meta-schema} The current IRI for the default JSON Schema dialect meta-schema is -`https://json-schema.org/1/2025`. This IRI encodes the specifications version +`https://json-schema.org/1/2025`. This IRI encodes the specification's version and release year. Because all schemas written to conform to a given version are guaranteed to be compatible with later releases within the same iteration, the meta-schema IRI `https://json-schema.org/1` is also recognized to represent the From 4a5da5f0829c3b06a72e4fd79b1742523e42e0d2 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Wed, 16 Apr 2025 18:51:10 +1200 Subject: [PATCH 764/780] replace 'iteration' language --- specs/jsonschema-core.md | 8 ++++++-- specs/jsonschema-validation.md | 4 ++-- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 3286d1a0..aa77d218 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -429,9 +429,13 @@ they do not know how to process or explicitly choose not to process. ## Specification Versioning and Compatibility -This specification is versioned by two values: iteration and release year. +This specification is identified collectively by two values: version and release +year. -A schema written to conform with the requirements of a given version (iteration and release year) is compatible with specifications published with the same iteration value and either the same or greater release year value. Thus, JSON Schema provides a guarantee of compatibility for future releases within an iteration. +A schema written to conform with the requirements of a given version is +compatible with successive specifications, which are published with the same +version and either the same or greater release year value. Thus, JSON Schema +provides a guarantee of compatibility for future releases within a version. ## Keyword Behaviors {#keyword-behaviors} diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index bb403a68..ab980f88 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -105,9 +105,9 @@ specification. The current IRI for the default JSON Schema dialect meta-schema is `https://json-schema.org/1/2025`. This IRI encodes the specification's version and release year. Because all schemas written to conform to a given version are -guaranteed to be compatible with later releases within the same iteration, the +guaranteed to be compatible with later releases within the same version, the meta-schema IRI `https://json-schema.org/1` is also recognized to represent the -latest release within the indicated iteration. +latest release within the indicated version. The meta-schema describes a dialect consisting of all keywords defined in this specification and the JSON Schema Core specification. Certain keywords specify From b0a1cdbd25c37373bc130a623917d9424b658cf3 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 22 Jun 2025 09:31:55 +1200 Subject: [PATCH 765/780] incorporate RFC 9557 time zone extension into 'date-time' format --- specs/jsonschema-validation.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index ab980f88..67602ea4 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -397,22 +397,24 @@ custom format values. These attributes apply to string instances. Date and time format names are derived from +[RFC 9557, section 4.1](https://www.rfc-editor.org/info/rfc9557) which extends [RFC 3339, section 5.6](https://www.rfc-editor.org/info/rfc3339). The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339. - *date-time*: A string instance is valid against this attribute if it is a - valid representation according to the "date-time" ABNF rule (referenced above) + valid representation according to the "date-time" ABNF rule in RFC 3339, + optionally with the "time-zone" rule in RFC 9557 - *date*: A string instance is valid against this attribute if it is a valid - representation according to the "full-date" ABNF rule (referenced above) + representation according to the "full-date" ABNF rule in RFC 3339 - *time*: A string instance is valid against this attribute if it is a valid - representation according to the "full-time" ABNF rule (referenced above) + representation according to the "full-time" ABNF rule in RFC 3339 - *duration*: A string instance is valid against this attribute if it is a valid - representation according to the "duration" ABNF rule (referenced above) + representation according to the "duration" ABNF rule in ISO 8601 Implementations MAY support additional attributes using the other format names defined anywhere in that RFC. Implementations SHOULD NOT define extension -attributes with any name matching an RFC 3339 format unless it validates -according to the rules of that format.[^5] +attributes with any name matching an RFC 3339, RFC 9557, or ISO 8601 format +unless it validates according to the rules of that format.[^5] [^5]: There is not currently consensus on the need for supporting all RFC 3339 formats, so this approach of reserving the namespace will encourage From cd0d4bfc93eba799803dc0b57cb47ac9adf46783 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 22 Jun 2025 12:26:51 +1200 Subject: [PATCH 766/780] re-unite meta-schema --- specs/meta/applicator.json | 63 ---------- specs/meta/content.json | 14 --- specs/meta/core.json | 48 -------- specs/meta/format-annotation.json | 11 -- specs/meta/format-assertion.json | 11 -- specs/meta/meta-data.json | 34 ------ specs/meta/meta.json | 187 ++++++++++++++++++++++++++++++ specs/meta/unevaluated.json | 12 -- specs/meta/validation.json | 90 -------------- 9 files changed, 187 insertions(+), 283 deletions(-) delete mode 100644 specs/meta/applicator.json delete mode 100644 specs/meta/content.json delete mode 100644 specs/meta/core.json delete mode 100644 specs/meta/format-annotation.json delete mode 100644 specs/meta/format-assertion.json delete mode 100644 specs/meta/meta-data.json create mode 100644 specs/meta/meta.json delete mode 100644 specs/meta/unevaluated.json delete mode 100644 specs/meta/validation.json diff --git a/specs/meta/applicator.json b/specs/meta/applicator.json deleted file mode 100644 index cbb25392..00000000 --- a/specs/meta/applicator.json +++ /dev/null @@ -1,63 +0,0 @@ -{ - "$schema": "https://json-schema.org/draft/next/schema", - "$id": "https://json-schema.org/draft/next/meta/applicator", - "$dynamicAnchor": "meta", - - "title": "Applicator vocabulary meta-schema", - "type": ["object", "boolean"], - "properties": { - "prefixItems": { "$ref": "#/$defs/schemaArray" }, - "items": { "$dynamicRef": "#meta" }, - "maxContains": { "$ref": "#/$defs/nonNegativeInteger" }, - "minContains": { - "$ref": "#/$defs/nonNegativeInteger", - "default": 1 - }, - "contains": { "$dynamicRef": "#meta" }, - "additionalProperties": { "$dynamicRef": "#meta" }, - "properties": { - "type": "object", - "additionalProperties": { "$dynamicRef": "#meta" }, - "default": {} - }, - "patternProperties": { - "type": "object", - "additionalProperties": { "$dynamicRef": "#meta" }, - "propertyNames": { "format": "regex" }, - "default": {} - }, - "dependentSchemas": { - "type": "object", - "additionalProperties": { "$dynamicRef": "#meta" }, - "default": {} - }, - "propertyDependencies": { - "type": "object", - "additionalProperties": { - "type": "object", - "additionalProperties": { "$dynamicRef": "#meta" }, - "default": {} - }, - "default": {} - }, - "propertyNames": { "$dynamicRef": "#meta" }, - "if": { "$dynamicRef": "#meta" }, - "then": { "$dynamicRef": "#meta" }, - "else": { "$dynamicRef": "#meta" }, - "allOf": { "$ref": "#/$defs/schemaArray" }, - "anyOf": { "$ref": "#/$defs/schemaArray" }, - "oneOf": { "$ref": "#/$defs/schemaArray" }, - "not": { "$dynamicRef": "#meta" } - }, - "$defs": { - "nonNegativeInteger": { - "type": "integer", - "minimum": 0 - }, - "schemaArray": { - "type": "array", - "minItems": 1, - "items": { "$dynamicRef": "#meta" } - } - } -} diff --git a/specs/meta/content.json b/specs/meta/content.json deleted file mode 100644 index f9b754e1..00000000 --- a/specs/meta/content.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "$schema": "https://json-schema.org/draft/next/schema", - "$id": "https://json-schema.org/draft/next/meta/content", - "$dynamicAnchor": "meta", - - "title": "Content vocabulary meta-schema", - - "type": ["object", "boolean"], - "properties": { - "contentEncoding": { "type": "string" }, - "contentMediaType": { "type": "string" }, - "contentSchema": { "$dynamicRef": "#meta" } - } -} diff --git a/specs/meta/core.json b/specs/meta/core.json deleted file mode 100644 index 473927c3..00000000 --- a/specs/meta/core.json +++ /dev/null @@ -1,48 +0,0 @@ -{ - "$schema": "https://json-schema.org/draft/next/schema", - "$id": "https://json-schema.org/draft/next/meta/core", - "$dynamicAnchor": "meta", - - "title": "Core vocabulary meta-schema", - "type": ["object", "boolean"], - "properties": { - "$id": { - "$ref": "#/$defs/iriReferenceString", - "$comment": "Fragments not allowed.", - "pattern": "^[^#]*$" - }, - "$schema": { "$ref": "#/$defs/iriString" }, - "$ref": { "$ref": "#/$defs/iriReferenceString" }, - "$anchor": { "$ref": "#/$defs/anchorString" }, - "$dynamicRef": { "$ref": "#/$defs/iriReferenceString" }, - "$dynamicAnchor": { "$ref": "#/$defs/anchorString" }, - "$vocabulary": { - "type": "object", - "propertyNames": { "$ref": "#/$defs/iriString" }, - "additionalProperties": { - "type": "boolean" - } - }, - "$comment": { - "type": "string" - }, - "$defs": { - "type": "object", - "additionalProperties": { "$dynamicRef": "#meta" } - } - }, - "$defs": { - "anchorString": { - "type": "string", - "pattern": "^[A-Za-z_][-A-Za-z0-9._]*$" - }, - "iriString": { - "type": "string", - "format": "iri" - }, - "iriReferenceString": { - "type": "string", - "format": "iri-reference" - } - } -} diff --git a/specs/meta/format-annotation.json b/specs/meta/format-annotation.json deleted file mode 100644 index 5f657b6c..00000000 --- a/specs/meta/format-annotation.json +++ /dev/null @@ -1,11 +0,0 @@ -{ - "$schema": "https://json-schema.org/draft/next/schema", - "$id": "https://json-schema.org/draft/next/meta/format-annotation", - "$dynamicAnchor": "meta", - - "title": "Format vocabulary meta-schema for annotation results", - "type": ["object", "boolean"], - "properties": { - "format": { "type": "string" } - } -} diff --git a/specs/meta/format-assertion.json b/specs/meta/format-assertion.json deleted file mode 100644 index 3e8cf47f..00000000 --- a/specs/meta/format-assertion.json +++ /dev/null @@ -1,11 +0,0 @@ -{ - "$schema": "https://json-schema.org/draft/next/schema", - "$id": "https://json-schema.org/draft/next/meta/format-assertion", - "$dynamicAnchor": "meta", - - "title": "Format vocabulary meta-schema for assertion results", - "type": ["object", "boolean"], - "properties": { - "format": { "type": "string" } - } -} diff --git a/specs/meta/meta-data.json b/specs/meta/meta-data.json deleted file mode 100644 index 3359227f..00000000 --- a/specs/meta/meta-data.json +++ /dev/null @@ -1,34 +0,0 @@ -{ - "$schema": "https://json-schema.org/draft/next/schema", - "$id": "https://json-schema.org/draft/next/meta/meta-data", - "$dynamicAnchor": "meta", - - "title": "Meta-data vocabulary meta-schema", - - "type": ["object", "boolean"], - "properties": { - "title": { - "type": "string" - }, - "description": { - "type": "string" - }, - "default": true, - "deprecated": { - "type": "boolean", - "default": false - }, - "readOnly": { - "type": "boolean", - "default": false - }, - "writeOnly": { - "type": "boolean", - "default": false - }, - "examples": { - "type": "array", - "items": true - } - } -} diff --git a/specs/meta/meta.json b/specs/meta/meta.json new file mode 100644 index 00000000..860aaa89 --- /dev/null +++ b/specs/meta/meta.json @@ -0,0 +1,187 @@ +{ + "$schema": "https://json-schema.org/version/year/meta", + "$id": "https://json-schema.org/version/year/meta", + "$dynamicAnchor": "meta", + + "title": "JSON Schema Core and Validation specification meta-schema", + "type": ["object", "boolean"], + "properties": { + "$id": { + "$ref": "#/$defs/iriReferenceString", + "$comment": "Fragments not allowed.", + "pattern": "^[^#]*$" + }, + "$schema": { "$ref": "#/$defs/iriString" }, + "$ref": { "$ref": "#/$defs/iriReferenceString" }, + "$anchor": { "$ref": "#/$defs/anchorString" }, + "$dynamicRef": { "$ref": "#/$defs/iriReferenceString" }, + "$dynamicAnchor": { "$ref": "#/$defs/anchorString" }, + "$comment": { + "type": "string" + }, + "$defs": { + "type": "object", + "additionalProperties": { "$dynamicRef": "#meta" } + }, + "title": { + "type": "string" + }, + "description": { + "type": "string" + }, + "default": true, + "deprecated": { + "type": "boolean", + "default": false + }, + "readOnly": { + "type": "boolean", + "default": false + }, + "writeOnly": { + "type": "boolean", + "default": false + }, + "examples": { + "type": "array", + "items": true + }, + "prefixItems": { "$ref": "#/$defs/schemaArray" }, + "items": { "$dynamicRef": "#meta" }, + "maxContains": { "$ref": "#/$defs/nonNegativeInteger" }, + "minContains": { + "$ref": "#/$defs/nonNegativeInteger", + "default": 1 + }, + "contains": { "$dynamicRef": "#meta" }, + "additionalProperties": { "$dynamicRef": "#meta" }, + "properties": { + "type": "object", + "additionalProperties": { "$dynamicRef": "#meta" }, + "default": {} + }, + "patternProperties": { + "type": "object", + "additionalProperties": { "$dynamicRef": "#meta" }, + "propertyNames": { "format": "regex" }, + "default": {} + }, + "dependentSchemas": { + "type": "object", + "additionalProperties": { "$dynamicRef": "#meta" }, + "default": {} + }, + "propertyNames": { "$dynamicRef": "#meta" }, + "if": { "$dynamicRef": "#meta" }, + "then": { "$dynamicRef": "#meta" }, + "else": { "$dynamicRef": "#meta" }, + "allOf": { "$ref": "#/$defs/schemaArray" }, + "anyOf": { "$ref": "#/$defs/schemaArray" }, + "oneOf": { "$ref": "#/$defs/schemaArray" }, + "not": { "$dynamicRef": "#meta" }, + "unevaluatedItems": { "$dynamicRef": "#meta" }, + "unevaluatedProperties": { "$dynamicRef": "#meta" }, + "type": { + "anyOf": [ + { "$ref": "#/$defs/simpleTypes" }, + { + "type": "array", + "items": { "$ref": "#/$defs/simpleTypes" }, + "minItems": 1, + "uniqueItems": true + } + ] + }, + "const": true, + "enum": { + "type": "array", + "items": true + }, + "multipleOf": { + "type": "number", + "exclusiveMinimum": 0 + }, + "maximum": { + "type": "number" + }, + "exclusiveMaximum": { + "type": "number" + }, + "minimum": { + "type": "number" + }, + "exclusiveMinimum": { + "type": "number" + }, + "maxLength": { "$ref": "#/$defs/nonNegativeInteger" }, + "minLength": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, + "pattern": { + "type": "string", + "format": "regex" + }, + "maxItems": { "$ref": "#/$defs/nonNegativeInteger" }, + "minItems": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, + "uniqueItems": { + "type": "boolean", + "default": false + }, + "maxProperties": { "$ref": "#/$defs/nonNegativeInteger" }, + "minProperties": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, + "required": { "$ref": "#/$defs/stringArray" }, + "dependentRequired": { + "type": "object", + "additionalProperties": { + "$ref": "#/$defs/stringArray" + } + }, + "format": { "type": "string" }, + "contentEncoding": { "type": "string" }, + "contentMediaType": { "type": "string" }, + "contentSchema": { "$dynamicRef": "#meta" }, + + "$vocabulary": { + "$comment": "Proposed keyword: https://github.com/json-schema-org/json-schema-spec/blob/main/specs/proposals/vocabularies.md" + }, + "propertyDependencies": { + "$comment": "Proposed keyword: https://github.com/json-schema-org/json-schema-spec/blob/main/specs/proposals/propertyDependencies.md" + } + }, + "$defs": { + "anchorString": { + "type": "string", + "pattern": "^[A-Za-z_][-A-Za-z0-9._]*$" + }, + "iriString": { + "type": "string", + "format": "iri" + }, + "iriReferenceString": { + "type": "string", + "format": "iri-reference" + }, + "nonNegativeInteger": { + "type": "integer", + "minimum": 0 + }, + "nonNegativeIntegerDefault0": { + "$ref": "#/$defs/nonNegativeInteger", + "default": 0 + }, + "schemaArray": { + "type": "array", + "minItems": 1, + "items": { "$dynamicRef": "#meta" } + }, + "simpleTypes": { + "enum": [ + "array", + "boolean", + "integer", + "null", + "number", + "object", + "string" + ] + } + } +} diff --git a/specs/meta/unevaluated.json b/specs/meta/unevaluated.json deleted file mode 100644 index 1d283fbd..00000000 --- a/specs/meta/unevaluated.json +++ /dev/null @@ -1,12 +0,0 @@ -{ - "$schema": "https://json-schema.org/draft/next/schema", - "$id": "https://json-schema.org/draft/next/meta/unevaluated", - "$dynamicAnchor": "meta", - - "title": "Unevaluated applicator vocabulary meta-schema", - "type": ["object", "boolean"], - "properties": { - "unevaluatedItems": { "$dynamicRef": "#meta" }, - "unevaluatedProperties": { "$dynamicRef": "#meta" } - } -} diff --git a/specs/meta/validation.json b/specs/meta/validation.json deleted file mode 100644 index 51afc7cb..00000000 --- a/specs/meta/validation.json +++ /dev/null @@ -1,90 +0,0 @@ -{ - "$schema": "https://json-schema.org/draft/next/schema", - "$id": "https://json-schema.org/draft/next/meta/validation", - "$dynamicAnchor": "meta", - - "title": "Validation vocabulary meta-schema", - "type": ["object", "boolean"], - "properties": { - "type": { - "anyOf": [ - { "$ref": "#/$defs/simpleTypes" }, - { - "type": "array", - "items": { "$ref": "#/$defs/simpleTypes" }, - "minItems": 1, - "uniqueItems": true - } - ] - }, - "const": true, - "enum": { - "type": "array", - "items": true - }, - "multipleOf": { - "type": "number", - "exclusiveMinimum": 0 - }, - "maximum": { - "type": "number" - }, - "exclusiveMaximum": { - "type": "number" - }, - "minimum": { - "type": "number" - }, - "exclusiveMinimum": { - "type": "number" - }, - "maxLength": { "$ref": "#/$defs/nonNegativeInteger" }, - "minLength": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, - "pattern": { - "type": "string", - "format": "regex" - }, - "maxItems": { "$ref": "#/$defs/nonNegativeInteger" }, - "minItems": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, - "uniqueItems": { - "type": "boolean", - "default": false - }, - "maxProperties": { "$ref": "#/$defs/nonNegativeInteger" }, - "minProperties": { "$ref": "#/$defs/nonNegativeIntegerDefault0" }, - "required": { "$ref": "#/$defs/stringArray" }, - "dependentRequired": { - "type": "object", - "additionalProperties": { - "$ref": "#/$defs/stringArray" - } - } - }, - "$defs": { - "nonNegativeInteger": { - "type": "integer", - "minimum": 0 - }, - "nonNegativeIntegerDefault0": { - "$ref": "#/$defs/nonNegativeInteger", - "default": 0 - }, - "simpleTypes": { - "enum": [ - "array", - "boolean", - "integer", - "null", - "number", - "object", - "string" - ] - }, - "stringArray": { - "type": "array", - "items": { "type": "string" }, - "uniqueItems": true, - "default": [] - } - } -} From 44c5c0e5e29f7c32f424f9d35b38c5e34861b8f5 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 22 Jun 2025 16:24:15 +1200 Subject: [PATCH 767/780] allow for x- properties --- specs/meta/meta.json | 3 +++ 1 file changed, 3 insertions(+) diff --git a/specs/meta/meta.json b/specs/meta/meta.json index 860aaa89..218e3bed 100644 --- a/specs/meta/meta.json +++ b/specs/meta/meta.json @@ -146,6 +146,9 @@ "$comment": "Proposed keyword: https://github.com/json-schema-org/json-schema-spec/blob/main/specs/proposals/propertyDependencies.md" } }, + "patternProperties": { + "^x-": true + }, "$defs": { "anchorString": { "type": "string", From 33d7241e6a745d85ae17ca689ad0c3ef0c9a03b7 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 22 Jun 2025 16:48:53 +1200 Subject: [PATCH 768/780] disallow other $* keywrods --- specs/meta/meta.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/specs/meta/meta.json b/specs/meta/meta.json index 218e3bed..151b542a 100644 --- a/specs/meta/meta.json +++ b/specs/meta/meta.json @@ -147,7 +147,8 @@ } }, "patternProperties": { - "^x-": true + "^x-": true, + "^(?!(?:\\$id|\\$schema|\\$ref|\\$anchor|\\$dynamicRef|\\$dynamicAnchor|\\$comment|\\$defs)$).*": false }, "$defs": { "anchorString": { From 154b863eddcbebc711d555ae36ccada48af646e7 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 22 Jun 2025 16:51:29 +1200 Subject: [PATCH 769/780] disallow other $* keywords (fix) --- specs/meta/meta.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/meta/meta.json b/specs/meta/meta.json index 151b542a..4048fdd8 100644 --- a/specs/meta/meta.json +++ b/specs/meta/meta.json @@ -148,7 +148,7 @@ }, "patternProperties": { "^x-": true, - "^(?!(?:\\$id|\\$schema|\\$ref|\\$anchor|\\$dynamicRef|\\$dynamicAnchor|\\$comment|\\$defs)$).*": false + "^(?!(?:\\$id|\\$schema|\\$ref|\\$anchor|\\$dynamicRef|\\$dynamicAnchor|\\$comment|\\$defs)$)\\$.*": false }, "$defs": { "anchorString": { From 8bdeaa6df9b61589152d9b6fe58f0521c1990d0f Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 13 Jul 2025 15:09:43 +1200 Subject: [PATCH 770/780] Update specs/jsonschema-validation.md Co-authored-by: Richard Gibson --- specs/jsonschema-validation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 67602ea4..aa457dfb 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -409,7 +409,7 @@ format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339. - *time*: A string instance is valid against this attribute if it is a valid representation according to the "full-time" ABNF rule in RFC 3339 - *duration*: A string instance is valid against this attribute if it is a valid - representation according to the "duration" ABNF rule in ISO 8601 + representation according to the "duration" ABNF rule in RFC 3339 Appendix A Implementations MAY support additional attributes using the other format names defined anywhere in that RFC. Implementations SHOULD NOT define extension From 3dca1c9f97fd03f3e3afb7232d66f92aad667a5b Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 13 Jul 2025 15:10:08 +1200 Subject: [PATCH 771/780] Update specs/jsonschema-validation.md Co-authored-by: Richard Gibson --- specs/jsonschema-validation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index aa457dfb..395fe9f5 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -399,7 +399,7 @@ These attributes apply to string instances. Date and time format names are derived from [RFC 9557, section 4.1](https://www.rfc-editor.org/info/rfc9557) which extends [RFC 3339, section 5.6](https://www.rfc-editor.org/info/rfc3339). The duration -format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339. +format is from ISO 8601 as formalized into ABNF by RFC 3339 Appendix A. - *date-time*: A string instance is valid against this attribute if it is a valid representation according to the "date-time" ABNF rule in RFC 3339, From 55097db48aff4c2d07ee48fbf5b3255caef081c1 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 13 Jul 2025 15:14:15 +1200 Subject: [PATCH 772/780] add clarity and full-inclusion of rfc9557 format --- specs/jsonschema-validation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index 395fe9f5..da7f372c 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -402,8 +402,8 @@ Date and time format names are derived from format is from ISO 8601 as formalized into ABNF by RFC 3339 Appendix A. - *date-time*: A string instance is valid against this attribute if it is a - valid representation according to the "date-time" ABNF rule in RFC 3339, - optionally with the "time-zone" rule in RFC 9557 + valid representation of either the "date-time" ABNF rule in RFC 3339 or the + "date-time-ext" rule in RFC 9557 - *date*: A string instance is valid against this attribute if it is a valid representation according to the "full-date" ABNF rule in RFC 3339 - *time*: A string instance is valid against this attribute if it is a valid From bba80a7dd72e46517f07b5f37e3a924d8482267b Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 13 Jul 2025 15:35:22 +1200 Subject: [PATCH 773/780] use propertyNames to restrict $-keywords --- specs/meta/meta.json | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/specs/meta/meta.json b/specs/meta/meta.json index 4048fdd8..168f85b3 100644 --- a/specs/meta/meta.json +++ b/specs/meta/meta.json @@ -1,6 +1,6 @@ { - "$schema": "https://json-schema.org/version/year/meta", - "$id": "https://json-schema.org/version/year/meta", + "$schema": "https://json-schema.org/1/2025", + "$id": "https://json-schema.org/1/2025", "$dynamicAnchor": "meta", "title": "JSON Schema Core and Validation specification meta-schema", @@ -147,8 +147,10 @@ } }, "patternProperties": { - "^x-": true, - "^(?!(?:\\$id|\\$schema|\\$ref|\\$anchor|\\$dynamicRef|\\$dynamicAnchor|\\$comment|\\$defs)$)\\$.*": false + "^x-": true + }, + "propertyNames": { + "pattern": "^[^$]|^\\$(id|schema|ref|anchor|dynamicRef|dynamicAnchor|comment|defs)$" }, "$defs": { "anchorString": { @@ -186,6 +188,12 @@ "object", "string" ] + }, + "stringArray": { + "type": "array", + "items": { "type": "string" }, + "uniqueItems": true, + "default": [] } } } From 821255e97f2756b7ae0faaad6db24692325b63de Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sun, 13 Jul 2025 16:52:51 +1200 Subject: [PATCH 774/780] add subsection to point to the github process file for proposal requirements --- PROCESS.md | 2 +- specs/jsonschema-core.md | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/PROCESS.md b/PROCESS.md index b0a06cb0..7d769bed 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -106,7 +106,7 @@ The website will also be configured to: The latest-release meta-schemas will be updated with proposals as indicated by the [Proposal section](#proposal) of this document. -> \[!IMPORTANT] +> [!IMPORTANT] > These are only publication and availability URLs. The specification will > define the `$id` values for the meta-schemas. diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 2cf7f4ce..93b84dfd 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -437,6 +437,13 @@ compatible with successive specifications, which are published with the same version and either the same or greater release year value. Thus, JSON Schema provides a guarantee of compatibility for future releases within a version. +### Future Development and Support of Proposals + +Continued development of this specifications and support requirments for +proposed features is managed in the +[json-schema-org/json-schema-spec](https://github.com/json-schema-org/json-schema-spec) +GitHub repository and defined by _PROCESS.md_. + ## Keyword Behaviors {#keyword-behaviors} JSON Schema keywords may exhibit one or more behaviors. This specification From d6aba7ba25dd84aced7115cbd88831d089c340fb Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Fri, 18 Jul 2025 08:04:43 +1200 Subject: [PATCH 775/780] date-time-ext allows for no suffix Co-authored-by: Richard Gibson --- specs/jsonschema-validation.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/specs/jsonschema-validation.md b/specs/jsonschema-validation.md index da7f372c..e658f3a4 100644 --- a/specs/jsonschema-validation.md +++ b/specs/jsonschema-validation.md @@ -402,8 +402,7 @@ Date and time format names are derived from format is from ISO 8601 as formalized into ABNF by RFC 3339 Appendix A. - *date-time*: A string instance is valid against this attribute if it is a - valid representation of either the "date-time" ABNF rule in RFC 3339 or the - "date-time-ext" rule in RFC 9557 + valid representation of the "date-time-ext" rule in RFC 9557 - *date*: A string instance is valid against this attribute if it is a valid representation according to the "full-date" ABNF rule in RFC 3339 - *time*: A string instance is valid against this attribute if it is a valid From 623a1e4fc1ccfa8d998d9bb6089fdddfd986b12c Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 19 Jul 2025 17:48:27 +1200 Subject: [PATCH 776/780] fix grammar mistake --- specs/jsonschema-core.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/jsonschema-core.md b/specs/jsonschema-core.md index 93b84dfd..4d629d3f 100644 --- a/specs/jsonschema-core.md +++ b/specs/jsonschema-core.md @@ -439,7 +439,7 @@ provides a guarantee of compatibility for future releases within a version. ### Future Development and Support of Proposals -Continued development of this specifications and support requirments for +Continued development of these specifications and support requirments for proposed features is managed in the [json-schema-org/json-schema-spec](https://github.com/json-schema-org/json-schema-spec) GitHub repository and defined by _PROCESS.md_. From e754c5a9e482e622f507abb9ec7a5da501df0170 Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 19 Jul 2025 17:53:52 +1200 Subject: [PATCH 777/780] re-escape the bracket for some reason --- PROCESS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/PROCESS.md b/PROCESS.md index 7d769bed..b0a06cb0 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -106,7 +106,7 @@ The website will also be configured to: The latest-release meta-schemas will be updated with proposals as indicated by the [Proposal section](#proposal) of this document. -> [!IMPORTANT] +> \[!IMPORTANT] > These are only publication and availability URLs. The specification will > define the `$id` values for the meta-schemas. From db2b0c2f31401d0c6a3621112e14aa37c26cd37b Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Sat, 19 Jul 2025 18:37:15 +1200 Subject: [PATCH 778/780] update the meta-schema to allow for extension; add readme with basic how-to --- specs/meta/README.md | 74 ++++++++++++++++++++++++++++++++++++++++++++ specs/meta/meta.json | 5 +++ 2 files changed, 79 insertions(+) create mode 100644 specs/meta/README.md diff --git a/specs/meta/README.md b/specs/meta/README.md new file mode 100644 index 00000000..3c5bb51a --- /dev/null +++ b/specs/meta/README.md @@ -0,0 +1,74 @@ +# JSON Schema Meta-Schema + +The _meta.json_ file contains the meta-schema for the in-progress JSON Schema +specifications. You can find the latest published version on the +[JSON Schema website](https://json-schema.org). + +## Meta-Schemas + +A meta-schema is a schema that itself describes a schema. This is possible +because JSON Schema can be written as JSON. + +Furthermore, the JSON Schema meta-schema is self-validating. That is, its JSON +form validates against the meta-schema. + +## Extensions and Unknown Keywords + +The JSON Schema specification allows for extension keywords to be introduced, +however it also disallows unknown keywords. While seemingly contradictory, the +meta-schema has been set up to allow for extension. + +For this example, we'll add two hypothetical keywords: `odds` and `evens`, which +validate the odd and even indexed values in an array, respectively. + +First, create a schema that just defines the new keywords. + +```json +{ + "$schema": "https://json-schema.org/1", + "$id": "https://example.com/schema/odds-evens", + + "properties": { + "odds": { "$dynamicRef": "#meta" }, + "evens": { "$dynamicRef": "#meta" } + } +} +``` + +Second, create a new meta-schema that + +- references the above schema +- references the JSON Schema meta-schema +- includes an extension point in a `$defs` + +```json +{ + "$schema": "https://json-schema.org/1", + "$id": "https://example.com/schema/odds-evens-extension", + + "$ref": "https://json-schema.org/1", + + "$defs": { + "extension": { + "$dynamicAnchor": "extension", + "$ref": "https://example.com/schema/odds-evens" + } + } +} +``` + +Now you can use `https://example.com/schema/odds-evens-extension` in your +schemas to make use of the new `odds` and `evens` keywords. + +```json +{ + "$schema": "https://example.com/schema/odds-evens-extension", + "$id": "https://example.com/schema/model", + + "type": "array", + "odds": { "type": "string" }, + "evens": { "type": "number" } +} +``` + +This schema will validate arrays whose items alternate between strings and numbers. \ No newline at end of file diff --git a/specs/meta/meta.json b/specs/meta/meta.json index 168f85b3..f86e16c9 100644 --- a/specs/meta/meta.json +++ b/specs/meta/meta.json @@ -152,7 +152,12 @@ "propertyNames": { "pattern": "^[^$]|^\\$(id|schema|ref|anchor|dynamicRef|dynamicAnchor|comment|defs)$" }, + "$dynamicRef": "#extension", + "unevaluatedProperties": false, "$defs": { + "extension": { + "$dynamicAnchor": "extension" + }, "anchorString": { "type": "string", "pattern": "^[A-Za-z_][-A-Za-z0-9._]*$" From 84aeb6b57d6960552dc7a034cd3172b730406719 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Tue, 29 Jul 2025 16:58:44 -0700 Subject: [PATCH 779/780] Update python dependencies with security vulnerabilities --- requirements.txt | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/requirements.txt b/requirements.txt index 5b414e3d..92b43d25 100644 --- a/requirements.txt +++ b/requirements.txt @@ -2,13 +2,13 @@ # This file is autogenerated by pip-compile with Python 3.13 # by the following command: # -# pip-compile +# pip-compile requirements.in # -certifi==2025.1.31 +certifi==2025.7.14 # via requests -charset-normalizer==3.4.1 +charset-normalizer==3.4.2 # via requests -configargparse==1.7 +configargparse==1.7.1 # via xml2rfc google-i18n-address==3.1.1 # via xml2rfc @@ -18,27 +18,27 @@ intervaltree==3.1.0 # via xml2rfc jinja2==3.1.6 # via xml2rfc -lxml==5.3.1 +lxml==6.0.0 # via xml2rfc markupsafe==3.0.2 # via jinja2 -platformdirs==4.3.6 +platformdirs==4.3.8 # via xml2rfc pycountry==24.6.1 # via xml2rfc pyyaml==6.0.2 # via xml2rfc -requests==2.32.3 +requests==2.32.4 # via # google-i18n-address # xml2rfc sortedcontainers==2.4.0 # via intervaltree -urllib3==2.3.0 +urllib3==2.5.0 # via requests wcwidth==0.2.13 # via xml2rfc -xml2rfc==3.28.0 +xml2rfc==3.30.0 # via -r requirements.in # The following packages are considered to be unsafe in a requirements file: From fa58ebc73cdc1823dacf3a4f88c1477852f6e4ec Mon Sep 17 00:00:00 2001 From: Greg Dennis Date: Mon, 4 Aug 2025 10:56:35 +1200 Subject: [PATCH 780/780] markdown style updates --- specs/meta/README.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/specs/meta/README.md b/specs/meta/README.md index 3c5bb51a..709c56d8 100644 --- a/specs/meta/README.md +++ b/specs/meta/README.md @@ -1,8 +1,10 @@ # JSON Schema Meta-Schema -The _meta.json_ file contains the meta-schema for the in-progress JSON Schema -specifications. You can find the latest published version on the -[JSON Schema website](https://json-schema.org). +The *meta.json* file contains the meta-schema for the in-progress JSON Schema +specifications. You can find the latest published version on the [JSON Schema +website](https://json-schema.org). + +## Table of Contents ## Meta-Schemas @@ -71,4 +73,5 @@ schemas to make use of the new `odds` and `evens` keywords. } ``` -This schema will validate arrays whose items alternate between strings and numbers. \ No newline at end of file +This schema will validate arrays whose items alternate between strings and +numbers.