|
1140 | 1140 | </t>
|
1141 | 1141 | </section>
|
1142 | 1142 |
|
| 1143 | + <section title="Collecting Annotations"> |
| 1144 | + <t> |
| 1145 | + <cref> |
| 1146 | + The exact structure and format of the information collected is TBD, |
| 1147 | + but will be defined before the next draft. Some details of this |
| 1148 | + section may change as a result, but the overall process is expected |
| 1149 | + to remain the same. See GitHub issue #396 to track progress. |
| 1150 | + </cref> |
| 1151 | + </t> |
| 1152 | + <t> |
| 1153 | + Annotations are collected by keywords that explicitly define |
| 1154 | + annotation-collecting behavior. Note that boolean schemas cannot |
| 1155 | + produce annotations as they do not make use of keywords. |
| 1156 | + </t> |
| 1157 | + <t> |
| 1158 | + A collected annotation MUST include the following information: |
| 1159 | + <list> |
| 1160 | + <t> |
| 1161 | + The name of the annotation, which MUST be identical to the keyword |
| 1162 | + that defines that annotation. |
| 1163 | + </t> |
| 1164 | + <t> |
| 1165 | + The instance location to which it is attached, as a JSON Pointer |
| 1166 | + </t> |
| 1167 | + <t> |
| 1168 | + The schema location of the attaching keyword, as a list of URIs |
| 1169 | + constructed as described below |
| 1170 | + </t> |
| 1171 | + <t> |
| 1172 | + The attached value(s) |
| 1173 | + </t> |
| 1174 | + </list> |
| 1175 | + </t> |
| 1176 | + <t> |
| 1177 | + If multiple schema locations attach values to the same instance location, |
| 1178 | + and the annotation defines a process for combining such values, then the |
| 1179 | + combined value MUST also be associated with the instance location. |
| 1180 | + </t> |
| 1181 | + <t> |
| 1182 | + Applications MAY make decisions on which of multiple annotation values |
| 1183 | + to use based on the schema location that contributed the value. |
| 1184 | + This is intended to allow flexible usage. Collecting the schema location |
| 1185 | + facilites such usage. |
| 1186 | + </t> |
| 1187 | + <t> |
| 1188 | + For example, one application may consider a "description" annotation that is |
| 1189 | + in the same schema object as a "$ref" to override any "description" in the |
| 1190 | + reference's target schema. A different application may prefer to concatenate |
| 1191 | + all "description" annotations based on whatever ordering it defines. |
| 1192 | + </t> |
| 1193 | + <section title="Annotations and Assertions"> |
| 1194 | + <t> |
| 1195 | + If any keyword in a schema object produces a false assertion |
| 1196 | + result, then all annotations from all keywords in that schema |
| 1197 | + object, and any of its subschemas or referenced schemas, MUST |
| 1198 | + be discarded. |
| 1199 | + </t> |
| 1200 | + <t> |
| 1201 | + This may be due to an assertion keyword directly producing |
| 1202 | + a false result, or an applicator keyword producing a false |
| 1203 | + assertion result as the aggregate assertion result of |
| 1204 | + its subschema(s). |
| 1205 | + </t> |
| 1206 | + </section> |
| 1207 | + <section title="Annotations and Applicators"> |
| 1208 | + <t> |
| 1209 | + In addition to possibly defining annotation results of their own, |
| 1210 | + applicator keywords aggregate the annotations collected in their |
| 1211 | + subschema(s) or referenced schema(s). The rules for aggregating |
| 1212 | + annotation values are defined by each annotation keyword, and are |
| 1213 | + not directly affected by the logic used for combining assertion |
| 1214 | + results. |
| 1215 | + </t> |
| 1216 | + <t> |
| 1217 | + If, in the process of aggregating subscheama results, an applicator |
| 1218 | + keyword modifies a subschema's assertion result to be false, all |
| 1219 | + annotation keywords from that subschema MUST be discarded. |
| 1220 | + </t> |
| 1221 | + <t> |
| 1222 | + Note that this means that an applicator such as <xref target="not">"not"</xref> |
| 1223 | + will never produce annotation results: Either the subschema failed an |
| 1224 | + assertion and discarded its annotations before "not" processes them, or if |
| 1225 | + the subschema passed all assertions, "not" will invert that to a failure, |
| 1226 | + and then discard the annotations before producing its own result. |
| 1227 | + </t> |
| 1228 | + </section> |
| 1229 | + </section> |
| 1230 | + |
1143 | 1231 | <section title="A Vocabulary for Applying Subschemas">
|
1144 | 1232 | <t>
|
1145 | 1233 | This section defines a vocabulary of applicator keywords that
|
|
1213 | 1301 | </t>
|
1214 | 1302 | </section>
|
1215 | 1303 |
|
1216 |
| - <section title="not"> |
| 1304 | + <section title="not" anchor="not"> |
1217 | 1305 | <t>
|
1218 | 1306 | This keyword's value MUST be a valid JSON Schema.
|
1219 | 1307 | </t>
|
|
0 commit comments