Skip to content

Commit 0f6ade1

Browse files
RelequestualRelequestual
authored
Merge branch 'master' into canon
2 parents 9a14b73 + db65da8 commit 0f6ade1

File tree

2 files changed

+78
-67
lines changed

2 files changed

+78
-67
lines changed

Diff for: ‎jsonschema-core.xml

+55-56
Original file line numberDiff line numberDiff line change
@@ -50,7 +50,7 @@
5050
</address>
5151
</author>
5252

53-
<date year="2021"/>
53+
<date year="2022"/>
5454
<workgroup>Internet Engineering Task Force</workgroup>
5555
<keyword>JSON</keyword>
5656
<keyword>Schema</keyword>
@@ -399,6 +399,13 @@
399399
of any vocabulary, there is no analogous mechanism to indicate individual
400400
keyword usage.
401401
</t>
402+
<t>
403+
A schema vocabulary can be defined by anything from an informal description
404+
to a standards proposal, depending on the audience and interoperability
405+
expectations. In particular, in order to facilitate vocabulary use within
406+
non-public organizations, a vocabulary specification need not be published
407+
outside of its scope of use.
408+
</t>
402409
</section>
403410
<section title="Meta-Schemas">
404411
<t>
@@ -1856,6 +1863,11 @@
18561863
no point in forbidding it, while others have argued that it complicates
18571864
schema identification and should be forbidden. Feedback on this
18581865
topic is encouraged.
1866+
After some discussion, we feel that we need to remove the use of
1867+
"canonical" in favour of talking about JSON Pointers which reference
1868+
across schema resource boundaries as undefined or even forbidden behavior
1869+
(https://github.com/json-schema-org/json-schema-spec/issues/937,
1870+
https://github.com/json-schema-org/json-schema-spec/issues/1183)
18591871
</cref>
18601872
</t>
18611873
<t>
@@ -2088,13 +2100,6 @@
20882100
The current URI for the corresponding meta-schema is:
20892101
<eref target="https://json-schema.org/draft/2020-12/meta/applicator"/>.
20902102
</t>
2091-
<t>
2092-
Updated vocabulary and meta-schema URIs MAY be published between
2093-
specification drafts in order to correct errors. Implementations
2094-
SHOULD consider URIs dated after this specification draft and
2095-
before the next to indicate the same syntax and semantics
2096-
as those listed here.
2097-
</t>
20982103
<section title="Keyword Independence">
20992104
<t>
21002105
Schema keywords typically operate independently, without
@@ -2112,7 +2117,8 @@
21122117
"items", whose behavior is defined in terms of "prefixItems"
21132118
</t>
21142119
<t>
2115-
"contains", whose behavior is defined in terms of "minContains"
2120+
"contains", whose behavior is affected by the presence and value of
2121+
"minContains", in the Validation vocabulary
21162122
</t>
21172123
</list>
21182124
</t>
@@ -2345,6 +2351,8 @@
23452351
positions within the instance array, it produces an
23462352
annotation result of boolean true, indicating that all remaining array
23472353
elements have been evaluated against this keyword's subschema.
2354+
This annotation affects the behavior of "unevaluatedItems" in the
2355+
Unevaluated vocabulary.
23482356
</t>
23492357
<t>
23502358
Omitting this keyword has the same assertion behavior as
@@ -2364,15 +2372,10 @@
23642372
</t>
23652373
<t>
23662374
An array instance is valid against "contains" if at least one of
2367-
its elements is valid against the given schema. The subschema MUST be
2368-
applied to every array element even after the first match has
2369-
been found, in order to collect annotations for use by other keywords.
2370-
This is to ensure that all possible annotations are collected.
2371-
</t>
2372-
<t>
2373-
Logically, the validation result of applying the value subschema to each
2374-
item in the array MUST be ORed with "false", resulting in an overall
2375-
validation result.
2375+
its elements is valid against the given schema,
2376+
except when "minContains" is present and has a value of 0, in which
2377+
case an array instance MUST be considered valid against the "contains" keyword,
2378+
even if none of its elements is valid against the given schema.
23762379
</t>
23772380
<t>
23782381
This keyword produces an annotation value which is an array of
@@ -2382,6 +2385,16 @@
23822385
instance. The annotation MUST be present if the instance array to which
23832386
this keyword's schema applies is empty.
23842387
</t>
2388+
<t>
2389+
This annotation affects the behavior of "unevaluatedItems" in the
2390+
Unevaluated vocabulary, and MAY also be used to implement the
2391+
"minContains" and "maxContains" keywords in the Validation vocabulary.
2392+
</t>
2393+
<t>
2394+
The subschema MUST be applied to every array element even after the first
2395+
match has been found, in order to collect annotations for use by other
2396+
keywords. This is to ensure that all possible annotations are collected.
2397+
</t>
23852398
</section>
23862399
</section>
23872400

@@ -2400,6 +2413,8 @@
24002413
<t>
24012414
The annotation result of this keyword is the set of instance
24022415
property names matched by this keyword.
2416+
This annotation affects the behavior of "additionalProperties" (in
2417+
this vocabulary) and "unevaluatedProperties" in the Unevaluated vocabulary.
24032418
</t>
24042419
<t>
24052420
Omitting this keyword has the same assertion behavior as
@@ -2423,6 +2438,8 @@
24232438
<t>
24242439
The annotation result of this keyword is the set of instance
24252440
property names matched by this keyword.
2441+
This annotation affects the behavior of "additionalProperties" (in this
2442+
vocabulary) and "unevaluatedProperties" (in the Unevaluated vocabulary).
24262443
</t>
24272444
<t>
24282445
Omitting this keyword has the same assertion behavior as
@@ -2449,6 +2466,8 @@
24492466
<t>
24502467
The annotation result of this keyword is the set of instance
24512468
property names validated by this keyword's subschema.
2469+
This annotation affects the behavior of "unevaluatedProperties"
2470+
in the Unevaluated vocabulary.
24522471
</t>
24532472
<t>
24542473
Omitting this keyword has the same assertion behavior as
@@ -2524,13 +2543,6 @@
25242543
The current URI for the corresponding meta-schema is:
25252544
<eref target="https://json-schema.org/draft/2020-12/meta/unevaluated"/>.
25262545
</t>
2527-
<t>
2528-
Updated vocabulary and meta-schema URIs MAY be published between
2529-
specification drafts in order to correct errors. Implementations
2530-
SHOULD consider URIs dated after this specification draft and
2531-
before the next to indicate the same syntax and semantics
2532-
as those listed here.
2533-
</t>
25342546

25352547
<section title="Keyword Independence">
25362548
<t>
@@ -2586,6 +2598,7 @@
25862598
positions within the instance array, it produces an
25872599
annotation result of boolean true, analogous to the
25882600
behavior of "items".
2601+
This annotation affects the behavior of "unevaluatedItems" in parent schemas.
25892602
</t>
25902603
<t>
25912604
Omitting this keyword has the same assertion behavior as
@@ -2629,6 +2642,7 @@
26292642
<t>
26302643
The annotation result of this keyword is the set of instance
26312644
property names validated by this keyword's subschema.
2645+
This annotation affects the behavior of "unevaluatedProperties" in parent schemas.
26322646
</t>
26332647
<t>
26342648
Omitting this keyword has the same assertion behavior as
@@ -3148,20 +3162,6 @@ https://example.com/schemas/common#/$defs/count/minimum
31483162
<t>Type name: application</t>
31493163
<t>Subtype name: schema+json</t>
31503164
<t>Required parameters: N/A</t>
3151-
<t>
3152-
Optional parameters:
3153-
<list style="hanging">
3154-
<t hangText="schema:">
3155-
A non-empty list of space-separated URIs, each identifying
3156-
a JSON Schema resource. The instance SHOULD successfully
3157-
validate against at least one of these meta-schemas.
3158-
Non-validating meta-schemas MAY be included for purposes such
3159-
as allowing clients to make use of older versions of
3160-
a meta-schema as long as the runtime instance validates
3161-
against that older version.
3162-
</t>
3163-
</list>
3164-
</t>
31653165
<t>
31663166
Encoding considerations: Encoding considerations are
31673167
identical to those specified for the "application/json"
@@ -3192,20 +3192,7 @@ https://example.com/schemas/common#/$defs/count/minimum
31923192
<list>
31933193
<t>Type name: application</t>
31943194
<t>Subtype name: schema-instance+json</t>
3195-
<t>
3196-
Required parameters:
3197-
<list style="hanging">
3198-
<t hangText="schema:">
3199-
A non-empty list of space-separated URIs, each identifying
3200-
a JSON Schema resource. The instance SHOULD successfully
3201-
validate against at least one of these schemas.
3202-
Non-validating schemas MAY be included for purposes such
3203-
as allowing clients to make use of older versions of a schema
3204-
as long as the runtime instance validates against that
3205-
older version.
3206-
</t>
3207-
</list>
3208-
</t>
3195+
<t>Required parameters: N/A</t>
32093196
<t>
32103197
Encoding considerations: Encoding considerations are
32113198
identical to those specified for the "application/json"
@@ -3435,6 +3422,18 @@ https://example.com/schemas/common#/$defs/count/minimum
34353422
</t>
34363423
</list>
34373424
</t>
3425+
<t>
3426+
Note: The fragment part of the URI does not make it canonical or non-canonical,
3427+
rather, the base URI used (as part of the full URI with any fragment) is what
3428+
determines the canonical nature of the resulting full URI.
3429+
<cref>
3430+
Multiple "canonical" URIs? We Acknowledge this is potentially confusing, and
3431+
direct you to read the CREF located in the
3432+
<xref target="embedded">JSON Pointer fragments and embedded schema resources</xref>
3433+
section for futher comments.
3434+
</cref>
3435+
</t>
3436+
34383437
</section>
34393438

34403439
<section title="Manipulating schema documents and references">
@@ -3706,7 +3705,7 @@ https://example.com/schemas/common#/$defs/count/minimum
37063705
{"$ref": "https://json-schema.org/draft/2020-12/meta/core"},
37073706
{"$ref": "https://json-schema.org/draft/2020-12/meta/applicator"},
37083707
{"$ref": "https://json-schema.org/draft/2020-12/meta/validation"},
3709-
{"$ref": "https://example.com/meta/example-vocab",
3708+
{"$ref": "https://example.com/meta/example-vocab"}
37103709
],
37113710
"patternProperties": {
37123711
"^unevaluated": false
@@ -3873,8 +3872,8 @@ https://example.com/schemas/common#/$defs/count/minimum
38733872
<t>"$schema" MAY change for embedded resources</t>
38743873
<t>Array-value "items" functionality is now "prefixItems"</t>
38753874
<t>"items" subsumes the old function of "additionalItems"</t>
3876-
<t>"contains" and "unevaluatedItems" interactions now specified</t>
3877-
<t>Rename $recursive* to $dynamic*</t>
3875+
<t>"contains" annotation behavior, and "contains" and "unevaluatedItems" interactions now specified</t>
3876+
<t>Rename $recursive* to $dynamic*, with behavior modification</t>
38783877
<t>$dynamicAnchor defines a fragment like $anchor</t>
38793878
<t>$dynamic* (previously $recursive) no longer use runtime base URI determination</t>
38803879
<t>Define Compound Schema Documents (bundle) and processing</t>

Diff for: ‎jsonschema-validation.xml

+23-11
Original file line numberDiff line numberDiff line change
@@ -442,8 +442,9 @@
442442
</t>
443443
<t>
444444
A value of 0 is allowed, but is only useful for setting a range
445-
of occurrences from 0 to the value of "maxContains". A value of
446-
0 with no "maxContains" causes "contains" to always pass validation.
445+
of occurrences from 0 to the value of "maxContains". A value of
446+
0 causes "minContains" to always pass validation (but validation can
447+
still fail against a "maxContains" keyword).
447448
</t>
448449
<t>
449450
Omitting this keyword has the same behavior as a value of 1.
@@ -704,30 +705,34 @@
704705
<list style="hanging">
705706
<t hangText="date-time:">
706707
A string instance is valid against this attribute if it is
707-
a valid representation according to the "date-time" production.
708+
a valid representation according to the "date-time' ABNF rule
709+
(referenced above)
708710
</t>
709711
<t hangText="date:">
710712
A string instance is valid against this attribute if it is
711-
a valid representation according to the "full-date" production.
713+
a valid representation according to the "full-date" ABNF rule
714+
(referenced above)
712715
</t>
713716
<t hangText="time:">
714717
A string instance is valid against this attribute if it is
715-
a valid representation according to the "full-time" production.
718+
a valid representation according to the "full-time" ABNF rule
719+
(referenced above)
716720
</t>
717721
<t hangText="duration:">
718722
A string instance is valid against this attribute if it is
719-
a valid representation according to the "duration" production.
723+
a valid representation according to the "duration" ABNF rule
724+
(referenced above)
720725
</t>
721726
</list>
722727
</t>
723728
<t>
724729
Implementations MAY support additional attributes using the other
725-
production names defined anywhere in that RFC. If "full-date" or "full-time"
730+
format names defined anywhere in that RFC. If "full-date" or "full-time"
726731
are implemented, the corresponding short form ("date" or "time"
727732
respectively) MUST be implemented, and MUST behave identically.
728733
Implementations SHOULD NOT define extension attributes
729-
with any name matching an RFC 3339 production unless it validates
730-
according to the rules of that production.
734+
with any name matching an RFC 3339 format unless it validates
735+
according to the rules of that format.
731736
<cref>
732737
There is not currently consensus on the need for supporting
733738
all RFC 3339 formats, so this approach of reserving the
@@ -964,15 +969,22 @@
964969

965970
<t>
966971
If the instance value is a string, this property defines that the string
967-
SHOULD be interpreted as binary data and decoded using the encoding
972+
SHOULD be interpreted as encoded binary data and decoded using the encoding
968973
named by this property.
969974
</t>
970975

971976
<t>
972977
Possible values indicating base 16, 32, and 64 encodings with several
973978
variations are listed in <xref target="RFC4648">RFC 4648</xref>. Additionally,
974979
sections 6.7 and 6.8 of <xref target="RFC2045">RFC 2045</xref> provide
975-
encodings used in MIME. As "base64" is defined in both RFCs, the definition
980+
encodings used in MIME. This keyword is derived from MIME's
981+
Content-Transfer-Encoding header, which was designed to map binary data
982+
into ASCII characters. It is not related to HTTP's Content-Encoding header,
983+
which is used to encode (e.g. compress or encrypt)
984+
the content of HTTP request and responses.
985+
</t>
986+
<t>
987+
As "base64" is defined in both RFCs, the definition
976988
from RFC 4648 SHOULD be assumed unless the string is specifically intended
977989
for use in a MIME context. Note that all of these encodings result in
978990
strings consisting only of 7-bit ASCII characters. Therefore, this keyword

0 commit comments

Comments
 (0)