diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ddeda4cd..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 master. +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. @@ -78,4 +82,4 @@ Support this project with your organization. Your logo will show up here with a - \ No newline at end of file + diff --git a/Makefile b/Makefile index a85e82ce..9607d187 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -XML2RFC=xml2rfc +XML2RFC ?= xml2rfc OUT = \ jsonschema-core.html jsonschema-core.txt \ @@ -24,4 +24,4 @@ json-schema.tar.gz: $(OUT) clean: rm -f $(OUT) json-schema.tar.gz -.PHONY: clean +.PHONY: clean all diff --git a/README.md b/README.md index 69147dea..5dd3478d 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) [![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. @@ -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: diff --git a/jsonschema-core.xml b/jsonschema-core.xml index 8397999f..f580d50c 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2,6 +2,7 @@ + @@ -206,7 +207,7 @@ 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.
@@ -316,8 +317,8 @@ of five categories: - 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 produce a boolean result when applied to an instance @@ -394,7 +395,7 @@ 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 @@ A JSON Schema resource is a schema which is canonically identified by an - absolute URI. Schema resources MAY - also be identified by URIs, including URIs with fragments, + 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 URIs + 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 - URI is determined as described in section + IRI is determined as described in section . Note that documents that embed schemas in another format will not @@ -502,7 +503,7 @@ fragment identifier structure: JSON Pointers. - The use of JSON Pointers as URI fragment identifiers is described in + 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, @@ -658,9 +659,9 @@ schema object with no subschemas. - 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 @@
- 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 references, or both. The Core vocabulary defined in this document defines several identifying keywords, most notably "$id". - 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. 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. @@ -933,7 +934,7 @@ such as "$ref" were followed to reach the absolute schema location. - 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. @@ -1137,15 +1138,15 @@ 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. - The current URI for the Core vocabulary is: - <https://json-schema.org/draft/2020-12/vocab/core>. + The current IRI for the Core vocabulary is: + <https://json-schema.org/draft/next/vocab/core>. - The current URI for the corresponding meta-schema is: - . + The current IRI for the corresponding meta-schema is: + . While the "$" prefix is not formally reserved for the Core vocabulary, @@ -1196,12 +1197,12 @@ set of valid schemas written for this particular dialect. - 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. + 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 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". @@ -1228,15 +1229,15 @@ 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. - 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. Vocabulary documents may be added in forthcoming drafts. For now, identifying the keyword set is deemed sufficient as that, @@ -1277,7 +1278,7 @@ 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. @@ -1317,60 +1318,60 @@
-
+
- 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.
-
+
To differentiate between schemas in a vast ecosystem, schemas are - identified by URI, and can embed references - to other schemas by specifying their URI. + identified by IRI, and can embed references + to other schemas by specifying their IRI. - 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. + 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 URI. + canonical IRI. - 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. If present, the value for this keyword MUST be a string, and MUST represent a - valid URI-reference. This URI-reference + valid IRI-reference. This IRI-reference SHOULD be normalized, and MUST resolve to an - absolute-URI (without a fragment), - or to a URI with an empty fragment. + absolute-IRI (without a fragment), + or to a IRI with an empty fragment. 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 RFC 3986 normalization process, - implementers and schema authors cannot rely on generic URI libraries + implementers and schema authors cannot rely on generic IRI libraries understanding it. 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. An empty fragment is currently allowed because older meta-schemas have an empty fragment in their $id (or previously, id). @@ -1378,28 +1379,30 @@ - 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 - RFC 3986 section 5.1.1 regarding base URIs + 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 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 + 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. 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 previous section.
The root schema of a JSON Schema document SHOULD contain an "$id" keyword - with an absolute-URI (containing a scheme, + with an absolute-IRI (containing a scheme, but no fragment).
@@ -1415,17 +1418,19 @@ 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". - 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 + RFC 3987 and + RFC 3986. - 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 @@ NCName production. 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. @@ -1466,17 +1471,17 @@ keywords, applying the referenced schema to the instance. - 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. - 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.
@@ -1489,8 +1494,8 @@ - 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. @@ -1505,27 +1510,22 @@ 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". - 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 + 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. - 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". - - - Otherwise, its behavior is identical to "$ref", and no runtime - resolution is needed. + 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 appendix @@ -1616,44 +1616,47 @@
-
+
- RFC3986 Section 5.1 defines how to determine the - default base URI of a document. + 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 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. - 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 + RFC 3987 Section 6.5 and 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. + 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 URI is determined according to the rules of that + 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 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.
- 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. When schemas are downloaded, @@ -1661,17 +1664,17 @@ 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 + 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 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.
@@ -1703,14 +1706,14 @@
- 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 RFC 3986. - 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. @@ -1741,7 +1744,7 @@ 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>. When an implementation then looks inside the <#/items> schema, it @@ -1767,10 +1770,10 @@
- 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. Conceptually, a set of linked schema resources should behave @@ -1780,10 +1783,10 @@ subschemas. - 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.
@@ -1804,20 +1807,20 @@
- 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". 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".
Now consider the following two schema resources linked by reference - using a URI value for "$ref": + using a IRI value for "$ref": 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.
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. 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. 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 +1876,8 @@ - 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 .
@@ -1895,13 +1898,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. - 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. When the Schema Resource referenced by a by-reference applicator is bundled, it is RECOMMENDED that @@ -1922,7 +1925,7 @@ 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. @@ -2092,15 +2095,15 @@ 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. - The current URI for this vocabulary, known as the Applicator vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/applicator>. + The current IRI for this vocabulary, known as the Applicator vocabulary, is: + <https://json-schema.org/draft/next/vocab/applicator>. - The current URI for the corresponding meta-schema is: - . + The current IRI for the corresponding meta-schema is: + .
@@ -2297,6 +2300,25 @@ 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. + +
@@ -2367,37 +2389,6 @@ Implementations that do not support annotation collection MUST do so.
- -
- - 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 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. - - - 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. - - - 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. - -
@@ -2509,6 +2500,48 @@
+ +
+ +
+ + 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. + + + 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. + + + 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, 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. + +
+
@@ -2545,16 +2578,16 @@ 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. - 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>. + <https://json-schema.org/draft/next/vocab/unevaluated>. - The current URI for the corresponding meta-schema is: - . + The current IRI for the corresponding meta-schema is: + .
@@ -2570,7 +2603,7 @@ "unevaluatedProperties", whose behavior is defined in terms of annotations from "properties", "patternProperties", - "additionalProperties" and itself + "additionalProperties", "contains", and itself @@ -2627,9 +2660,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 in-place applicator keywords. This includes but is not limited to the in-place applicators @@ -2638,7 +2671,7 @@ 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. @@ -2648,7 +2681,7 @@ 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. @@ -2726,9 +2759,15 @@
- 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". + + 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. +
@@ -2742,22 +2781,22 @@ due to the inclusion of these by-reference applicator keywords. - The JSON key for this information is "keywordLocation". + The JSON key for this information is "evaluationPath".
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. 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. @@ -2771,10 +2810,10 @@ https://example.com/schemas/common#/$defs/count/minimum 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". - The JSON key for this information is "absoluteKeywordLocation". + The JSON key for this information is "schemaLocation".
@@ -2808,13 +2847,15 @@ https://example.com/schemas/common#/$defs/count/minimum
- 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. - 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. + + + The JSON key for nested results is "nested".
@@ -2824,19 +2865,14 @@ https://example.com/schemas/common#/$defs/count/minimum 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. "valid" - a boolean value indicating the overall validation success or failure - "errors" - the collection of errors or annotations produced by a failed - validation - - - "annotations" - the collection of errors or annotations produced by a - successful validation + "nested" - the collection of errors or annotations produced by a keyword For these examples, the following schema and instance will be used. @@ -2846,7 +2882,7 @@ https://example.com/schemas/common#/$defs/count/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: - . + here for brevity. The IRI of the full output structure of the example above is: + .
@@ -3067,7 +3103,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, @@ -3084,27 +3120,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." } @@ -3120,8 +3156,8 @@ https://example.com/schemas/common#/$defs/count/minimum
For convenience, JSON Schema has been provided to validate output generated - by implementations. Its URI is: - . + by implementations. Its IRI is: + .
@@ -3236,6 +3272,7 @@ https://example.com/schemas/common#/$defs/count/minimum &RFC2119; &RFC3986; + &RFC3987; &RFC6839; &RFC6901; &RFC8259; @@ -3349,9 +3386,9 @@ https://example.com/schemas/common#/$defs/count/minimum
- The schemas at the following URI-encoded JSON + The schemas at the following IRI-encoded JSON Pointers (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 and above. @@ -3359,76 +3396,76 @@ https://example.com/schemas/common#/$defs/count/minimum - + https://example.com/root.json - + 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/other.json# - + https://example.com/root.json#/$defs/B - https://example.com/other.json - + 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 @@ -3436,11 +3473,11 @@ 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. + 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" 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 JSON Pointer fragments and embedded schema resources section for futher comments. @@ -3471,9 +3508,9 @@ 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 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. With these conditions met, each external resource can be copied @@ -3481,7 +3518,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.
@@ -3514,7 +3551,7 @@ 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: + present in each, resulting in the following full schema IRIs: "https://example.com/tree#node" "https://example.com/strict-tree#node" @@ -3561,9 +3598,9 @@ 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 "$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. @@ -3705,20 +3742,20 @@ https://example.com/schemas/common#/$defs/count/minimum @@ -3880,6 +3917,14 @@ https://example.com/schemas/common#/$defs/count/minimum + + + "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 diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index bbac5ca0..a8426471 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -177,20 +177,20 @@
- The current URI for the default JSON Schema dialect meta-schema is - . + 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 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. - 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. @@ -203,15 +203,15 @@ 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. - The current URI for this vocabulary, known as the Validation vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/validation>. + The current IRI for this vocabulary, known as the Validation vocabulary, is: + <https://json-schema.org/draft/next/vocab/validation>. - The current URI for the corresponding meta-schema is: - . + The current IRI for the corresponding meta-schema is: + .
@@ -414,13 +414,13 @@ then this keyword has no effect. - 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 "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. + result is a boolean "true" and the instance length (number of items or + properties) is less than or equal to the "maxContains" value.
@@ -433,13 +433,13 @@ then this keyword has no effect. - 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 "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. + 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 @@ -547,19 +547,19 @@ - The current URI 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: - . + 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 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: - . + <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. @@ -819,7 +819,7 @@ A string instance is valid against this attribute if it is - a valid URI, according to . + a valid IRI, according to . A string instance is valid against this attribute if it is a valid URI @@ -920,15 +920,15 @@ 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. - The current URI for this vocabulary, known as the Content vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/content>. + The current IRI for this vocabulary, known as the Content vocabulary, is: + <https://json-schema.org/draft/next/vocab/content>. - The current URI for the corresponding meta-schema is: - . + The current IRI for the corresponding meta-schema is: + .
@@ -1127,15 +1127,15 @@ 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. - The current URI for this vocabulary, known as the Meta-Data vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/meta-data>. + The current IRI for this vocabulary, known as the Meta-Data vocabulary, is: + <https://json-schema.org/draft/next/vocab/meta-data>. - The current URI for the corresponding meta-schema is: - . + The current IRI for the corresponding meta-schema is: + .
@@ -1442,6 +1442,11 @@ + + + Use IRIs instead of URIs + + Improve and clarify the "minContains" keyword explanation diff --git a/meta/applicator.json b/meta/applicator.json index ca699230..1b2f8c2e 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", @@ -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" }, 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 dfc092d9..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", @@ -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" } } } 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/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": "" } ] diff --git a/schema.json b/schema.json index d5e2d31c..066d86b9 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", @@ -51,7 +51,8 @@ }, "$recursiveRef": { "$comment": "\"$recursiveRef\" has been replaced by \"$dynamicRef\".", - "$ref": "meta/core#/$defs/uriReferenceString", + "type": "string", + "format": "uri-reference", "deprecated": true } }