diff --git a/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md
new file mode 100644
index 00000000..5e83dd95
--- /dev/null
+++ b/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md
@@ -0,0 +1,91 @@
+# Acknowledge ambiguity in additionalProperties behaviour and fix after patch release
+
+* Status: accepted
+* Deciders: @relequestual @gregsdennis, @jdesrosiers, @karenetheridge
+* Date: 2022-05-19
+
+Related...
+
+Issue: https://github.com/json-schema-org/json-schema-spec/issues/1172
+
+Discussion: https://github.com/json-schema-org/community/discussions/57
+
+Pull Request: https://github.com/json-schema-org/json-schema-spec/pull/1203
+
+## Context and Problem Statement
+
+When we changed the specification to use annotations as the context in which some keywords behave, we included a clause that allowed implementations which didn't use annotations to optimize the processing of `additionalProperties` in another way which produces the same effect as the prior behaviour.
+This section created an ambiguity in terms of the resulting output format, but not validation.
+
+We needed to decide on how to proceed for the patch release of the 2020-12 version of the specification.
+
+The two above links are to a GitHub Discussion and a GitHub Issue detailing the problems.
+Details with an example of the problem can be seen in the Discussion's opening post specifically.
+
+## Decision Drivers
+
+* The "patch release" should not change anything functionally
+* Annotations as they are, are confusing to users, implementers, and specification editors alike
+* Patch release is behind schedule
+* There are currently no tests for the output format
+* It's hard to see any immediate consensus on changing the annotation based behaviour
+
+## Considered Options
+
+* [Leaving it "as is" and do nothing](https://github.com/json-schema-org/community/discussions/57#discussioncomment-1413777)
+* [Pick one](https://github.com/json-schema-org/community/discussions/57#discussioncomment-1416683) of the behaviours
+* [Revert back to draft-07 behaviour](https://github.com/json-schema-org/community/discussions/57#discussioncomment-1453723)
+* [Reinterpret how we understand annotation collection](https://github.com/json-schema-org/json-schema-spec/issues/1172#issuecomment-1049686478) to allow reading annotations within the same schema object regardless of assertion results
+* [Acknowledge and accept that two approaches and results are allowable](https://github.com/json-schema-org/community/issues/161#issue-1173742930)
+* Redefine annotation collection behaviour and/or how `additionalProperties` works
+
+## Decision Outcome
+
+Chosen option: "Acknowledge and accept that two approaches and results are allowable", because
+
+* Leaving it "as is" will continue to cause confusion
+* The change is non-functional which is required for the patch release
+* The patch release is behind schedule
+* Finding consensus of other solutions proved to be difficult
+* There's no test suite for the output format, so it's not easy to see unintended consequences of a functional change
+* We need to properly re-evaluate annotation collection and how annotations are used by other keywords
+
+### Positive Consequences
+
+* Patch release can move forward
+* Validation result is not impacted
+* Confusion is at least seen and acknowledged
+* Implementations which pick either approach are seen to be compliant
+
+### Negative Consequences
+
+* May have an impact for downstream tools which process full output data
+* A test suite (not yet developed) which covers this situation needs to allow for multiple valid answers
+
+## Pros and Cons of the Options
+
+### Leaving it "as is" and do nothing
+
+Agree to do nothing and hope for the best. There isn't any downstream tooling yet anyway.
+
+* Good, because no functional change
+* Good, because no impact on downstream tooling
+* Bad, because leaves a known ambiguity in the specification
+
+### Pick one / Revert to draft-07 behaviour / Reinterpret annotation collection
+
+* Good, because ambiguity is removed
+* Good, because not many tools will be effected
+* Bad, because it can be seen as a functional change (not really allowed for the patch release)
+* Bad, because it can break existing implementations and downstream tools
+* Bad, because without a test suite it's hard to see unexpected consequences
+
+## Links
+
+* Issue: [Ambiguous behaviour of additionalProperties when invalid](https://github.com/json-schema-org/json-schema-spec/issues/1172)
+* Discussion: [The meaning of "additionalProperties" has changed](https://github.com/json-schema-org/community/discussions/57)
+* Resolving Pull Request: [Add CREF about ambiguous behaviour of additionalProperties](https://github.com/json-schema-org/json-schema-spec/pull/1203)
+* Alternative solution proposal: [Resolve contradictions in the described behaviour of "additionalProperties" and "items"](https://github.com/json-schema-org/json-schema-spec/pull/1154)
+
+* [Result of discussing](https://github.com/json-schema-org/json-schema-spec/issues/1172#issuecomment-1063962900) on an Open Community Working Meeting call - @jdesrosiers proposed a less controversial and more agreeable solution to add a comment that both are allowable
+* [Related GitHub Discussion](https://github.com/json-schema-org/community/discussions/67) on alternative behaviour for `unevaluated*` keywords
diff --git a/adr/README.md b/adr/README.md
new file mode 100644
index 00000000..331cd6bf
--- /dev/null
+++ b/adr/README.md
@@ -0,0 +1,15 @@
+# Architectural Decision Log
+
+This log lists the architectural decisions for the JSON Schema specification.
+
+
+
+* [ADR-2022-04-08](2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md) - Acknowledge ambiguity in additionalProperties behaviour and fix after patch release
+
+
+
+You can find the ADR for using ADRs in our [community repo ADR log](https://github.com/json-schema-org/community/tree/HEAD/docs/adr).
+
+For new ADRs, please use [template.md](template.md) as basis.
+More information on MADR is available at .
+General information about architectural decision records is available at .
diff --git a/adr/template.md b/adr/template.md
new file mode 100644
index 00000000..25696bbe
--- /dev/null
+++ b/adr/template.md
@@ -0,0 +1,72 @@
+# [short title of solved problem and solution]
+
+* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)]
+* Deciders: [list everyone involved in the decision]
+* Date: [YYYY-MM-DD when the decision was last updated]
+
+Technical Story: [description | ticket/issue URL]
+
+## Context and Problem Statement
+
+[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]
+
+## Decision Drivers
+
+* [driver 1, e.g., a force, facing concern, …]
+* [driver 2, e.g., a force, facing concern, …]
+* …
+
+## Considered Options
+
+* [option 1]
+* [option 2]
+* [option 3]
+* …
+
+## Decision Outcome
+
+Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
+
+### Positive Consequences
+
+* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
+* …
+
+### Negative Consequences
+
+* [e.g., compromising quality attribute, follow-up decisions required, …]
+* …
+
+## Pros and Cons of the Options
+
+### [option 1]
+
+[example | description | pointer to more information | …]
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* …
+
+### [option 2]
+
+[example | description | pointer to more information | …]
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* …
+
+### [option 3]
+
+[example | description | pointer to more information | …]
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* …
+
+## Links
+
+* [Link type] [Link to ADR]
+* …
diff --git a/jsonschema-core.xml b/jsonschema-core.xml
index a93c377d..d3beca54 100644
--- a/jsonschema-core.xml
+++ b/jsonschema-core.xml
@@ -20,7 +20,7 @@
-
+JSON Schema: A Media Type for Describing JSON Documents
@@ -50,7 +50,7 @@
-
+ Internet Engineering Task ForceJSONSchema
@@ -315,8 +315,8 @@
of five categories:
- control schema identification through setting the schema's
- canonical URI and/or changing how the base URI is determined
+ control schema identification through setting a URI
+ for the schema and/or changing how the base URI is determined
produce a boolean result when applied to an instance
@@ -399,6 +399,13 @@
of any vocabulary, there is no analogous mechanism to indicate individual
keyword usage.
+
+ A schema vocabulary can be defined by anything from an informal description
+ to a standards proposal, depending on the audience and interoperability
+ expectations. In particular, in order to facilitate vocabulary use within
+ non-public organizations, a vocabulary specification need not be published
+ outside of its scope of use.
+
@@ -419,13 +426,25 @@
A JSON Schema resource is a schema which is
canonically identified by an
- absolute URI.
+ absolute URI. Schema resources MAY
+ also be identified by URIs, including URIs with fragments,
+ if the resulting secondary resource (as defined by
+ section 3.5 of RFC 3986) is identical
+ to the primary resource. This can occur with the empty fragment,
+ or when one schema resource is embedded in another. Any such URIs
+ with fragments are considered to be non-canonical.
The root schema is the schema that comprises the entire JSON document
in question. The root schema is always a schema resource, where the
URI is determined as described in section
.
+
+ Note that documents that embed schemas in another format will not
+ have a root schema resource in this sense. Exactly how such usages
+ fit with the JSON Schema document and resource concepts will be
+ clarified in a future draft.
+
Some keywords take schemas themselves, allowing JSON Schemas to be nested:
@@ -723,9 +742,9 @@
be able to support those keywords or vocabularies that contain them.
-
+
- Identifiers set the canonical URI of a schema, or affect how such URIs are
+ Identifiers define URIs for a schema, or affect how such URIs are
resolved in references, or both.
The Core vocabulary defined in this document defines several
identifying keywords, most notably "$id".
@@ -1334,25 +1353,32 @@
If present, the value for this keyword MUST be a string, and MUST represent a
valid URI-reference. This URI-reference
SHOULD be normalized, and MUST resolve to an
- absolute-URI (without a fragment). Therefore,
- "$id" MUST NOT contain a non-empty fragment, and SHOULD NOT contain an
- empty fragment.
+ absolute-URI (without a fragment),
+ or to a URI with an empty fragment.
- Since an empty fragment in the context of the application/schema+json media
- type refers to the same resource as the base URI without a fragment,
- an implementation MAY normalize a URI ending with an empty fragment by removing
- the fragment. However, schema authors SHOULD NOT rely on this behavior
- across implementations.
+ The empty fragment form is NOT RECOMMENDED and is retained only
+ for backwards compatibility, and because the
+ application/schema+json media type defines that a URI with an
+ empty fragment identifies the same resource as the same URI
+ with the fragment removed. However, since this equivalence is not
+ part of the RFC 3986 normalization process,
+ implementers and schema authors cannot rely on generic URI libraries
+ understanding it.
+
+
+ Therefore, "$id" MUST NOT contain a non-empty fragment, and SHOULD NOT
+ contain an empty fragment. The absolute-URI form MUST be considered
+ the canonical URI, regardless of the presence or absence of an empty fragment.
- This is primarily allowed because older meta-schemas have an empty
- fragment in their $id (or previously, id). A future draft may outright
- forbid even empty fragments in "$id".
+ An empty fragment is currently allowed because older meta-schemas have
+ an empty fragment in their $id (or previously, id).
+ A future draft may outright forbid even empty fragments in "$id".
- This URI also serves as the base URI for relative URI-references in keywords
- within the schema resource, in accordance with
+ The absolute-URI also serves as the base URI for relative URI-references
+ in keywords within the schema resource, in accordance with
RFC 3986 section 5.1.1 regarding base URIs
embedded in content.
@@ -1616,7 +1642,7 @@
media type.
- Unless the "$id" keyword described in the next section is present in the
+ Unless the "$id" keyword described in an earlier section is present in the
root schema, this base URI SHOULD be considered the canonical URI of the
schema document's root schema resource.
@@ -1743,7 +1769,7 @@
Since JSON Pointer URI fragments are constructed based on the structure
of the schema document, an embedded schema resource and its subschemas
can be identified by JSON Pointer fragments relative to either its own
- canonical URI, or relative to the containing resource's URI.
+ canonical URI, or relative to any containing resource's URI.
Conceptually, a set of linked schema resources should behave
@@ -1775,13 +1801,18 @@
}
]]>
-
- The URI "https://example.com/foo#/items/additionalProperties"
- points to the schema of the "additionalProperties" keyword in
- the embedded resource. The canonical URI of that schema, however,
- is "https://example.com/bar#/additionalProperties".
-
+
+ The URI "https://example.com/foo#/items" points to the "items" schema,
+ which is an embedded resource. The canonical URI of that schema
+ resource, however, is "https://example.com/bar".
+
+
+ For the "additionalProperties" schema within that embedded resource,
+ the URI "https://example.com/foo#/items/additionalProperties" points
+ to the correct object, but that object's URI relative to its resource's
+ canonical URI is "https://example.com/bar#/additionalProperties".
+
Now consider the following two schema resources linked by reference
@@ -1803,38 +1834,47 @@
]]>
- Here we see that the canonical URI for that "additionalProperties"
- subschema is still valid, while the non-canonical URI with the fragment
- beginning with "#/items/$ref" now resolves to nothing.
+ Here we see that "https://example.com/bar#/additionalProperties",
+ using a JSON Pointer fragment appended to the canonical URI of
+ the "bar" schema resource, is still valid, while
+ "https://example.com/foo#/items/additionalProperties", which relied
+ on a JSON Pointer fragment appended to the canonical URI of the
+ "foo" schema resource, no longer resolves to anything.
Note also that "https://example.com/foo#/items" is valid in both
arrangements, but resolves to a different value. This URI ends up
- functioning similarly to a retrieval URI for a resource. While valid,
- examining the resolved value and either using the "$id" (if the value
- is a subschema), or resolving the reference and using the "$id" of the
- reference target, is preferable.
+ functioning similarly to a retrieval URI for a resource. While this URI
+ is valid, it is more robust to use the "$id" of the embedded or referenced
+ resource unless it is specifically desired to identify the object containing
+ the "$ref" in the second (non-embedded) arrangement.
- An implementation MAY choose not to support addressing schemas
- by non-canonical URIs. As such, it is RECOMMENDED that schema authors only
- use canonical URIs, as using non-canonical URIs may reduce
- schema interoperability.
+ An implementation MAY choose not to support addressing schema resource
+ contents by URIs using a base other than the resource's canonical URI,
+ plus a JSON Pointer fragment relative to that base. Therefore, schema
+ authors SHOULD NOT rely on such URIs, as using them may reduce interoperability.
This is to avoid requiring implementations to keep track of a whole
stack of possible base URIs and JSON Pointer fragments for each,
given that all but one will be fragile if the schema resources
- are reorganized. Some have argued that this is easy so there is
+ are reorganized. Some
+ have argued that this is easy so there is
no point in forbidding it, while others have argued that it complicates
schema identification and should be forbidden. Feedback on this
topic is encouraged.
+ After some discussion, we feel that we need to remove the use of
+ "canonical" in favour of talking about JSON Pointers which reference
+ across schema resource boundaries as undefined or even forbidden behavior
+ (https://github.com/json-schema-org/json-schema-spec/issues/937,
+ https://github.com/json-schema-org/json-schema-spec/issues/1183)
- Further examples of such non-canonical URIs, as well as the appropriate
- canonical URIs to use instead, are provided in appendix
- .
+ Further examples of such non-canonical URI construction, as well as
+ the appropriate canonical URI-based fragments to use instead,
+ are provided in appendix .
@@ -2061,13 +2101,6 @@
The current URI for the corresponding meta-schema is:
.
-
- Updated vocabulary and meta-schema URIs MAY be published between
- specification drafts in order to correct errors. Implementations
- SHOULD consider URIs dated after this specification draft and
- before the next to indicate the same syntax and semantics
- as those listed here.
-
Schema keywords typically operate independently, without
@@ -2085,7 +2118,8 @@
"items", whose behavior is defined in terms of "prefixItems"
- "contains", whose behavior is defined in terms of "minContains"
+ "contains", whose behavior is affected by the presence and value of
+ "minContains", in the Validation vocabulary
@@ -2318,6 +2352,8 @@
positions within the instance array, it produces an
annotation result of boolean true, indicating that all remaining array
elements have been evaluated against this keyword's subschema.
+ This annotation affects the behavior of "unevaluatedItems" in the
+ Unevaluated vocabulary.
Omitting this keyword has the same assertion behavior as
@@ -2337,15 +2373,10 @@
An array instance is valid against "contains" if at least one of
- its elements is valid against the given schema. The subschema MUST be
- applied to every array element even after the first match has
- been found, in order to collect annotations for use by other keywords.
- This is to ensure that all possible annotations are collected.
-
-
- Logically, the validation result of applying the value subschema to each
- item in the array MUST be ORed with "false", resulting in an overall
- validation result.
+ its elements is valid against the given schema,
+ except when "minContains" is present and has a value of 0, in which
+ case an array instance MUST be considered valid against the "contains" keyword,
+ even if none of its elements is valid against the given schema.
This keyword produces an annotation value which is an array of
@@ -2355,6 +2386,16 @@
instance. The annotation MUST be present if the instance array to which
this keyword's schema applies is empty.
+
+ This annotation affects the behavior of "unevaluatedItems" in the
+ Unevaluated vocabulary, and MAY also be used to implement the
+ "minContains" and "maxContains" keywords in the Validation vocabulary.
+
+
+ The subschema MUST be applied to every array element even after the first
+ match has been found, in order to collect annotations for use by other
+ keywords. This is to ensure that all possible annotations are collected.
+
@@ -2373,6 +2414,8 @@
The annotation result of this keyword is the set of instance
property names matched by this keyword.
+ This annotation affects the behavior of "additionalProperties" (in
+ this vocabulary) and "unevaluatedProperties" in the Unevaluated vocabulary.
Omitting this keyword has the same assertion behavior as
@@ -2396,6 +2439,8 @@
The annotation result of this keyword is the set of instance
property names matched by this keyword.
+ This annotation affects the behavior of "additionalProperties" (in this
+ vocabulary) and "unevaluatedProperties" (in the Unevaluated vocabulary).
Omitting this keyword has the same assertion behavior as
@@ -2422,6 +2467,8 @@
The annotation result of this keyword is the set of instance
property names validated by this keyword's subschema.
+ This annotation affects the behavior of "unevaluatedProperties"
+ in the Unevaluated vocabulary.
Omitting this keyword has the same assertion behavior as
@@ -2433,6 +2480,17 @@
checking the names in "properties" and the patterns in
"patternProperties" against the instance property set.
Implementations that do not support annotation collection MUST do so.
+
+ In defining this option, it seems there is the potential for
+ ambiguity in the output format. The ambiguity does not affect validation results,
+ but it does affect the resulting output format.
+ The ambiguity allows for multiple valid output results depending on whether annotations
+ are used or a solution that "produces the same effect" as draft-07. It is understood
+ that annotations from failing schemas are dropped.
+ See our
+ [Decision Record](https://github.com/json-schema-org/json-schema-spec/tree/HEAD/adr/2022-04-08-cref-for-ambiguity-and-fix-later-gh-spec-issue-1172.md)
+ for further details.
+
@@ -2497,13 +2555,6 @@
The current URI for the corresponding meta-schema is:
.
-
- Updated vocabulary and meta-schema URIs MAY be published between
- specification drafts in order to correct errors. Implementations
- SHOULD consider URIs dated after this specification draft and
- before the next to indicate the same syntax and semantics
- as those listed here.
-
@@ -2559,6 +2610,7 @@
positions within the instance array, it produces an
annotation result of boolean true, analogous to the
behavior of "items".
+ This annotation affects the behavior of "unevaluatedItems" in parent schemas.
Omitting this keyword has the same assertion behavior as
@@ -2602,6 +2654,7 @@
The annotation result of this keyword is the set of instance
property names validated by this keyword's subschema.
+ This annotation affects the behavior of "unevaluatedProperties" in parent schemas.
Omitting this keyword has the same assertion behavior as
@@ -2695,8 +2748,8 @@
The absolute, dereferenced location of the validating keyword. The value MUST
- be expressed as a full URI using the canonical URI of the relevant
- schema object, and it MUST NOT include by-reference applicators
+ be expressed as a full URI using the canonical URI of the relevant schema resource
+ with a JSON Pointer fragment, and it MUST NOT include by-reference applicators
such as "$ref" or "$dynamicRef" as non-terminal path components.
It MAY end in such keywords if the error or annotation is for that
keyword, such as an unresolvable reference.
@@ -3121,20 +3174,6 @@ https://example.com/schemas/common#/$defs/count/minimum
Type name: applicationSubtype name: schema+jsonRequired parameters: N/A
-
- Optional parameters:
-
-
- A non-empty list of space-separated URIs, each identifying
- a JSON Schema resource. The instance SHOULD successfully
- validate against at least one of these meta-schemas.
- Non-validating meta-schemas MAY be included for purposes such
- as allowing clients to make use of older versions of
- a meta-schema as long as the runtime instance validates
- against that older version.
-
-
-
Encoding considerations: Encoding considerations are
identical to those specified for the "application/json"
@@ -3165,20 +3204,7 @@ https://example.com/schemas/common#/$defs/count/minimum
Type name: applicationSubtype name: schema-instance+json
-
- Required parameters:
-
-
- A non-empty list of space-separated URIs, each identifying
- a JSON Schema resource. The instance SHOULD successfully
- validate against at least one of these schemas.
- Non-validating schemas MAY be included for purposes such
- as allowing clients to make use of older versions of a schema
- as long as the runtime instance validates against that
- older version.
-
-
-
+ Required parameters: N/A
Encoding considerations: Encoding considerations are
identical to those specified for the "application/json"
@@ -3241,9 +3267,9 @@ https://example.com/schemas/common#/$defs/count/minimum
-
+
-
+
@@ -3332,10 +3358,10 @@ https://example.com/schemas/common#/$defs/count/minimum
-
+
https://example.com/root.json
-
+
https://example.com/root.json#
@@ -3343,21 +3369,21 @@ https://example.com/schemas/common#/$defs/count/minimum
https://example.com/root.json
-
+
https://example.com/root.json#foo
-
+
https://example.com/root.json#/$defs/A
- https://example.com/other.json
-
+ https://example.com/other.json
+
https://example.com/other.json#
-
+
https://example.com/root.json#/$defs/B
@@ -3365,49 +3391,61 @@ https://example.com/schemas/common#/$defs/count/minimum
https://example.com/other.json
-
+
https://example.com/other.json#bar
-
+
https://example.com/other.json#/$defs/X
-
+
https://example.com/root.json#/$defs/B/$defs/X
- https://example.com/t/inner.json
-
+ https://example.com/t/inner.json
+
https://example.com/t/inner.json#bar
-
+
https://example.com/t/inner.json#
-
+
https://example.com/other.json#/$defs/Y
-
+
https://example.com/root.json#/$defs/B/$defs/Y
-
+
urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f
-
+
urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f#
-
+
https://example.com/root.json#/$defs/C
+
+ Note: The fragment part of the URI does not make it canonical or non-canonical,
+ rather, the base URI used (as part of the full URI with any fragment) is what
+ determines the canonical nature of the resulting full URI.
+
+ Multiple "canonical" URIs? We Acknowledge this is potentially confusing, and
+ direct you to read the CREF located in the
+ JSON Pointer fragments and embedded schema resources
+ section for futher comments.
+
+
+
@@ -3433,8 +3471,8 @@ https://example.com/schemas/common#/$defs/count/minimum
This transformation can be safely and reversibly done as long as
all static references (e.g. "$ref") use URI-references that resolve
- to canonical URIs, and all schema resources have an absolute-URI
- as the "$id" in their root schema.
+ to URIs using the canonical resource URI as the base, and all schema
+ resources have an absolute-URI as the "$id" in their root schema.
With these conditions met, each external resource can be copied
@@ -3442,7 +3480,7 @@ https://example.com/schemas/common#/$defs/count/minimum
schema objects, and without changing any aspect of validation or
annotation results. The names of the schemas under "$defs" do
not affect behavior, assuming they are each unique, as they
- do not appear in canonical URIs for the embedded resources.
+ do not appear in the canonical URIs for the embedded resources.
@@ -3679,7 +3717,7 @@ https://example.com/schemas/common#/$defs/count/minimum
{"$ref": "https://json-schema.org/draft/2020-12/meta/core"},
{"$ref": "https://json-schema.org/draft/2020-12/meta/applicator"},
{"$ref": "https://json-schema.org/draft/2020-12/meta/validation"},
- {"$ref": "https://example.com/meta/example-vocab",
+ {"$ref": "https://example.com/meta/example-vocab"}
],
"patternProperties": {
"^unevaluated": false
@@ -3841,13 +3879,23 @@ https://example.com/schemas/common#/$defs/count/minimum
+
+
+ Improve and clarify the "type", "contains", "unevaluatedProperties", and "unevaluatedItems" keyword explanations
+ Clarify various aspects of "canonical URIs"
+ Comment on ambiguity around annotations and "additionalProperties"
+ Clarify Vocabularies need not be formally defined
+ Remove references to remaining media-type parameters
+ Fix multiple examples
+
+ "$schema" MAY change for embedded resourcesArray-value "items" functionality is now "prefixItems""items" subsumes the old function of "additionalItems"
- "contains" and "unevaluatedItems" interactions now specified
- Rename $recursive* to $dynamic*
+ "contains" annotation behavior, and "contains" and "unevaluatedItems" interactions now specified
+ Rename $recursive* to $dynamic*, with behavior modification$dynamicAnchor defines a fragment like $anchor$dynamic* (previously $recursive) no longer use runtime base URI determinationDefine Compound Schema Documents (bundle) and processing
diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml
index e12c6cd2..ee3ee1b6 100644
--- a/jsonschema-validation.xml
+++ b/jsonschema-validation.xml
@@ -28,7 +28,7 @@
-
+
JSON Schema Validation: A Vocabulary for Structural Validation of JSON
@@ -53,7 +53,7 @@
</address>
</author>
- <date year="2021"/>
+ <date year="2022"/>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>JSON</keyword>
<keyword>Schema</keyword>
@@ -442,8 +442,9 @@
</t>
<t>
A value of 0 is allowed, but is only useful for setting a range
- of occurrences from 0 to the value of "maxContains". A value of
- 0 with no "maxContains" causes "contains" to always pass validation.
+ of occurrences from 0 to the value of "maxContains". A value of
+ 0 causes "minContains" and "contains" to always pass validation
+ (but validation can still fail against a "maxContains" keyword).
</t>
<t>
Omitting this keyword has the same behavior as a value of 1.
@@ -704,30 +705,34 @@
<list style="hanging">
<t hangText="date-time:">
A string instance is valid against this attribute if it is
- a valid representation according to the "date-time" production.
+ a valid representation according to the "date-time' ABNF rule
+ (referenced above)
</t>
<t hangText="date:">
A string instance is valid against this attribute if it is
- a valid representation according to the "full-date" production.
+ a valid representation according to the "full-date" ABNF rule
+ (referenced above)
</t>
<t hangText="time:">
A string instance is valid against this attribute if it is
- a valid representation according to the "full-time" production.
+ a valid representation according to the "full-time" ABNF rule
+ (referenced above)
</t>
<t hangText="duration:">
A string instance is valid against this attribute if it is
- a valid representation according to the "duration" production.
+ a valid representation according to the "duration" ABNF rule
+ (referenced above)
</t>
</list>
</t>
<t>
Implementations MAY support additional attributes using the other
- production names defined anywhere in that RFC. If "full-date" or "full-time"
+ format names defined anywhere in that RFC. If "full-date" or "full-time"
are implemented, the corresponding short form ("date" or "time"
respectively) MUST be implemented, and MUST behave identically.
Implementations SHOULD NOT define extension attributes
- with any name matching an RFC 3339 production unless it validates
- according to the rules of that production.
+ with any name matching an RFC 3339 format unless it validates
+ according to the rules of that format.
<cref>
There is not currently consensus on the need for supporting
all RFC 3339 formats, so this approach of reserving the
@@ -964,7 +969,7 @@
<t>
If the instance value is a string, this property defines that the string
- SHOULD be interpreted as binary data and decoded using the encoding
+ SHOULD be interpreted as encoded binary data and decoded using the encoding
named by this property.
</t>
@@ -972,7 +977,14 @@
Possible values indicating base 16, 32, and 64 encodings with several
variations are listed in <xref target="RFC4648">RFC 4648</xref>. Additionally,
sections 6.7 and 6.8 of <xref target="RFC2045">RFC 2045</xref> provide
- encodings used in MIME. As "base64" is defined in both RFCs, the definition
+ encodings used in MIME. This keyword is derived from MIME's
+ Content-Transfer-Encoding header, which was designed to map binary data
+ into ASCII characters. It is not related to HTTP's Content-Encoding header,
+ which is used to encode (e.g. compress or encrypt)
+ the content of HTTP request and responses.
+ </t>
+ <t>
+ As "base64" is defined in both RFCs, the definition
from RFC 4648 SHOULD be assumed unless the string is specifically intended
for use in a MIME context. Note that all of these encodings result in
strings consisting only of 7-bit ASCII characters. Therefore, this keyword
@@ -1342,9 +1354,9 @@
<author initials="G." surname="Dennis">
<organization/>
</author>
- <date year="2020" month="December"/>
+ <date year="2022" month="May"/>
</front>
- <seriesInfo name="Internet-Draft" value="draft-bhutton-json-schema-00" />
+ <seriesInfo name="Internet-Draft" value="draft-bhutton-json-schema-01" />
</reference>
</references>
@@ -1429,6 +1441,12 @@
</t>
<t>
<list style="hanging">
+ <t hangText="draft-bhutton-json-schema-validation-01">
+ <list style="symbols">
+ <t>Improve and clarify the "minContains" keyword explanation</t>
+ <t>Remove the use of "production" in favour of "ABNF rule"</t>
+ </list>
+ </t>
<t hangText="draft-bhutton-json-schema-validation-00">
<list style="symbols">
<t>Correct email format RFC reference to 5321 instead of 5322</t>