diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ddeda4cd..3e21ad31 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -22,7 +22,7 @@ If the pull request would solve a particular issue, reference the issue in the p Changes that would affect implementation behavior should typically be opened as an issue first. -Pull requests should be made to master. +Pull requests should be made to the default branch, which may be `draft-patch`, `draft-next`, or `master` depending on where we are in the [release process](https://github.com/json-schema-org/community/discussions/7). Most PRs, including all PRs that impact implementation behavior, will be left open for a minimum of 14 days. Minor wording fixes may be merged more quickly once approved by a project member. @@ -78,4 +78,4 @@ Support this project with your organization. Your logo will show up here with a - \ 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 a93c377d..77e62e91 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -2,6 +2,7 @@ + @@ -180,17 +181,14 @@
- A JSON document is an information resource (series of octets) described by the - application/json media type. - - - In JSON Schema, the terms "JSON document", "JSON text", and "JSON value" are - interchangeable because of the data model it defines. + A JSON document represents the data underlying a given "JSON text" or "JSON value". + Thus in JSON Schema, the terms "JSON document", "JSON text", and "JSON value" are + interchangeable because of the data model defined in . JSON Schema is only defined over JSON documents. However, any document or memory structure that can be parsed into or processed according to the JSON Schema data - model can be interpreted against a JSON Schema, including media types like + model can be interpreted against a JSON Schema, including data formats like CBOR.
@@ -205,10 +203,10 @@ 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. -
+
JSON Schema interprets documents according to a data model. A JSON value interpreted according to this data model is called an "instance". @@ -316,7 +314,7 @@ control schema identification through setting the schema's - canonical URI and/or changing how the base URI is determined + canonical IRI and/or changing how the base IRI is determined produce a boolean result when applied to an instance @@ -393,7 +391,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 @@ -419,12 +417,12 @@ A JSON Schema resource is a schema which is canonically identified by an - absolute URI. + absolute IRI. 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 . @@ -482,7 +480,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, @@ -638,9 +636,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. @@ -725,20 +723,20 @@
- Identifiers set the canonical URI of a schema, or affect how such URIs are + Identifiers set the canonical IRI of 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. @@ -913,7 +911,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. @@ -1117,15 +1115,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, @@ -1176,12 +1174,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". @@ -1208,15 +1206,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, @@ -1257,7 +1255,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. @@ -1297,51 +1295,51 @@
-
+
- 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). Therefore, + absolute-IRI (without a fragment). Therefore, "$id" MUST NOT contain a non-empty fragment, and SHOULD NOT contain an empty fragment. Since an empty fragment in the context of the application/schema+json media - type refers to the same resource as the base URI without a fragment, - an implementation MAY normalize a URI ending with an empty fragment by removing + type refers to the same resource as the base IRI without a fragment, + an implementation MAY normalize a IRI ending with an empty fragment by removing the fragment. However, schema authors SHOULD NOT rely on this behavior across implementations. @@ -1351,28 +1349,30 @@ - This URI also serves as the base URI for relative URI-references in keywords + This IRI also serves as the base IRI for relative IRI-references in keywords within the schema resource, in accordance with + RFC 3987 section 6.5 and RFC 3986 section 5.1.1 regarding base URIs embedded in content. The presence of "$id" in a subschema indicates that the subschema constitutes a distinct schema resource within a single schema document. Furthermore, - in accordance with RFC 3986 section 5.1.2 - regarding encapsulating entities, if an "$id" in a subschema is a relative - URI-reference, the base URI for resolving that reference is the URI of + 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).
@@ -1388,17 +1388,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, @@ -1420,8 +1422,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. @@ -1439,17 +1441,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.
@@ -1462,8 +1464,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. @@ -1478,27 +1480,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 @@ -1589,44 +1586,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 the next 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, @@ -1634,17 +1634,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.
@@ -1676,14 +1676,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. @@ -1714,7 +1714,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 @@ -1740,10 +1740,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 the containing resource's URI. + canonical IRI, or relative to the containing resource's IRI. Conceptually, a set of linked schema resources should behave @@ -1753,10 +1753,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.
@@ -1776,16 +1776,16 @@ ]]> - The URI "https://example.com/foo#/items/additionalProperties" + The IRI "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, + the embedded resource. The canonical IRI of that schema, however, is "https://example.com/bar#/additionalProperties".
Now consider the following two schema resources linked by reference - using a URI value for "$ref": + using a IRI value for "$ref": - Here we see that the canonical URI for that "additionalProperties" - subschema is still valid, while the non-canonical URI with the fragment + Here we see that the canonical IRI for that "additionalProperties" + subschema is still valid, while the non-canonical IRI with the fragment beginning with "#/items/$ref" now resolves to nothing.
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, + arrangements, but resolves to a different value. This IRI ends up + functioning similarly to a retrieval IRI for a resource. While valid, examining the resolved value and either using the "$id" (if the value is a subschema), or resolving the reference and using the "$id" of the reference target, is preferable. An implementation MAY choose not to support addressing schemas - by non-canonical URIs. As such, it is RECOMMENDED that schema authors only - use canonical URIs, as using non-canonical URIs may reduce + by non-canonical IRIs. As such, it is RECOMMENDED that schema authors only + use canonical IRIs, as using non-canonical IRIs 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, + stack of possible base IRIs and JSON Pointer fragments for each, given that all but one will be fragile if the schema resources are reorganized. Some have argued that this is easy so there is no point in forbidding it, while others have argued that it complicates @@ -1832,8 +1832,8 @@ - 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 IRIs, as well as the appropriate + canonical IRIs to use instead, are provided in appendix .
@@ -1854,13 +1854,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 @@ -1881,7 +1881,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. @@ -2051,20 +2051,20 @@ 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: + . - 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. @@ -2330,32 +2330,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. 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. - - - 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. - -
@@ -2450,6 +2424,42 @@
+ +
+
+ + 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. 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. + + + An object instance is valid against "contains" if at least one of + its property values is valid against the given schema. The subschema + MUST be applied to every property value even after the first match has + been found, in order to collect annotations for use by other keywords. + This is to ensure that all possible annotations are collected. + + + Logically, the validation result of applying the value subschema to each + item in the array or property in the object MUST be ORed with "false", + resulting in an overall validation result. + + + 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. + +
+
@@ -2486,16 +2496,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: - . + . Updated vocabulary and meta-schema URIs MAY be published between @@ -2518,7 +2528,7 @@ "unevaluatedProperties", whose behavior is defined in terms of annotations from "properties", "patternProperties", - "additionalProperties" and itself + "additionalProperties", "contains", and itself @@ -2574,9 +2584,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 @@ -2585,7 +2595,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. @@ -2595,7 +2605,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. @@ -2695,15 +2705,15 @@
The absolute, dereferenced location of the validating keyword. The value MUST - be expressed as a full URI using the canonical URI of the relevant + be expressed as a full IRI using the canonical IRI of the relevant schema object, and it MUST NOT include by-reference applicators such as "$ref" or "$dynamicRef" as 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. @@ -2717,7 +2727,7 @@ 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". @@ -2792,7 +2802,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: + .
@@ -3013,7 +3023,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, @@ -3066,8 +3076,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: + .
@@ -3125,7 +3135,7 @@ https://example.com/schemas/common#/$defs/count/minimum Optional parameters: - A non-empty list of space-separated URIs, each identifying + A non-empty list of space-separated IRIs, 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 @@ -3169,7 +3179,7 @@ https://example.com/schemas/common#/$defs/count/minimum Required parameters: - A non-empty list of space-separated URIs, each identifying + A non-empty list of space-separated IRIs, 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 @@ -3209,6 +3219,7 @@ https://example.com/schemas/common#/$defs/count/minimum &RFC2119; &RFC3986; + &RFC3987; &RFC6839; &RFC6901; &RFC8259; @@ -3324,7 +3335,7 @@ https://example.com/schemas/common#/$defs/count/minimum The schemas at the following URI-encoded JSON Pointers (relative to the root schema) have the following - base URIs, and are identifiable by any listed URI in accordance with + base IRIs, and are identifiable by any listed IRI in accordance with sections and above. @@ -3332,76 +3343,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 @@ -3432,8 +3443,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 + all static references (e.g. "$ref") use IRI-references that resolve + to canonical IRIs, and all schema resources have an absolute-IRI as the "$id" in their root schema. @@ -3442,7 +3453,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 canonical IRIs for the embedded resources.
@@ -3475,7 +3486,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" @@ -3522,9 +3533,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. @@ -3666,19 +3677,19 @@ https://example.com/schemas/common#/$defs/count/minimum @@ -3841,6 +3852,12 @@ https://example.com/schemas/common#/$defs/count/minimum + + + "contains" now applies to objects as well as arrays + Remove bookending requirement for "$dynamicRef" + + "$schema" MAY change for embedded resources diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index e12c6cd2..990ec15b 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -177,7 +177,7 @@
The current URI 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, @@ -206,11 +206,11 @@ The current URI for this vocabulary, known as the Validation vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/validation>. + <https://json-schema.org/draft/next/vocab/validation>. The current URI for the corresponding meta-schema is: - . + .
@@ -413,13 +413,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.
@@ -432,13 +432,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 @@ -546,18 +546,18 @@ 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 + <https://json-schema.org/draft/next/vocab/format-annotation>. The current URI 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 Format-Assertion vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/format-assertion>. The current + <https://json-schema.org/draft/next/vocab/format-assertion>. The current URI for the corresponding meta-schema is: - . + . Implementing support for the Format-Assertion vocabulary is OPTIONAL. @@ -918,11 +918,11 @@ The current URI for this vocabulary, known as the Content vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/content>. + <https://json-schema.org/draft/next/vocab/content>. The current URI for the corresponding meta-schema is: - . + .
@@ -1118,11 +1118,11 @@ The current URI for this vocabulary, known as the Meta-Data vocabulary, is: - <https://json-schema.org/draft/2020-12/vocab/meta-data>. + <https://json-schema.org/draft/next/vocab/meta-data>. The current URI for the corresponding meta-schema is: - . + .
diff --git a/meta/applicator.json b/meta/applicator.json index ca699230..948f4193 100644 --- a/meta/applicator.json +++ b/meta/applicator.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://json-schema.org/draft/2020-12/meta/applicator", + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/draft/next/meta/applicator", "$vocabulary": { - "https://json-schema.org/draft/2020-12/vocab/applicator": true + "https://json-schema.org/draft/next/vocab/applicator": true }, "$dynamicAnchor": "meta", diff --git a/meta/content.json b/meta/content.json index 2f6e056a..2c29ee50 100644 --- a/meta/content.json +++ b/meta/content.json @@ -1,8 +1,8 @@ { - "$schema": "https://json-schema.org/draft/2020-12/schema", - "$id": "https://json-schema.org/draft/2020-12/meta/content", + "$schema": "https://json-schema.org/draft/next/schema", + "$id": "https://json-schema.org/draft/next/meta/content", "$vocabulary": { - "https://json-schema.org/draft/2020-12/vocab/content": true + "https://json-schema.org/draft/next/vocab/content": true }, "$dynamicAnchor": "meta", diff --git a/meta/core.json b/meta/core.json index 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/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 } }