Skip to content

Commit efe6664

Browse files
committed
Remove special case handling of annotation values
The approach of annotation keywords specifying combination rules is not really compatible with the output format approach. It is also a source of uncertainty in how to use and specify annotations. This removes the concept. Note that "readOnly", "writeOnly", and "deprecated" still advise applications on how to handle multiple values. However, the wording is purely in terms of application handling and not in terms of aggregating the values, so no change to the validation spec is necessary.
1 parent d432786 commit efe6664

File tree

1 file changed

+8
-17
lines changed

1 file changed

+8
-17
lines changed

jsonschema-core.xml

Lines changed: 8 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -770,7 +770,9 @@
770770
</t>
771771
<t>
772772
<xref target="annotations">Annotation</xref> results are
773-
combined according to the rules specified by each annotation keyword.
773+
preserved along with the instance location and the location of
774+
the schema keyword, so that applications can decide how to
775+
interpret multiple values.
774776
</t>
775777
<section title="Referenced and Referencing Schemas" anchor="referenced">
776778
<t>
@@ -865,8 +867,9 @@
865867
<t>
866868
Annotations are attached to specific locations in an instance.
867869
Since many subschemas can be applied to any single
868-
location, annotation keywords need to specify any unusual handling of
869-
multiple applicable occurrences of the keyword with different values.
870+
location, applications may need to decide how to handle differing
871+
annotation values being attached to the same instance location by
872+
the same schema keyword in different schema objects.
870873
</t>
871874
<t>
872875
Unlike assertion results, annotation data can take a wide variety of forms,
@@ -919,14 +922,6 @@
919922
</t>
920923
</list>
921924
</t>
922-
<t>
923-
If the same keyword attaches values from multiple schema locations
924-
to the same instance location, and the annotation defines a process
925-
for combining such values, then the combined value MUST also be associated
926-
with the instance location. The <xref target="output">output formats</xref>
927-
described in this specification that include annotation information
928-
meet this requirement.
929-
</t>
930925
<section title="Distinguishing Among Multiple Values">
931926
<t>
932927
Applications MAY make decisions on which of multiple annotation values
@@ -986,8 +981,7 @@
986981
<t>
987982
In this example, both Feature A and Feature B make use of the re-usable
988983
"enabledToggle" schema. That schema uses the "title", "description",
989-
and "default" annotations, none of which define special behavior for
990-
handling multiple values. Therefore the application has to decide how
984+
and "default" annotations. Therefore the application has to decide how
991985
to handle the additional "default" value for Feature A, and the additional
992986
"description" value for Feature B.
993987
</t>
@@ -1061,10 +1055,7 @@
10611055
<t>
10621056
In addition to possibly defining annotation results of their own,
10631057
applicator keywords aggregate the annotations collected in their
1064-
subschema(s) or referenced schema(s). The rules for aggregating
1065-
annotation values are defined by each annotation keyword, and are
1066-
not directly affected by the logic used for combining assertion
1067-
results.
1058+
subschema(s) or referenced schema(s).
10681059
</t>
10691060
</section>
10701061
</section>

0 commit comments

Comments
 (0)