Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Commit 0f6ade1

Browse files
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

‎jsonschema-core.xml

Lines changed: 55 additions & 56 deletions
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>

‎jsonschema-validation.xml

Lines changed: 23 additions & 11 deletions
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)

AltStyle によって変換されたページ (->オリジナル) /