Skip to content

Commit f4cfe21

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 3f1b1c4 commit f4cfe21

File tree

1 file changed

+8
-17
lines changed

1 file changed

+8
-17
lines changed

jsonschema-core.xml

+8-17
Original file line numberDiff line numberDiff line change
@@ -757,7 +757,9 @@
757757
</t>
758758
<t>
759759
<xref target="annotations">Annotation</xref> results are
760-
combined according to the rules specified by each annotation keyword.
760+
preserved along with the instance location and the location of
761+
the schema keyword, so that applications can decide how to
762+
interpret multiple values.
761763
</t>
762764
<section title="Referenced and Referencing Schemas" anchor="referenced">
763765
<t>
@@ -852,8 +854,9 @@
852854
<t>
853855
Annotations are attached to specific locations in an instance.
854856
Since many subschemas can be applied to any single
855-
location, annotation keywords need to specify any unusual handling of
856-
multiple applicable occurrences of the keyword with different values.
857+
location, applications may need to decide how to handle differing
858+
annotation values being attached to the same instance location by
859+
the same schema keyword in different schema objects.
857860
</t>
858861
<t>
859862
Unlike assertion results, annotation data can take a wide variety of forms,
@@ -906,14 +909,6 @@
906909
</t>
907910
</list>
908911
</t>
909-
<t>
910-
If the same keyword attaches values from multiple schema locations
911-
to the same instance location, and the annotation defines a process
912-
for combining such values, then the combined value MUST also be associated
913-
with the instance location. The <xref target="output">output formats</xref>
914-
described in this specification that include annotation information
915-
meet this requirement.
916-
</t>
917912
<section title="Distinguishing Among Multiple Values">
918913
<t>
919914
Applications MAY make decisions on which of multiple annotation values
@@ -973,8 +968,7 @@
973968
<t>
974969
In this example, both Feature A and Feature B make use of the re-usable
975970
"enabledToggle" schema. That schema uses the "title", "description",
976-
and "default" annotations, none of which define special behavior for
977-
handling multiple values. Therefore the application has to decide how
971+
and "default" annotations. Therefore the application has to decide how
978972
to handle the additional "default" value for Feature A, and the additional
979973
"description" value for Feature B.
980974
</t>
@@ -1048,10 +1042,7 @@
10481042
<t>
10491043
In addition to possibly defining annotation results of their own,
10501044
applicator keywords aggregate the annotations collected in their
1051-
subschema(s) or referenced schema(s). The rules for aggregating
1052-
annotation values are defined by each annotation keyword, and are
1053-
not directly affected by the logic used for combining assertion
1054-
results.
1045+
subschema(s) or referenced schema(s).
10551046
</t>
10561047
</section>
10571048
</section>

0 commit comments

Comments
 (0)