JSON Schema defines the media type "application/schema+json", a JSON-based format for describing the structure of JSON data. JSON Schema asserts what a JSON document must look like, ways to extract information from it, and how to interact with it. The "application/schema-instance+json" media type provides additional feature-rich integration with "application/schema+json" beyond what can be offered for "application/json" documents.
This document a pre-release identified as JSON Schema draft 2020-12-rc-1.
The issues list for this draft can be found at <https://github.com/json-schema-org/json-schema-spec/issues>.
For additional information, see <https://json-schema.org/>.
To provide feedback, use this issue tracker, the communication methods listed on the homepage, or email the document editors.
@@ -550,7 +550,7 @@This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-This Internet-Draft will expire on June 4, 2021.
+This Internet-Draft will expire on August 1, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
@@ -702,9 +702,11 @@Keywords MAY use regular expressions to express constraints, or constrain the instance value to be a regular expression. These regular expressions SHOULD be valid according to the regular expression dialect described in ECMA-262, section 21.2.1.
-Regular expressions SHOULD be built with the "u" flag (or equivalent) to provide Unicode support, or processed in such a way which provides Unicode as defined by ECMA-262.
+Regular expressions SHOULD be built with the "u" flag (or equivalent) to provide Unicode support, or processed in such a way which provides Unicode support as defined by ECMA-262.
Furthermore, given the high disparity in regular expression constructs support, schema authors SHOULD limit themselves to the following regular expression tokens:
The lexical scope of a keyword is determined by the nested JSON data structure of objects and arrays. The largest such scope is an entire schema document. The smallest scope is a single schema object with no subschemas.
Keywords MAY be defined with a partial value, such as a URI-reference, which must be resolved against another value, such as another URI-reference or a full URI, which is found through the lexical structure of the JSON document. The "$id", "$ref", and "$dynamicRef" core keywords, and the "base" JSON Hyper-Schema keyword, are examples of this sort of behavior.
Note that some keywords, such as "$schema", apply to the lexical scope of the entire schema resource, and therefore MUST only appear in a schema resource's root schema.
-Other keywords may take into account the dynamic scope that exists during the evaluation of a schema. The outermost dynamic scope is the root schema of the schema document in which processing begins. The path from this root schema to any particular keyword (that includes any "$ref" and "$dynamicRef" keywords that may have been resolved) is considered the keyword's "validation path."
+Other keywords may take into account the dynamic scope that exists during the evaluation of a schema, typically together with an instance document. The outermost dynamic scope is the schema object at which processing begins, even if it is not a schema resource root. The path from this root schema to any particular keyword (that includes any "$ref" and "$dynamicRef" keywords that may have been resolved) is considered the keyword's "validation path."
Lexical and dynamic scopes align until a reference keyword is encountered. While following the reference keyword moves processing from one lexical scope into a different one, from the perspective of dynamic scope, following a reference is no different from descending into a subschema present as a value. A keyword on the far side of that reference that resolves information through the dynamic scope will consider the originating side of the reference to be their dynamic parent, rather than examining the local lexically enclosing parent.
The concept of dynamic scope is primarily used with "$dynamicRef" and "$dynamicAnchor", and should be considered an advanced feature and used with caution when defining additional keywords. It also appears when reporting errors and collected annotations, as it may be possible to revisit the same lexical scope repeatedly with different dynamic scopes. In such cases, it is important to inform the user of the dynamic path that produced the error or annotation.
Identifiers set the canonical URI of a schema, or affect how such URIs are resolved in references, or both. The Core vocabulary defined in this document defines several identifying keywords, most notably "$id".
-Canonical schema URIs MUST NOT change while processing an instance, but keywords that affect URI-reference resolution MAY have behavior that is only fully determined dynamically.
+Canonical schema URIs MUST NOT change while processing an instance, but keywords that affect URI-reference resolution MAY have behavior that is only fully determined at runtime.
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 effects to the matching "$dynamicRef" keyword, leaving the behavior of "$ref" undisturbed.
As noted in Section 7.5, an applicator keyword may refer to a schema to be applied, rather than including it as a subschema in the applicator's value. In such situations, the schema being applied is known as the referenced schema, while the schema containing the applicator keyword is the referencing schema.
While root schemas and subschemas are static concepts based on a schema's position within a schema document, referenced and referencing schemas are dynamic. Different pairs of schemas may find themselves in various referenced and referencing arrangements during the evaluation of an instance against a schema.
-For some by-reference applicators, such as "$ref", the referenced schema can be determined by static analysis of the schema document's lexical scope. Others, such as "$dynamicRef" (with "$dynamicAnchor"), are only resolvable with knowledge of all the schemas in it's dynamic scope.
+For some by-reference applicators, such as "$ref", the referenced schema can be determined by static analysis of the schema document's lexical scope. Others, such as "$dynamicRef" (with "$dynamicAnchor"), may make use of dynamic scoping, and therefore only be resolvable in the process of evaluating the schema with an instance.
The "$ref" keyword is an applicator that is used to reference a statically identified schema. Its results are the results of the referenced schema. [CREF5]Note that this definition of how the results are determined means that other keywords can appear alongside of "$ref" in the same schema object.
-The value of the "$ref" keyword MUST be a string which is a URI-Reference. Resolved against the current URI base, it produces the URI of the schema to apply. This resolution is safe to perform on schema load as neither other schemas nor the instance can change how the reference resolves.
+The value of the "$ref" keyword MUST be a string which is a URI-Reference. Resolved against the current URI base, it produces the URI of the schema to apply. This resolution is safe to perform on schema load, as the process of evaluating an instance cannot change how the reference resolves.
The "$dynamicRef" keyword is an applicator that is used to reference a dynamically identified schema.
-Together with "$dynamicAnchor", "$dynamicRef" implements a cooperative extension mechanism that is primarily useful with recursive schemas (schemas that reference themselves). Both the extension point and the extension target are defined with "$dynamicAnchor", and only exhibit dynamic behavior when referenced with "$dynamicRef".
-The value of the "$dynamicRef" property MUST be a string which is a URI-Reference. Resolved against the current URI base, it produces the URI used as the starting point for resolution. This initial resolution is safe to perform on schema load.
+The "$dynamicRef" keyword is an applicator that allows for deferring the full resolution until runtime, at which point it is resolved each time it is encountered while evaluating an instance.
+Together with "$dynamicAnchor", "$dynamicRef" implements a cooperative extension mechanism that is primarily useful with recursive schemas (schemas that reference themselves). Both the extension point and the runtime-determined extension target are defined with "$dynamicAnchor", and only exhibit runtime dynamic behavior when referenced with "$dynamicRef".
+The value of the "$dynamicRef" property MUST be a string which is a URI-Reference. Resolved against the current URI base, it produces the URI used as the starting point for runtime resolution. This initial resolution is safe to perform on schema load.
If the initially resolved starting point URI includes a fragment that 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 dynamic resolution is needed.
+Otherwise, its behavior is identical to "$ref", and no runtime resolution is needed.
For a full example using these keyword, see appendix C. [CREF6]The difference between the hyper-schema meta-schema in pre-2019 drafts and an this draft dramatically demonstrates the utility of these keywords.
The use of URIs to identify remote schemas does not necessarily mean anything is downloaded, but instead JSON Schema implementations SHOULD understand ahead of time which schemas they will be using, and the URIs that identify them.
-When schemas are downloaded, for example by a generic user-agent that doesn't know until runtime which schemas to download, see Usage for Hypermedia.
+When schemas are downloaded, for example by a generic user-agent that does not know until runtime which schemas to download, see Usage for Hypermedia.
Implementations SHOULD be able to associate arbitrary URIs with an arbitrary schema and/or automatically associate a schema's "$id"-given URI, depending on the trust that the validator has in the schema. Such URIs and schemas can be supplied to an implementation prior to processing instances, or may be noted within a schema document as it is processed, producing associations as shown in appendix A.
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.
@@ -1514,20 +1515,20 @@
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 validated successfully when applied to every index of the instance. If the instance array this keywords subschema is applicable to is empty, the annotation value MUST NOT be missing.
+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.
The value of "properties" MUST be an object. Each value of this object MUST be a valid JSON Schema.
Validation succeeds if, for each name that appears in both the instance and as a name within this keyword's value, the child instance for that name successfully validates against the corresponding schema.
-The annotation result of this keyword is the set of instance property names matched by this keyword. Annotation results for "properties" keywords from multiple schemas applied to the same instance location are combined by taking the union of the sets.
+The annotation result of this keyword is the set of instance property names matched by this keyword.
Omitting this keyword has the same assertion behavior as an empty object.
The value of "patternProperties" MUST be an object. Each property name of this object SHOULD be a valid regular expression, according to the ECMA-262 regular expression dialect. Each property value of this object MUST be a valid JSON Schema.
Validation succeeds if, for each instance name that matches any regular expressions that appear as a property name in this keyword's value, the child instance for that name successfully validates against each schema that corresponds to a matching regular expression.
-The annotation result of this keyword is the set of instance property names matched by this keyword. Annotation results for "patternProperties" keywords from multiple schemas applied to the same instance location are combined by taking the union of the sets.
+The annotation result of this keyword is the set of instance property names matched by this keyword.
Omitting this keyword has the same assertion behavior as an empty object.
The value of "additionalProperties" MUST be a valid JSON Schema.
The behavior of this keyword depends on the presence and annotation results of "properties" and "patternProperties" within the same schema object. Validation with "additionalProperties" applies only to the child values of instance names that do not appear in the annotation results of either "properties" or "patternProperties".
For all such properties, validation succeeds if the child instance validates against the "additionalProperties" schema.
-The annotation result of this keyword is the set of instance property names validated by this keyword's subschema. Annotation results for "additionalProperties" keywords from multiple schemas applied to the same instance location are combined by taking the union of the sets.
+The annotation result of this keyword is the set of instance property names validated by this keyword's subschema.
Omitting this keyword has the same assertion behavior as an empty schema.
Implementations MAY choose to implement or optimize this keyword in another way that produces the same effect, such as by directly checking the names in "properties" and the patterns in "patternProperties" against the instance property set. Implementations that do not support annotation collection MUST do so.
The current URI for the corresponding meta-schema is: <https://json-schema.org/draft/2020-12/meta/unevaluated>.
Updated vocabulary and meta-schema URIs MAY be published between specification drafts in order to correct errors. Implementations SHOULD consider URIs dated after this specification draft and before the next to indicate the same syntax and semantics as those listed here.
The value of "unevaluatedItems" MUST be a valid JSON Schema.
-The behavior of this keyword depends on the annotation results of adjacent keywords that apply to the instance location being validated. Specifically, the annotations from "prefixItems", "items", and "contains", which can come from those keywords when they are adjacent to the "unevaluatedItems" keyword. Those two annotations, as well as "unevaluatedItems", can also result from any and all adjacent in-place applicator keywords. This includes but is not limited to the in-place applicators defined in this document.
-If no relevant annotations are present, the "unevaluatedItems" subschema MUST be applied to all locations in the array. If a boolean true value is present from any of the relevant annotations, "unevaluatedItems" MUST be ignored. Otherwise, the subschema MUST be applied to any index greater than the largest annotation value for "prefixItems", which does not appear in any annotation value for "contains".
-This means that "prefixItems", "items", "contains", and all in-place applicators MUST be evaluated before this keyword can be evaluated. Authors of extension keywords MUST NOT define an in-place applicator that would need to be evaluated before this keyword.
-If the "unevaluatedItems" subschema is applied to any positions within the instance array, it produces an annotation result of boolean true, analogous to the behavior of "items".
-Omitting this keyword has the same assertion behavior as an empty schema.
+11.1. Keyword Independence +Schema keywords typically operate independently, without affecting each other's outcomes. However, the keywords in this vocabulary are notable exceptions:
+ +
The value of "unevaluatedItems" MUST be a valid JSON Schema.
+The behavior of this keyword depends on the annotation results of adjacent keywords that apply to the instance location being validated. Specifically, the annotations from "prefixItems", "items", and "contains", which can come from those keywords when they are adjacent to the "unevaluatedItems" keyword. Those three annotations, as well as "unevaluatedItems", can also result from any and all adjacent in-place applicator keywords. This includes but is not limited to the in-place applicators defined in this document.
+If no relevant annotations are present, the "unevaluatedItems" subschema MUST be applied to all locations in the array. If a boolean true value is present from any of the relevant annotations, "unevaluatedItems" MUST be ignored. Otherwise, the subschema MUST be applied to any index greater than the largest annotation value for "prefixItems", which does not appear in any annotation value for "contains".
+This means that "prefixItems", "items", "contains", and all in-place applicators MUST be evaluated before this keyword can be evaluated. Authors of extension keywords MUST NOT define an in-place applicator that would need to be evaluated after this keyword.
+If the "unevaluatedItems" subschema is applied to any positions within the instance array, it produces an annotation result of boolean true, analogous to the behavior of "items".
+Omitting this keyword has the same assertion behavior as an empty schema.
+The value of "unevaluatedProperties" MUST be a valid JSON Schema.
-The behavior of this keyword depends on the annotation results of adjacent keywords that apply to the instance location being validated. Specifically, the annotations from "properties", "patternProperties", and "additionalProperties", which can come from those keywords when they are adjacent to the "unevaluatedProperties" keyword. Those three annotations, as well as "unevaluatedProperties", can also result from any and all adjacent in-place applicator keywords. This includes but is not limited to the in-place applicators defined in this document.
-Validation with "unevaluatedProperties" applies only to the child values of instance names that do not appear in the "properties", "patternProperties", "additionalProperties", or "unevaluatedProperties" annotation results that apply to the instance location being validated.
-For all such properties, validation succeeds if the child instance validates against the "unevaluatedProperties" schema.
-This means that "properties", "patternProperties", "additionalProperties", and all in-place applicators MUST be evaluated before this keyword can be evaluated. Authors of extension keywords MUST NOT define an in-place applicator that would need to be evaluated before this keyword.
-The annotation result of this keyword is the set of instance property names validated by this keyword's subschema. Annotation results for "unevaluatedProperties" keywords from multiple schemas applied to the same instance location are combined by taking the union of the sets.
-Omitting this keyword has the same assertion behavior as an empty schema.
+The value of "unevaluatedProperties" MUST be a valid JSON Schema.
+The behavior of this keyword depends on the annotation results of adjacent keywords that apply to the instance location being validated. Specifically, the annotations from "properties", "patternProperties", and "additionalProperties", which can come from those keywords when they are adjacent to the "unevaluatedProperties" keyword. Those three annotations, as well as "unevaluatedProperties", can also result from any and all adjacent in-place applicator keywords. This includes but is not limited to the in-place applicators defined in this document.
+Validation with "unevaluatedProperties" applies only to the child values of instance names that do not appear in the "properties", "patternProperties", "additionalProperties", or "unevaluatedProperties" annotation results that apply to the instance location being validated.
+For all such properties, validation succeeds if the child instance validates against the "unevaluatedProperties" schema.
+This means that "properties", "patternProperties", "additionalProperties", and all in-place applicators MUST be evaluated before this keyword can be evaluated. Authors of extension keywords MUST NOT define an in-place applicator that would need to be evaluated after this keyword.
+The annotation result of this keyword is the set of instance property names validated by this keyword's subschema.
+Omitting this keyword has the same assertion behavior as an empty schema.
An implementation SHOULD provide at least the "flag", "basic", or "detailed" format and MAY provide the "verbose" format. If it provides one or more of the complex formats, it MUST also provide the "flag" format. Implementations SHOULD specify in their documentation which formats they support.
+An implementation SHOULD provide at least one of the "flag", "basic", or "detailed" format and MAY provide the "verbose" format. If it provides one or more of the "detailed" or "verbose" formats, it MUST also provide the "flag" format. Implementations SHOULD specify in their documentation which formats they support.
Beyond the simplistic "flag" output, additional information is useful to aid in debugging a schema or instance. Each sub-result SHOULD contain the information contained within this section at a minimum.
@@ -1609,13 +1620,13 @@The JSON key for this information is "keywordLocation".
The absolute, dereferenced location of the validating keyword. The value MUST be expressed as a full URI using the canonical URI of the relevant schema object, and it MUST NOT include by-reference applicators 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. [CREF12]Note that "absolute" here is in the sense of "absolute filesystem path" (meaning the complete location) rather than the "absolute-URI" terminology from RFC 3986 (meaning with scheme but without fragment). Keyword absolute locations will always have a fragment in order to identify the keyword.
+The absolute, dereferenced location of the validating keyword. The value MUST be expressed as a full URI using the canonical URI of the relevant schema object, and it MUST NOT include by-reference applicators 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. [CREF12]Note that "absolute" here is in the sense of "absolute filesystem path" (meaning the complete location) rather than the "absolute-URI" terminology from RFC 3986 (meaning with scheme but without fragment). Keyword absolute locations will have a fragment in order to identify the keyword.
https://example.com/schemas/common#/$defs/count/minimum
-This information MAY be omitted only if either the relative location contains no references or if the schema does not declare an absolute URI as its "$id".
+This information MAY be omitted only if either the dynamic scope did not pass over a reference or if the schema does not declare an absolute URI as its "$id".
The JSON key for this information is "absoluteKeywordLocation".
Both schemas and instances are JSON values. As such, all security considerations defined in RFC 8259 apply.
-Instances and schemas are both frequently written by untrusted third parties, to be deployed on public Internet servers. Validators should take care that the parsing and validating against schemas doesn't consume excessive system resources. Validators MUST NOT fall into an infinite loop.
+Instances and schemas are both frequently written by untrusted third parties, to be deployed on public Internet servers. Validators should take care that the parsing and validating against schemas does not consume excessive system resources. Validators MUST NOT fall into an infinite loop.
A malicious party could cause an implementation to repeatedly collect a copy of a very large value as an annotation. Implementations SHOULD guard against excessive consumption of system resources in such a scenario.
-Servers MUST ensure that malicious parties can't change the functionality of existing schemas by uploading a schema with a pre-existing or very similar "$id".
+Servers MUST ensure that malicious parties cannot change the functionality of existing schemas by uploading a schema with a pre-existing or very similar "$id".
Individual JSON Schema vocabularies are liable to also have their own security considerations. Consult the respective specifications for more information.
Schema authors should take care with "$comment" contents, as a malicious implementation can display them to end-users in violation of a spec, or fail to strip them if such behavior is expected.
A malicious schema author could place executable code or other dangerous material within a "$comment". Implementations MUST NOT parse or otherwise take action based on "$comment" contents.
@@ -2190,7 +2201,7 @@Vocabulary authors should take care to avoid keyword name collisions if the vocabulary is intended for broad use, and potentially combined with other vocabularies. JSON Schema does not provide any formal namespacing system, but also does not constrain keyword names, allowing for any number of namespacing approaches.
Vocabularies may build on each other, such as by defining the behavior of their keywords with respect to the behavior of keywords from another vocabulary, or by using a keyword from another vocabulary with a restricted or expanded set of acceptable values. Not all such vocabulary re-use will result in a new vocabulary that is compatible with the vocabulary on which it is built. Vocabulary authors should clearly document what level of compatibility, if any, is expected.
Meta-schema authors should not use "$vocabulary" to combine multiple vocabularies that define conflicting syntax or semantics for the same keyword. As semantic conflicts are not generally detectable through schema validation, implementations are not expected to detect such conflicts. If conflicting vocabularies are declared, the resulting behavior is undefined.
-Vocabulary authors should provide a meta-schema that validates the expected usage of the vocabulary's keywords on their own. Such meta-schemas should not forbid additional keywords, and must not forbid any keywords from the Core vocabulary.
+Vocabulary authors SHOULD provide a meta-schema that validates the expected usage of the vocabulary's keywords on their own. Such meta-schemas SHOULD not forbid additional keywords, and MUST not forbid any keywords from the Core vocabulary.
It is recommended that meta-schema authors reference each vocabulary's meta-schema using the "allOf" keyword, although other mechanisms for constructing the meta-schema may be appropriate for certain use cases.
The recursive nature of meta-schemas makes the "$dynamicAnchor" and "$dynamicRef" keywords particularly useful for extending existing meta-schemas, as can be seen in the JSON Hyper-Schema meta-schema which extends the Validation meta-schema.
Meta-schemas may impose additional constraints, including describing keywords not present in any vocabulary, beyond what the meta-schemas associated with the declared vocabularies describe. This allows for restricting usage to a subset of a vocabulary, and for validating locally defined keywords not intended for re-use.
@@ -2200,7 +2211,7 @@This meta-schema explicitly declares both the Core and Applicator vocabularies, together with an extension vocabulary, and combines their meta-schemas with an "allOf". The extension vocabulary's meta-schema, which describes only the keywords in that vocabulary, is shown after the main example meta-schema.
-The main example meta-schema also restricts the usage of the Applicator vocabulary by forbidding the keywords prefixed with "unevaluated", which are particularly complex to implement. This does not change the semantics or set of keywords defined by the Applicator vocabulary. It just ensures that schemas using this meta-schema that attempt to use the keywords prefixed with "unevaluated" will fail validation against this meta-schema.
+The main example meta-schema also restricts the usage of the Unevaluated vocabulary by forbidding the keywords prefixed with "unevaluated", which are particularly complex to implement. This does not change the semantics or set of keywords defined by the other vocabularies. It just ensures that schemas using this meta-schema that attempt to use the keywords prefixed with "unevaluated" will fail validation against this meta-schema.
Finally, this meta-schema describes the syntax of a keyword, "localKeyword", that is not part of any vocabulary. Presumably, the implementors and users of this meta-schema will understand the semantics of "localKeyword". JSON Schema does not define any mechanism for expressing keyword semantics outside of vocabularies, making them unsuitable for use except in a specific environment in which they are understood.
This meta-schema combines several vocabularies for general use.
@@ -2222,7 +2233,7 @@{"$ref": "https://example.com/meta/example-vocab", ], "patternProperties": { - "^unevaluated.*$": false + "^unevaluated": false }, "properties": { "localKeyword": { @@ -2311,9 +2322,10 @@
diff --git a/draft/preview/2020-12-rc-1/jsonschema-validation.html b/draft/2020-12/json-schema-validation.html similarity index 98% rename from draft/preview/2020-12-rc-1/jsonschema-validation.html rename to draft/2020-12/json-schema-validation.html index f203d3ec..e573655f 100644 --- a/draft/preview/2020-12-rc-1/jsonschema-validation.html +++ b/draft/2020-12/json-schema-validation.html @@ -451,7 +451,7 @@ - + @@ -475,7 +475,7 @@
JSON Schema (application/schema+json) has several purposes, one of which is JSON instance validation. This document specifies a vocabulary for JSON Schema to describe the meaning of JSON documents, provide hints for user interfaces working with JSON data, and to make assertions about what a valid document must look like.
This document a pre-release identified as JSON Schema draft 2020-12-rc-1.
The issues list for this draft can be found at <https://github.com/json-schema-org/json-schema-spec/issues>.
For additional information, see <https://json-schema.org/>.
To provide feedback, use this issue tracker, the communication methods listed on the homepage, or email the document editors.
@@ -505,7 +504,7 @@This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-This Internet-Draft will expire on June 4, 2021.
+This Internet-Draft will expire on August 1, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
@@ -777,12 +776,12 @@The value of this keyword MUST be a non-negative integer.
If "contains" is not present within the same schema object, then this keyword has no effect.
-An array instance is valid against "maxContains" if its value is less than or equal to, the array length of the annotation result from an adjacent "contains" keyword where the annotation is an array, or the length of the instance array where the annotation is "true".
+An instance array is valid against "maxContains" in two ways, depending on the form of the annotation result of an adjacent "contains" keyword. The first way is if the annotation result is an array and the length of that array is less than or equal to the "maxContains" value. The second way is if the annotation result is a boolean "true" and the instance array length is less than or equal to the "maxContains" value.
The value of this keyword MUST be a non-negative integer.
If "contains" is not present within the same schema object, then this keyword has no effect.
-An array instance is valid against "minContains" if its value is greater than or equal to, the array length of the annotation result from an adjacent "contains" keyword where the annotation is an array, or the length of the instance array where the annotation is "true".
+An instance array is valid against "minContains" in two ways, depending on the form of the annotation result of an adjacent "contains" keyword. The first way is if the annotation result is an array and the length of that array is greater than or equal to the "minContains" value. The second way is if the annotation result is a boolean "true" and the instance array length is greater than or equal to the "minContains" value.
A value of 0 is allowed, but is only useful for setting a range of occurrences from 0 to the value of "maxContains". A value of 0 with no "maxContains" causes "contains" to always pass validation.
Omitting this keyword has the same behavior as a value of 1.
diff --git a/draft/2020-12/meta/applicator b/draft/2020-12/meta/applicator new file mode 120000 index 00000000..8fd44f54 --- /dev/null +++ b/draft/2020-12/meta/applicator @@ -0,0 +1 @@ +../../../_includes/draft/2020-12/meta/applicator.json \ No newline at end of file diff --git a/draft/2020-12/meta/content b/draft/2020-12/meta/content new file mode 120000 index 00000000..784c2c5e --- /dev/null +++ b/draft/2020-12/meta/content @@ -0,0 +1 @@ +../../../_includes/draft/2020-12/meta/content.json \ No newline at end of file diff --git a/draft/2020-12/meta/core b/draft/2020-12/meta/core new file mode 120000 index 00000000..acdf0634 --- /dev/null +++ b/draft/2020-12/meta/core @@ -0,0 +1 @@ +../../../_includes/draft/2020-12/meta/core.json \ No newline at end of file diff --git a/draft/2020-12/meta/format-annotation b/draft/2020-12/meta/format-annotation new file mode 120000 index 00000000..1264ea08 --- /dev/null +++ b/draft/2020-12/meta/format-annotation @@ -0,0 +1 @@ +../../../_includes/draft/2020-12/meta/format-annotation.json \ No newline at end of file diff --git a/draft/2020-12/meta/format-assertion b/draft/2020-12/meta/format-assertion new file mode 120000 index 00000000..b31c612b --- /dev/null +++ b/draft/2020-12/meta/format-assertion @@ -0,0 +1 @@ +../../../_includes/draft/2020-12/meta/format-assertion.json \ No newline at end of file diff --git a/draft/2020-12/meta/meta-data b/draft/2020-12/meta/meta-data new file mode 120000 index 00000000..49e5296e --- /dev/null +++ b/draft/2020-12/meta/meta-data @@ -0,0 +1 @@ +../../../_includes/draft/2020-12/meta/meta-data.json \ No newline at end of file diff --git a/draft/2020-12/meta/unevaluated b/draft/2020-12/meta/unevaluated new file mode 120000 index 00000000..fbd3c938 --- /dev/null +++ b/draft/2020-12/meta/unevaluated @@ -0,0 +1 @@ +../../../_includes/draft/2020-12/meta/unevaluated.json \ No newline at end of file diff --git a/draft/2020-12/meta/validation b/draft/2020-12/meta/validation new file mode 120000 index 00000000..90f062f1 --- /dev/null +++ b/draft/2020-12/meta/validation @@ -0,0 +1 @@ +../../../_includes/draft/2020-12/meta/validation.json \ No newline at end of file diff --git a/draft/2020-12/output/schema b/draft/2020-12/output/schema new file mode 120000 index 00000000..efe176a0 --- /dev/null +++ b/draft/2020-12/output/schema @@ -0,0 +1 @@ +../../../_includes/draft/2020-12/output/schema.json \ No newline at end of file diff --git a/draft/2020-12/output/verbose-example b/draft/2020-12/output/verbose-example new file mode 120000 index 00000000..38f31932 --- /dev/null +++ b/draft/2020-12/output/verbose-example @@ -0,0 +1 @@ +../../../_includes/draft/2020-12/output/verbose-example.json \ No newline at end of file diff --git a/draft/preview/2020-12-rc-1/relative-json-pointer.html b/draft/2020-12/relative-json-pointer.html similarity index 97% rename from draft/preview/2020-12-rc-1/relative-json-pointer.html rename to draft/2020-12/relative-json-pointer.html index d1fd75de..fe44bd8a 100644 --- a/draft/preview/2020-12-rc-1/relative-json-pointer.html +++ b/draft/2020-12/relative-json-pointer.html @@ -397,7 +397,7 @@ - + @@ -421,7 +421,7 @@
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
-This Internet-Draft will expire on June 4, 2021.
+This Internet-Draft will expire on August 1, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
@@ -505,8 +505,9 @@The ABNF syntax of a Relative JSON Pointer is:
- relative-json-pointer = non-negative-integer <json-pointer>
+ relative-json-pointer = non-negative-integer [index-manipulation] <json-pointer>
relative-json-pointer =/ non-negative-integer "#"
+ index-manipulation = ("+" / "-") non-negative-integer
non-negative-integer = %x30 / %x31-39 *( %x30-39 )
; "0", or digits without a leading "0"
@@ -566,8 +567,10 @@
"0" "baz"
"1/0" "bar"
+ "0-1" "bar"
"2/highly/nested/objects" true
"0#" 1
+ "0-1#" 0
"1#" "foo"
@@ -629,7 +632,7 @@ diff --git a/draft/2020-12/release-notes.md b/draft/2020-12/release-notes.md new file mode 100644 index 00000000..ed8cfc6e --- /dev/null +++ b/draft/2020-12/release-notes.md @@ -0,0 +1,8 @@ +--- +title: JSON Schema 2020-12 Release Notes +layout: page +--- + +_NOTE: This page is still being written._ + +You can find a minimal changelog at the end of the specification documents themselves. \ No newline at end of file diff --git a/draft/2020-12/schema b/draft/2020-12/schema new file mode 120000 index 00000000..70e58e37 --- /dev/null +++ b/draft/2020-12/schema @@ -0,0 +1 @@ +../../_includes/draft/2020-12/schema.json \ No newline at end of file diff --git a/draft/2020-12/vocab/applicator.md b/draft/2020-12/vocab/applicator.md new file mode 100644 index 00000000..93c75bcb --- /dev/null +++ b/draft/2020-12/vocab/applicator.md @@ -0,0 +1,4 @@ +--- +redirect_to: /draft/2020-12/json-schema-core.html#rfc.section.10 +title: A Vocabulary for Applying Subschemas +--- diff --git a/draft/2020-12/vocab/content.md b/draft/2020-12/vocab/content.md new file mode 100644 index 00000000..b60a25c4 --- /dev/null +++ b/draft/2020-12/vocab/content.md @@ -0,0 +1,4 @@ +--- +redirect_to: /draft/2020-12/json-schema-validation.html#rfc.section.8 +title: A Vocabulary for the Contents of String-Encoded Data +--- diff --git a/draft/2020-12/vocab/core.md b/draft/2020-12/vocab/core.md new file mode 100644 index 00000000..dca0cbed --- /dev/null +++ b/draft/2020-12/vocab/core.md @@ -0,0 +1,4 @@ +--- +redirect_to: /draft/2020-12/json-schema-core.html#rfc.section.8 +title: The JSON Schema Core Vocabulary +--- diff --git a/draft/2020-12/vocab/format-annotation.md b/draft/2020-12/vocab/format-annotation.md new file mode 100644 index 00000000..ff0e1aa8 --- /dev/null +++ b/draft/2020-12/vocab/format-annotation.md @@ -0,0 +1,4 @@ +--- +redirect_to: /draft/2020-12/json-schema-validation.html#rfc.section.7 +title: A Vocabulary for Semantic Content with "format" as annotations +--- diff --git a/draft/2020-12/vocab/format-assertion.md b/draft/2020-12/vocab/format-assertion.md new file mode 100644 index 00000000..fe9640eb --- /dev/null +++ b/draft/2020-12/vocab/format-assertion.md @@ -0,0 +1,4 @@ +--- +redirect_to: /draft/2020-12/json-schema-validation.html#rfc.section.7 +title: A Vocabulary for Semantic Content with "format" as assertions +--- diff --git a/draft/2020-12/vocab/meta-data.md b/draft/2020-12/vocab/meta-data.md new file mode 100644 index 00000000..0fb58ffa --- /dev/null +++ b/draft/2020-12/vocab/meta-data.md @@ -0,0 +1,4 @@ +--- +redirect_to: /draft/2020-12/json-schema-validation.html#rfc.section.9 +title: A Vocabulary for Basic Meta-Data Annotations +--- diff --git a/draft/2020-12/vocab/unevaluated.md b/draft/2020-12/vocab/unevaluated.md new file mode 100644 index 00000000..0ff02bc1 --- /dev/null +++ b/draft/2020-12/vocab/unevaluated.md @@ -0,0 +1,4 @@ +--- +redirect_to: /draft/2020-12/json-schema-core.html#rfc.section.11 +title: A Vocabulary for Unevaluated Locations +--- diff --git a/draft/2020-12/vocab/validation.md b/draft/2020-12/vocab/validation.md new file mode 100644 index 00000000..e03833e4 --- /dev/null +++ b/draft/2020-12/vocab/validation.md @@ -0,0 +1,4 @@ +--- +redirect_to: /draft/2020-12/json-schema-validation.html#rfc.section.6 +title: A Vocabulary for Structural Validation +--- diff --git a/hyper-schema.md b/hyper-schema.md deleted file mode 100644 index d57e3c3f..00000000 --- a/hyper-schema.md +++ /dev/null @@ -1,3 +0,0 @@ ---- -redirect_to: /draft/2019-09/hyper-schema ---- diff --git a/implementations.md b/implementations.md index 8a3cdf62..f626c71c 100644 --- a/implementations.md +++ b/implementations.md @@ -78,47 +78,6 @@ Benchmarks that compare at least two implementations supporting draft-06+ may be - PHP - [php-json-schema-bench](https://github.com/swaggest/php-json-schema-bench) - comparative benchmark for JSON-schema PHP validators using JSON-Schema Test Suite and z-schema/JSCK (MIT) -Hyper-Schema ---------------------- - - - - - -
' | remove: '
'}} - - {% if implementation.license %} - ({{ implementation.license | join: ", " }}) - {% endif %} - -' | remove: '
'}} + + {% if implementation.license %} + ({{ implementation.license | join: ", " }}) + {% endif %} + +