From 117c05e55ae0a798a10907f61348c81318971f9d Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Sat, 11 Sep 2021 18:31:05 -0700 Subject: [PATCH 01/36] Add dialect schema for hyperschema 2019-09 with schema 2020-12 --- hyper-schema.json | 27 ++++++++++++++ links.json | 85 ++++++++++++++++++++++++++++++++++++++++++ meta/hyper-schema.json | 29 ++++++++++++++ 3 files changed, 141 insertions(+) create mode 100644 hyper-schema.json create mode 100644 links.json create mode 100644 meta/hyper-schema.json diff --git a/hyper-schema.json b/hyper-schema.json new file mode 100644 index 00000000..eb4f0b32 --- /dev/null +++ b/hyper-schema.json @@ -0,0 +1,27 @@ +{ + "$schema": "https://json-schema.org/draft/2020-12/hyper-schema", + "$id": "https://json-schema.org/draft/2020-12/hyper-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/2019-09/vocab/hyper-schema": true + }, + "$dynamicAnchor": "meta", + + "title": "JSON Hyper-Schema", + "allOf": [ + { "$ref": "https://json-schema.org/draft/2020-12/schema" }, + { "$ref": "https://json-schema.org/draft/2020-12/meta/hyper-schema" } + ], + "links": [ + { + "rel": "self", + "href": "{+%24id}" + } + ] +} diff --git a/links.json b/links.json new file mode 100644 index 00000000..c71690ec --- /dev/null +++ b/links.json @@ -0,0 +1,85 @@ +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://json-schema.org/draft/2020-12/links", + "title": "Link Description Object", + + "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/2020-12/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/2020-12/hyper-schema#meta", + "default": true + }, + "targetMediaType": { + "type": "string" + }, + "targetHints": {}, + "headerSchema": { + "$dynamicRef": "https://json-schema.org/draft/2020-12/hyper-schema#meta", + "default": true + }, + "submissionMediaType": { + "type": "string", + "default": "application/json" + }, + "submissionSchema": { + "$dynamicRef": "https://json-schema.org/draft/2020-12/hyper-schema#meta", + "default": true + }, + "$comment": { + "type": "string" + } + }, + "required": [ "rel", "href" ] +} diff --git a/meta/hyper-schema.json b/meta/hyper-schema.json new file mode 100644 index 00000000..62a31366 --- /dev/null +++ b/meta/hyper-schema.json @@ -0,0 +1,29 @@ +{ + "$schema": "https://json-schema.org/draft/2020-12/hyper-schema", + "$id": "https://json-schema.org/draft/2020-12/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/2020-12/links" + } + } + }, + "links": [ + { + "rel": "self", + "href": "{+%24id}" + } + ] +} From 2c809dcdc9c89466495637d9a8d1ebc2b446319f Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 25 Mar 2021 14:44:46 -0700 Subject: [PATCH 02/36] 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 e2080cec7fd05abdaa16c7e91d1d780dafa889f3 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 11 May 2021 10:28:17 -0700 Subject: [PATCH 03/36] 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 6e8bac949ec37e127143c33742e088432726dddf Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Thu, 8 Apr 2021 10:37:02 -0700 Subject: [PATCH 04/36] 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 01c46242..a93c377d 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2679,7 +2679,7 @@
From d6464c175c59fc2d343dcec15ccb87f706764971 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 11 May 2021 10:28:30 -0700 Subject: [PATCH 05/36] 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 f0a93c63a5e2a7bf55e7cb391ccfebac8db45860 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 11 May 2021 11:38:59 -0700 Subject: [PATCH 06/36] 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 c73f0ce1..49df09c2 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 a8d4d28e8b1f1a4a0d1cc709a0d66fd641fb18ce Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 9 Nov 2021 06:47:37 -0800 Subject: [PATCH 07/36] 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 d717cadade562d28c5d69672901ac50ef3d5d786 Mon Sep 17 00:00:00 2001 From: Roberto Polli Date: Fri, 19 Nov 2021 16:43:58 +0100 Subject: [PATCH 08/36] 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 6e289b7c2cdb37d5ba9b25008f96b61bffb2c6a6 Mon Sep 17 00:00:00 2001 From: Juan Cruz Viotti Date: Thu, 30 Dec 2021 14:24:48 -0400 Subject: [PATCH 09/36] 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 2d682d24d763733443647db5f6ad480bdec8be59 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Mon, 31 May 2021 14:30:11 -0700 Subject: [PATCH 10/36] 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 1947dde994b6b3bf848631756d6d9bdabcdf6563 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Mon, 31 May 2021 14:37:53 -0700 Subject: [PATCH 11/36] 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 0e3482738dbc86013107f84582f8ad980aac9979 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Mon, 31 May 2021 14:52:43 -0700 Subject: [PATCH 12/36] 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 a18cb8364ff1395dc8a7323751bd0573ba70d839 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Mon, 31 May 2021 16:25:40 -0700 Subject: [PATCH 13/36] "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 af7705cd025d4bf9f5eed88b1f0bc2f1dedf5312 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Mon, 31 May 2021 16:26:03 -0700 Subject: [PATCH 14/36] $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 fe5ed2727780836e05ff3cd4da987808b67e5bf5 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Thu, 3 Feb 2022 20:14:32 -0800 Subject: [PATCH 15/36] 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 96fad2c9c6db1335212888cfe8472d5f438d05c5 Mon Sep 17 00:00:00 2001 From: Karen Etheridge Date: Thu, 3 Feb 2022 20:15:28 -0800 Subject: [PATCH 16/36] 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 df1d3813f4b8d69b6d7c5a253291712e0d543238 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 3 Feb 2022 10:31:07 -0800 Subject: [PATCH 17/36] 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 09d6f9dc5640f8d01b429958690efbba4a820aa0 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 14 Mar 2022 11:10:38 +0000 Subject: [PATCH 18/36] 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 eccb83da854e994ad298883330124ac1f84e2eba Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Thu, 13 May 2021 17:18:58 -0700 Subject: [PATCH 19/36] 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 37bcc3e842caf2bc5f30288e9a5aa36152ac3a7e Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 13 Jul 2021 16:47:56 -0700 Subject: [PATCH 20/36] 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 2c8813d030f98a0468dc570e326120a3b1d661ca Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 30 Mar 2022 09:46:52 +0100 Subject: [PATCH 21/36] 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 d951bd0615383aad197328debff686109f32358e Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 8 Apr 2022 15:53:07 +0100 Subject: [PATCH 22/36] 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 59f55a7877f6eaa785717fdaa7e72eabfc7dccc0 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Fri, 8 Apr 2022 16:00:19 +0100 Subject: [PATCH 23/36] 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 625c18e3d378009aa707c12db31c53e166480b66 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 20 Apr 2022 10:16:38 +0100 Subject: [PATCH 24/36] 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 a9ad27eb99ef8a7460d94778b61bc9b668a26981 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Wed, 20 Apr 2022 10:16:52 +0100 Subject: [PATCH 25/36] 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 c735415cda634c887e1e30b6b4c00fd140b3f20b Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 28 Apr 2022 13:30:21 +0100 Subject: [PATCH 26/36] 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 d9b6b20c057f5f61b51b886930b5fd766602d038 Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Thu, 28 Apr 2022 16:54:33 +0100 Subject: [PATCH 27/36] 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 5dad13a8a3bfc4eca79d1d0c80902b15d2bb1b46 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Tue, 10 May 2022 14:13:40 +0100 Subject: [PATCH 28/36] 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 76718da3660b6c0ccfad286489d87a0783dd247e Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Thu, 19 May 2022 12:06:35 +0100 Subject: [PATCH 29/36] 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 2b14ac9470517823064578379684b98c1ad4fa4f Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Thu, 19 May 2022 16:10:32 +0100 Subject: [PATCH 30/36] 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 d8ad641906020ef71bfd881b2e6668d60cbc0ef2 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Thu, 26 May 2022 21:51:27 +1200 Subject: [PATCH 31/36] 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 ee99032897d1acafb4d098c3807ed7102ca45423 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Fri, 10 Jun 2022 10:47:34 +0100 Subject: [PATCH 32/36] 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 510ba2515821b3106bf5e9a1e77565ea4410e0ec Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Fri, 10 Jun 2022 11:20:26 +0100 Subject: [PATCH 33/36] 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 769daad75a9553562333a8937a187741cb708c72 Mon Sep 17 00:00:00 2001 From: Ben Hutton <relequestual@gmail.com> Date: Fri, 10 Jun 2022 11:38:26 +0100 Subject: [PATCH 34/36] 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 d6e8c7a394c097b7b122bcfa4b7d346c1561cab5 Mon Sep 17 00:00:00 2001 From: Greg Dennis <gregsdennis@yahoo.com> Date: Thu, 2 Nov 2023 09:45:37 +1300 Subject: [PATCH 35/36] remove `$vocabulary` from vocab meta-schemas (2020-12) --- meta/applicator.json | 3 --- meta/content.json | 3 --- meta/core.json | 3 --- meta/format-annotation.json | 3 --- meta/format-assertion.json | 3 --- meta/hyper-schema.json | 3 --- meta/meta-data.json | 3 --- meta/unevaluated.json | 3 --- meta/validation.json | 3 --- 9 files changed, 27 deletions(-) diff --git a/meta/applicator.json b/meta/applicator.json index ca699230..f4775974 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -1,9 +1,6 @@ { "$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/2020-12/vocab/applicator": true - }, "$dynamicAnchor": "meta", "title": "Applicator vocabulary meta-schema", diff --git a/meta/content.json b/meta/content.json index 2f6e056a..76e3760d 100644 --- a/meta/content.json +++ b/meta/content.json @@ -1,9 +1,6 @@ { "$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/2020-12/vocab/content": true - }, "$dynamicAnchor": "meta", "title": "Content vocabulary meta-schema", diff --git a/meta/core.json b/meta/core.json index dfc092d9..69186228 100644 --- a/meta/core.json +++ b/meta/core.json @@ -1,9 +1,6 @@ { "$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/2020-12/vocab/core": true - }, "$dynamicAnchor": "meta", "title": "Core vocabulary meta-schema", diff --git a/meta/format-annotation.json b/meta/format-annotation.json index 51ef7ea1..3479e669 100644 --- a/meta/format-annotation.json +++ b/meta/format-annotation.json @@ -1,9 +1,6 @@ { "$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/2020-12/vocab/format-annotation": true - }, "$dynamicAnchor": "meta", "title": "Format vocabulary meta-schema for annotation results", diff --git a/meta/format-assertion.json b/meta/format-assertion.json index 5e73fd75..1a4f106c 100644 --- a/meta/format-assertion.json +++ b/meta/format-assertion.json @@ -1,9 +1,6 @@ { "$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/2020-12/vocab/format-assertion": true - }, "$dynamicAnchor": "meta", "title": "Format vocabulary meta-schema for assertion results", diff --git a/meta/hyper-schema.json b/meta/hyper-schema.json index 62a31366..f0beb5a4 100644 --- a/meta/hyper-schema.json +++ b/meta/hyper-schema.json @@ -1,9 +1,6 @@ { "$schema": "https://json-schema.org/draft/2020-12/hyper-schema", "$id": "https://json-schema.org/draft/2020-12/meta/hyper-schema", - "$vocabulary": { - "https://json-schema.org/draft/2019-09/vocab/hyper-schema": true - }, "$dynamicAnchor": "meta", "title": "JSON Hyper-Schema Vocabulary Schema", diff --git a/meta/meta-data.json b/meta/meta-data.json index 05cbc22a..4049ab21 100644 --- a/meta/meta-data.json +++ b/meta/meta-data.json @@ -1,9 +1,6 @@ { "$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/2020-12/vocab/meta-data": true - }, "$dynamicAnchor": "meta", "title": "Meta-data vocabulary meta-schema", diff --git a/meta/unevaluated.json b/meta/unevaluated.json index 5f62a3ff..93779e54 100644 --- a/meta/unevaluated.json +++ b/meta/unevaluated.json @@ -1,9 +1,6 @@ { "$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/2020-12/vocab/unevaluated": true - }, "$dynamicAnchor": "meta", "title": "Unevaluated applicator vocabulary meta-schema", diff --git a/meta/validation.json b/meta/validation.json index 606b87ba..ebb75db7 100644 --- a/meta/validation.json +++ b/meta/validation.json @@ -1,9 +1,6 @@ { "$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/2020-12/vocab/validation": true - }, "$dynamicAnchor": "meta", "title": "Validation vocabulary meta-schema", From b7e24435feef3b053f6a077bec0d994a7f1a1c18 Mon Sep 17 00:00:00 2001 From: Julian Berman <Julian@GrayVines.com> Date: Thu, 2 Nov 2023 22:55:16 -0400 Subject: [PATCH 36/36] Update the link to the JSON Schema website. Refs: json-schema-org/website#201 --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 69147dea..f10ca455 100644 --- a/README.md +++ b/README.md @@ -53,7 +53,7 @@ Conformance tests for JSON Schema and its vocabularies may be found 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). +The source for the website is [maintained in a separate repository](https://github.com/json-schema-org/website). ## Contributors