|
200 | 200 | <t> |
201 | 201 | A JSON document to which a schema is applied is known as an "instance". |
202 | 202 | </t> |
| 203 | + <t> |
| 204 | + JSON Schema is defined over "application/json" or compatible documents, |
| 205 | + including media types with the "+json" structured syntax suffix. |
| 206 | + </t> |
| 207 | + <t> |
| 208 | + Among these, this specification defines the "application/schema-instance+json" |
| 209 | + media type which defines handling for fragments in the URI, |
| 210 | + and the "schema" media type parameter. |
| 211 | + </t> |
203 | 212 |
|
204 | 213 | <section title="Instance Data Model"> |
205 | 214 | <t> |
|
243 | 252 | </t> |
244 | 253 | </section> |
245 | 254 |
|
246 | | - <section title="Instance Media Types"> |
247 | | - <t> |
248 | | - JSON Schema is designed to fully work with "application/json" documents, |
249 | | - as well as media types using the "+json" structured syntax suffix. |
250 | | - </t> |
251 | | - <t> |
252 | | - Some functionality that is useful for working with schemas is |
253 | | - defined by each media type, namely media type parameters and |
254 | | - URI fragment identifier syntax and semantics. These features are |
255 | | - useful in content negotiation and in calculating URIs for specific |
256 | | - locations within an instance, respectively. |
257 | | - </t> |
258 | | - <t> |
259 | | - This specification defines the "application/schema-instance+json" |
260 | | - media type in order to allow instance authors to take full advantage |
261 | | - of parameters and fragment identifiers for these purposes. |
262 | | - </t> |
263 | | - </section> |
264 | | - |
265 | 255 | <section title="Instance Equality"> |
266 | 256 | <t> |
267 | 257 | Two JSON instances are said to be equal if and only if they are of the same type |
|
288 | 278 | zeros) are insignificant. |
289 | 279 | </t> |
290 | 280 | </section> |
| 281 | + |
| 282 | + <section title="Non-JSON Instances"> |
| 283 | + <t> |
| 284 | + It is possible to use JSON Schema with a superset of the JSON Schema data model, |
| 285 | + where an instance may be outside any of the six JSON data types. |
| 286 | + </t> |
| 287 | + <t> |
| 288 | + In this case, annotations still apply; but validation keywords will not be useful. |
| 289 | + Validations that apply only to one of the core types will always pass, |
| 290 | + and other keywords will fail. |
| 291 | + </t> |
| 292 | + <t> |
| 293 | + A custom vocabulary may define support for a superset of the core data model. |
| 294 | + The schema itself may only be expressible in this superset; |
| 295 | + for example, to make use of the "const" keyword. |
| 296 | + </t> |
| 297 | + <t> |
| 298 | + New data model types may be defined as either supersets of an existing type |
| 299 | + (similar to how "number" is a superset of "integer"), |
| 300 | + or a type disjoint from the core data model altogether (like "binary"). |
| 301 | + Existing keywords may be updated to define behavior for the new range of values, |
| 302 | + but vocabularies that intend to be compatible with JSON Schema Validation should not |
| 303 | + change the behavior for existing types. |
| 304 | + </t> |
| 305 | + <t> |
| 306 | + Drawing on the "binary" example, |
| 307 | + a custom vocabulary may define what it means to use a "binary" data type |
| 308 | + in the "const" keyword, or the meaning of "minLength" when the instance is a "binary", |
| 309 | + but for the sake of consistency, it should not change the behavior when the instance is a string. |
| 310 | + </t> |
| 311 | + </section> |
291 | 312 | </section> |
292 | 313 |
|
293 | 314 | <section title="JSON Schema Documents" anchor="schema-document"> |
|
0 commit comments