|
126 | 126 | <section title="Keyword Behaviors">
|
127 | 127 | <t>
|
128 | 128 | JSON Schema keywords fall into several general behavior categories.
|
129 |
| - Assertions validate that an instance satisfies constraints. Annotations |
130 |
| - attach information that applications may use in any way they see fit. |
| 129 | + Assertions validate that an instance satisfies constraints, producing |
| 130 | + a boolean result. Annotations attach information that applications |
| 131 | + may use in any way they see fit. |
131 | 132 | Applicators apply subschemas to parts of the instance and combine
|
132 | 133 | their results.
|
133 | 134 | </t>
|
|
145 | 146 | subschemas have been evaluated, although in some circumstance evaluation
|
146 | 147 | may be short-circuited due to assertion results.
|
147 | 148 | </t>
|
| 149 | + <t> |
| 150 | + Keyword behavior MAY be defined in terms of the annotation results |
| 151 | + of <xref target="root">subschemas</xref> and/or adjacent keywords. |
| 152 | + Such keywords MUST NOT result in a circular dependency. |
| 153 | + Keywords MAY modify their behavior based on the presence or absence |
| 154 | + of another keyword in the same |
| 155 | + <xref target="schema-document">schema object</xref>. |
| 156 | + </t> |
| 157 | + <t> |
| 158 | + A missing keyword MUST NOT produce a false assertion result, MUST |
| 159 | + NOT produce annotation results, and MUST NOT cause any other schema |
| 160 | + to be evaluated as part of its own behavioral definition. |
| 161 | + However, given that missing keywords do not contribute annotations, |
| 162 | + the lack of annotation results may indirectly change the behavior |
| 163 | + of other keywords. |
| 164 | + </t> |
| 165 | + <t> |
| 166 | + In some cases, the missing keyword assertion behavior of a keyword is |
| 167 | + identical to that produced by a certain value, and keyword definitions |
| 168 | + SHOULD note such values where known. However, even if the value which |
| 169 | + produces the default behavior would produce annotation results if |
| 170 | + present, the default behavior still MUST NOT result in annotations. |
| 171 | + </t> |
| 172 | + <t> |
| 173 | + Because annotation collection can add significant cost in terms of both |
| 174 | + computation and memory, implementations MAY opt out of this feature. |
| 175 | + Keywords known to an implementation to have assertion or applicator behavior |
| 176 | + that depend on annotation results MUST then be treated as errors, unless |
| 177 | + an alternate implementation producing the same behavior is available. |
| 178 | + Keywords of this sort SHOULD describe reasonable alternate approaches |
| 179 | + when appropriate. |
| 180 | + </t> |
148 | 181 | <t>
|
149 | 182 | Extension keywords SHOULD stay within these categories, keeping in mind
|
150 | 183 | that annotations in particular are extremely flexible. Complex behavior
|
|
190 | 223 | </t>
|
191 | 224 | <t>
|
192 | 225 | An instance can only fail an assertion that is present in the schema.
|
193 |
| - In some cases, this no-op behavior is identical to a keyword that exists with |
194 |
| - certain values, and keyword definitions SHOULD note such values where known. |
195 |
| - These default behaviors MUST NOT result in assertion failures. |
| 226 | + |
196 | 227 | </t>
|
197 | 228 | <section title="Assertions and Instance Primitive Types">
|
198 | 229 | <t>
|
|
0 commit comments