|  | 
| 158 | 158 | 
 | 
| 159 | 159 |  <section title="General validation considerations"> | 
| 160 | 160 | 
 | 
| 161 |  | - <section title="Keywords and instance primitive types"> | 
|  | 161 | + <section title="Constraints and missing keywords"> | 
| 162 | 162 |  <t> | 
| 163 |  | - Most validation keywords only limit the range of values within a certain primitive type. | 
| 164 |  | - When the primitive type of the instance is not of the type targeted by the keyword, the | 
| 165 |  | - validation succeeds. | 
|  | 163 | + Each JSON Schema validation keyword adds constraints that | 
|  | 164 | + an instance must satisfy in order to successfully validate. | 
| 166 | 165 |  </t> | 
| 167 | 166 |  <t> | 
| 168 |  | - For example, the "maxLength" keyword will only restrict certain strings (that are too long) from being valid. | 
| 169 |  | - If the instance is a number, boolean, null, array, or object, the keyword passes validation. | 
| 170 |  | - </t> | 
|  | 167 | + Validation keywords that are missing never restrict validation. | 
|  | 168 | + In some cases, this no-op behavior is identical to a keyword that | 
|  | 169 | + exists with certain values, and these values are noted where relevant. | 
|  | 170 | + </t> | 
|  | 171 | + <figure> | 
|  | 172 | + <preamble> | 
|  | 173 | + From this principle, it follows that all JSON values | 
|  | 174 | + successfully validate against the empty schema: | 
|  | 175 | + </preamble> | 
|  | 176 | + <artwork> | 
|  | 177 | +<![CDATA[ | 
|  | 178 | +{} | 
|  | 179 | +]]> | 
|  | 180 | + </artwork> | 
|  | 181 | + </figure> | 
|  | 182 | + <figure> | 
|  | 183 | + <preamble> | 
|  | 184 | + Similarly, it follows that no JSON value successfully | 
|  | 185 | + validates against the empty schema's negation: | 
|  | 186 | + </preamble> | 
|  | 187 | + <artwork> | 
|  | 188 | +<![CDATA[ | 
|  | 189 | +{ | 
|  | 190 | + "not": {} | 
|  | 191 | +} | 
|  | 192 | +]]> | 
|  | 193 | + </artwork> | 
|  | 194 | + </figure> | 
| 171 | 195 |  </section> | 
| 172 | 196 | 
 | 
| 173 |  | - <section title="Validation of primitive types and child values"> | 
| 174 |  | - <t> | 
| 175 |  | - Two of the primitive types, array and object, allow for child values. The validation of | 
| 176 |  | - the primitive type is considered separately from the validation of child instances. | 
| 177 |  | - </t> | 
|  | 197 | + <section title="Keyword independence"> | 
| 178 | 198 |  <t> | 
| 179 |  | - For arrays, primitive type validation consists of validating restrictions on length. | 
|  | 199 | + Validation keywords typically operate independently, without | 
|  | 200 | + affecting each other's outcomes. | 
| 180 | 201 |  </t> | 
| 181 | 202 |  <t> | 
| 182 |  | - For objects, primitive type validation consists of validating restrictions on the presence | 
| 183 |  | - or absence of property names. | 
| 184 |  | - </t> | 
| 185 |  | - </section> | 
| 186 |  | - | 
| 187 |  | - <section title="Missing keywords"> | 
| 188 |  | - <t> | 
| 189 |  | - Validation keywords that are missing never restrict validation. | 
| 190 |  | - In some cases, this no-op behavior is identical to a keyword that exists with certain values, | 
| 191 |  | - and these values are noted where known. | 
|  | 203 | + For schema author convenience, there are some exceptions: | 
|  | 204 | + <list> | 
|  | 205 | +	 <t>"additionalProperties", whose behavior is defined in terms of "properties" and "patternProperties"</t> | 
|  | 206 | + <t>"additionalItems", whose behavior is defined in terms of "items"</t> | 
|  | 207 | + <t>"minimum" and "maximum", whose behavior may change for a special value of "exclusiveMinimum" and "exclusiveMaximum", respectively</t> | 
|  | 208 | + </list> | 
|  | 209 | + </list> | 
| 192 | 210 |  </t> | 
| 193 | 211 |  </section> | 
| 194 | 212 | 
 | 
| 195 |  | - <section title="Linearity"> | 
| 196 |  | - <!-- I call this "linear" in the same manner e.g. waves are linear, they don't interact with each other --> | 
|  | 213 | + <section title="Keywords and instance primitive types"> | 
| 197 | 214 |  <t> | 
| 198 |  | - Validation keywords typically operate independent of each other, without affecting each other. | 
|  | 215 | + Most validation keywords only limit the range of values within a certain primitive type. | 
|  | 216 | + When the primitive type of the instance is not of the type targeted by the keyword, the | 
|  | 217 | + validation succeeds. | 
| 199 | 218 |  </t> | 
| 200 | 219 |  <t> | 
| 201 |  | - For author convenience, there are some exceptions: | 
| 202 |  | - <list> | 
| 203 |  | - <t>"additionalProperties", whose behavior is defined in terms of "properties" and "patternProperties";</t> | 
| 204 |  | - <t>"additionalItems", whose behavior is defined in terms of "items"; and</t> | 
| 205 |  | - <t>"minimum" and "maximum", whose behavior may change for a special value of "exclusiveMinimum" and "exclusiveMaximum", respectively.</t> | 
| 206 |  | - </list> | 
|  | 220 | + For example, the "maxLength" keyword will only restrict certain strings (that are too long) from being valid. | 
|  | 221 | + If the instance is a number, boolean, null, array, or object, the keyword passes validation. | 
| 207 | 222 |  </t> | 
| 208 | 223 |  </section> | 
| 209 |  | - | 
| 210 | 224 |  </section> | 
| 211 | 225 | 
 | 
| 212 | 226 |  <section title="Meta-schema"> | 
|  | 
0 commit comments