352352 </t >
353353 <t >
354354 A JSON Schema MAY contain properties which are not schema keywords or are not recognized as schema keywords.
355- The behavior of such keywords is governed by section
356- <xref target =" unrecognized" format =" counter" xref >.
355+ The behavior of such keywords is governed by <xref target =" unrecognized" xref >.
357356 </t >
358357 <t >
359358 An empty schema is a JSON Schema with no properties.
439438 <t >
440439 The root schema is the schema that comprises the entire JSON document
441440 in question. The root schema is always a schema resource, where the
442- IRI is determined as described in section
443- <xref target =" initial-base" format =" counter" xref >.
441+ IRI is determined as described in <xref target =" initial-base" xref >.
444442 <cref >
445443 Note that documents that embed schemas in another format will not
446444 have a root schema resource in this sense. Exactly how such usages
471469 As with the root schema, a subschema is either an object or a boolean.
472470 </t >
473471 <t >
474- As discussed in section
475- <xref target =" id-keyword" format =" counter" xref >, a JSON Schema document
472+ As discussed in <xref target =" id-keyword" xref >, a JSON Schema document
476473 can contain multiple JSON Schema resources. When used without qualification,
477474 the term "root schema" refers to the document's root schema. In some
478475 cases, resource root schemas are discussed. A resource's root schema
657654 location in the instance is evaluated against the assertion and
658655 annotation keywords in the schema object. The interactions of those
659656 keyword results to produce the schema object results are governed by
660- section <xref target =" annot-assert" format = " counter " xref >, while the
657+ <xref target =" annot-assert" xref >, while the
661658 relationship of subschema results to the results of the applicator
662- keyword that applied them is described by section
663- <xref target =" applicators" format =" counter" xref >.
659+ keyword that applied them is described by <xref target =" applicators" xref >.
664660 </t >
665661 <t >
666662 Evaluation of a parent schema object can complete once all of its
816812 </t >
817813 <t >
818814 <xref target =" annotations" xref > results from subschemas
819- are preserved in accordance with section
820- <xref target =" collect" format =" counter" xref > so that applications
815+ are preserved in accordance with <xref target =" collect" xref > so that applications
821816 can decide how to interpret multiple values. Applicator keywords
822817 do not play a direct role in this preservation.
823818 </t >
11101105 keywords.
11111106 </t >
11121107 <t >
1113- While these keywords do not directly affect results, as explained in section
1114- <xref target =" non-schemas" format = " counter " xref > unrecognized
1108+ While these keywords do not directly affect results, as explained in
1109+ <xref target =" non-schemas" xref > unrecognized
11151110 extension keywords that reserve locations for re-usable schemas may have
11161111 undesirable interactions with references in certain circumstances.
11171112 </t >
12831278 or link relation types, or through documented default implementation-defined
12841279 behavior in the absence of an explicit meta-schema. If a meta-schema
12851280 does not contain "$vocabulary", the set of vocabularies in use is determined
1286- according to section <xref target =" default-vocabs" format = " counter " xref >.
1281+ according to <xref target =" default-vocabs" xref >.
12871282 </t >
12881283 <t >
12891284 Any vocabulary in use by a schema and understood by the implementation
12941289 <t >
12951290 Any vocabulary that is not present in "$vocabulary" MUST NOT be made
12961291 available for use in schemas described by that meta-schema, except for
1297- the core vocabulary as specified by the introduction to section
1298- <xref target =" core" format = " counter " xref >.
1292+ the core vocabulary as specified by the introduction to
1293+ <xref target =" core" xref >.
12991294 </t >
13001295 <t >
13011296 Implementations that do not support a vocabulary required by a schema
13041299 <t >
13051300 Implementations that do not support a vocabulary that is optionally used
13061301 by a schema SHOULD proceed with processing the schema. The keywords will
1307- be considered to be unrecognized keywords as addressed by section
1308- <xref target =" unrecognized" format = " counter " xref >. Note that since
1302+ be considered to be unrecognized keywords as addressed by
1303+ <xref target =" unrecognized" xref >. Note that since
13091304 the recommended behavior for such keywords is to collect them as
13101305 annotations, vocabularies consisting only of annotations will have
13111306 the same behavior when used optionally whether the implementation
13411336 </t >
13421337 <t >
13431338 Guidance regarding vocabularies with identically-named keywords is provided
1344- in Appendix <xref target =" vocab-practices" format = " counter " xref >.
1339+ in <xref target =" vocab-practices" xref >.
13451340 </t >
13461341 </section >
13471342 <section title =" Default vocabularies" anchor =" default-vocabs"
14441439 the parent schema resource. Note that an "$id" consisting of an empty IRI or
14451440 of the empty fragment only will result in the embedded resource having
14461441 the same IRI as the encapsulating resource, which SHOULD be considered
1447- an error per section <xref target =" duplicate-iris" format = " counter " xref >.
1442+ an error per <xref target =" duplicate-iris" xref >.
14481443 </t >
14491444 <t >
14501445 If no parent schema object explicitly identifies itself as a resource
14981493 </t >
14991494 <t >
15001495 If present, the value of these keywords MUST be a string and MUST conform
1501- to the plain name fragment identifier syntax defined in section
1502- <xref target =" fragments" format = " counter " xref >.
1496+ to the plain name fragment identifier syntax defined in
1497+ <xref target =" fragments" xref >.
15031498 <cref >
15041499 Note that the anchor string does not include the "#" character,
15051500 as it is not a IRI-reference. An "$anchor": "foo" becomes the
15831578 resolved IRI.
15841579 </t >
15851580 <t >
1586- For a full example using these keyword, see appendix
1587- <xref target =" recursive-example" format =" counter"
1581+ For a full example using these keyword, see <xref target =" recursive-example"
15881582 <cref >
15891583 The difference between the hyper-schema meta-schema in pre-2019
15901584 drafts and an this draft dramatically demonstrates the utility
17241718 on the trust that the validator has in the schema. Such IRIs and schemas
17251719 can be supplied to an implementation prior to processing instances, or may
17261720 be noted within a schema document as it is processed, producing associations
1727- as shown in appendix <xref target =" idExamples" format = " counter " xref >.
1721+ as shown in <xref target =" idExamples" xref >.
17281722 </t >
17291723 </section >
17301724
19261920 <t >
19271921 Further examples of such non-canonical IRI construction, as well as
19281922 the appropriate canonical IRI-based fragments to use instead,
1929- are provided in appendix <xref target =" idExamples" format = " counter " xref >.
1923+ are provided in <xref target =" idExamples" xref >.
19301924 </t >
19311925 </section >
19321926 </section >
25772571 Validation MUST always succeed against this keyword.
25782572 The value of this keyword is used as its annotation result.
25792573 </t >
2580- <t > Per section <xref target =" default-behaviors" format = " counter " xref >,
2574+ <t > Per <xref target =" default-behaviors" xref >,
25812575 omitted keywords MUST NOT produce annotation results. However, as described
25822576 in the section for "contains", the absence of this keyword's annotation
25832577 causes "contains" to assume a minimum value of 1.
@@ -3599,8 +3593,7 @@ https://example.com/schemas/common#/$defs/allOf/1
35993593 media type. See <xref target =" RFC8259" xref >.
36003594 </t >
36013595 <t >
3602- Security considerations: See Section
3603- <xref target =" security" format =" counter" xref > above.
3596+ Security considerations: See <xref target =" security" xref > above.
36043597 </t >
36053598 <t >
36063599 Interoperability considerations: See Sections
@@ -3609,8 +3602,8 @@ https://example.com/schemas/common#/$defs/allOf/1
36093602 <xref target =" regex" format =" counter" xref > above.
36103603 </t >
36113604 <t >
3612- Fragment identifier considerations: See Section
3613- <xref target =" fragments" format = " counter " xref >
3605+ Fragment identifier considerations: See
3606+ <xref target =" fragments" xref >
36143607 </t >
36153608 </list >
36163609 </t >
@@ -3630,8 +3623,7 @@ https://example.com/schemas/common#/$defs/allOf/1
36303623 media type. See <xref target =" RFC8259" xref >.
36313624 </t >
36323625 <t >
3633- Security considerations: See Section
3634- <xref target =" security" format =" counter" xref > above.
3626+ Security considerations: See <xref target =" security" xref > above.
36353627 </t >
36363628 <t >
36373629 Interoperability considerations: See Sections
@@ -3640,8 +3632,7 @@ https://example.com/schemas/common#/$defs/allOf/1
36403632 <xref target =" regex" format =" counter" xref > above.
36413633 </t >
36423634 <t >
3643- Fragment identifier considerations: See Section
3644- <xref target =" fragments" format =" counter" xref >
3635+ Fragment identifier considerations: See <xref target =" fragments" xref >
36453636 </t >
36463637 </list >
36473638 </t >
@@ -3772,8 +3763,7 @@ https://example.com/schemas/common#/$defs/allOf/1
37723763 The schemas at the following IRI-encoded <xref target =" RFC6901"
37733764 Pointers</xref > (relative to the root schema) have the following
37743765 base IRIs, and are identifiable by any listed IRI in accordance with
3775- sections <xref target =" fragments" format =" counter" xref > and
3776- <xref target =" embedded" format =" counter" xref > above.
3766+ <xref target =" fragments" xref > and <xref target =" embedded" xref > above.
37773767 </t >
37783768 <t >
37793769 <list style =" hanging"
0 commit comments