From d29e9c45183b457845014b870445ca29f4777be7 Mon Sep 17 00:00:00 2001 From: Austin Wright Date: Wed, 7 Dec 2022 17:22:36 -0700 Subject: [PATCH] Remove some superfluous format="counter" attributes --- jsonschema-core.xml | 64 +++++++++++++++++++-------------------------- 1 file changed, 27 insertions(+), 37 deletions(-) diff --git a/jsonschema-core.xml b/jsonschema-core.xml index f006d658..fabcfedc 100644 --- a/jsonschema-core.xml +++ b/jsonschema-core.xml @@ -352,8 +352,7 @@ A JSON Schema MAY contain properties which are not schema keywords or are not recognized as schema keywords. - The behavior of such keywords is governed by section - . + The behavior of such keywords is governed by . An empty schema is a JSON Schema with no properties. @@ -439,8 +438,7 @@ The root schema is the schema that comprises the entire JSON document in question. The root schema is always a schema resource, where the - IRI is determined as described in section - . + IRI is determined as described in . Note that documents that embed schemas in another format will not have a root schema resource in this sense. Exactly how such usages @@ -471,8 +469,7 @@ As with the root schema, a subschema is either an object or a boolean. - As discussed in section - , a JSON Schema document + As discussed in , a JSON Schema document can contain multiple JSON Schema resources. When used without qualification, the term "root schema" refers to the document's root schema. In some cases, resource root schemas are discussed. A resource's root schema @@ -657,10 +654,9 @@ location in the instance is evaluated against the assertion and annotation keywords in the schema object. The interactions of those keyword results to produce the schema object results are governed by - section , while the + , while the relationship of subschema results to the results of the applicator - keyword that applied them is described by section - . + keyword that applied them is described by . Evaluation of a parent schema object can complete once all of its @@ -816,8 +812,7 @@ Annotation results from subschemas - are preserved in accordance with section - so that applications + are preserved in accordance with so that applications can decide how to interpret multiple values. Applicator keywords do not play a direct role in this preservation. @@ -1110,8 +1105,8 @@ keywords. - While these keywords do not directly affect results, as explained in section - unrecognized + While these keywords do not directly affect results, as explained in + unrecognized extension keywords that reserve locations for re-usable schemas may have undesirable interactions with references in certain circumstances. @@ -1283,7 +1278,7 @@ or link relation types, or through documented default implementation-defined behavior in the absence of an explicit meta-schema. If a meta-schema does not contain "$vocabulary", the set of vocabularies in use is determined - according to section . + according to . Any vocabulary in use by a schema and understood by the implementation @@ -1294,8 +1289,8 @@ Any vocabulary that is not present in "$vocabulary" MUST NOT be made available for use in schemas described by that meta-schema, except for - the core vocabulary as specified by the introduction to section - . + the core vocabulary as specified by the introduction to + . Implementations that do not support a vocabulary required by a schema @@ -1304,8 +1299,8 @@ Implementations that do not support a vocabulary that is optionally used by a schema SHOULD proceed with processing the schema. The keywords will - be considered to be unrecognized keywords as addressed by section - . Note that since + be considered to be unrecognized keywords as addressed by + . Note that since the recommended behavior for such keywords is to collect them as annotations, vocabularies consisting only of annotations will have the same behavior when used optionally whether the implementation @@ -1341,7 +1336,7 @@ Guidance regarding vocabularies with identically-named keywords is provided - in Appendix . + in .
@@ -1444,7 +1439,7 @@ the parent schema resource. Note that an "$id" consisting of an empty IRI or of the empty fragment only will result in the embedded resource having the same IRI as the encapsulating resource, which SHOULD be considered - an error per section . + an error per . If no parent schema object explicitly identifies itself as a resource @@ -1498,8 +1493,8 @@ If present, the value of these keywords MUST be a string and MUST conform - to the plain name fragment identifier syntax defined in section - . + to the plain name fragment identifier syntax defined in + . Note that the anchor string does not include the "#" character, as it is not a IRI-reference. An "$anchor": "foo" becomes the @@ -1583,8 +1578,7 @@ resolved IRI. - For a full example using these keyword, see appendix - . + For a full example using these keyword, see . The difference between the hyper-schema meta-schema in pre-2019 drafts and an this draft dramatically demonstrates the utility @@ -1724,7 +1718,7 @@ on the trust that the validator has in the schema. Such IRIs 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 . + as shown in .
@@ -1926,7 +1920,7 @@ Further examples of such non-canonical IRI construction, as well as the appropriate canonical IRI-based fragments to use instead, - are provided in appendix . + are provided in . @@ -2577,7 +2571,7 @@ Validation MUST always succeed against this keyword. The value of this keyword is used as its annotation result. - Per section , + Per , omitted keywords MUST NOT produce annotation results. However, as described in the section for "contains", the absence of this keyword's annotation causes "contains" to assume a minimum value of 1. @@ -3599,8 +3593,7 @@ https://example.com/schemas/common#/$defs/allOf/1 media type. See JSON. - Security considerations: See Section - above. + Security considerations: See above. Interoperability considerations: See Sections @@ -3609,8 +3602,8 @@ https://example.com/schemas/common#/$defs/allOf/1 above. - Fragment identifier considerations: See Section - + Fragment identifier considerations: See + @@ -3630,8 +3623,7 @@ https://example.com/schemas/common#/$defs/allOf/1 media type. See JSON. - Security considerations: See Section - above. + Security considerations: See above. Interoperability considerations: See Sections @@ -3640,8 +3632,7 @@ https://example.com/schemas/common#/$defs/allOf/1 above. - Fragment identifier considerations: See Section - + Fragment identifier considerations: See @@ -3772,8 +3763,7 @@ https://example.com/schemas/common#/$defs/allOf/1 The schemas at the following IRI-encoded JSON Pointers (relative to the root schema) have the following base IRIs, and are identifiable by any listed IRI in accordance with - sections and - above. + and above.