idnits 2.17.1 draft-handrews-json-schema-validation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 19, 2018) is 2223 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2673 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 4329 (Obsoleted by RFC 9239) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Wright, Ed. 3 Internet-Draft 4 Intended status: Informational H. Andrews, Ed. 5 Expires: September 20, 2018 Cloudflare, Inc. 6 G. Luff 7 March 19, 2018 9 JSON Schema Validation: A Vocabulary for Structural Validation of JSON 10 draft-handrews-json-schema-validation-01 12 Abstract 14 JSON Schema (application/schema+json) has several purposes, one of 15 which is JSON instance validation. This document specifies a 16 vocabulary for JSON Schema to describe the meaning of JSON documents, 17 provide hints for user interfaces working with JSON data, and to make 18 assertions about what a valid document must look like. 20 Note to Readers 22 The issues list for this draft can be found at . 25 For additional information, see . 27 To provide feedback, use this issue tracker, the communication 28 methods listed on the homepage, or email the document editors. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 20, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 66 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1.1. Keyword Independence . . . . . . . . . . . . . . . . 5 69 3.2. Assertions . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2.1. Assertions and Instance Primitive Types . . . . . . . 6 71 3.3. Annotations . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.3.1. Annotations and Validation Outcomes . . . . . . . . . 7 73 3.3.2. Annotations and Short-Circuit Validation . . . . . . 7 74 4. Interoperability Considerations . . . . . . . . . . . . . . . 7 75 4.1. Validation of String Instances . . . . . . . . . . . . . 7 76 4.2. Validation of Numeric Instances . . . . . . . . . . . . . 7 77 4.3. Regular Expressions . . . . . . . . . . . . . . . . . . . 7 78 5. Meta-Schema . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 6. Validation Keywords . . . . . . . . . . . . . . . . . . . . . 8 80 6.1. Validation Keywords for Any Instance Type . . . . . . . . 8 81 6.1.1. type . . . . . . . . . . . . . . . . . . . . . . . . 8 82 6.1.2. enum . . . . . . . . . . . . . . . . . . . . . . . . 9 83 6.1.3. const . . . . . . . . . . . . . . . . . . . . . . . . 9 84 6.2. Validation Keywords for Numeric Instances (number and 85 integer) . . . . . . . . . . . . . . . . . . . . . . . . 9 86 6.2.1. multipleOf . . . . . . . . . . . . . . . . . . . . . 9 87 6.2.2. maximum . . . . . . . . . . . . . . . . . . . . . . . 9 88 6.2.3. exclusiveMaximum . . . . . . . . . . . . . . . . . . 9 89 6.2.4. minimum . . . . . . . . . . . . . . . . . . . . . . . 10 90 6.2.5. exclusiveMinimum . . . . . . . . . . . . . . . . . . 10 91 6.3. Validation Keywords for Strings . . . . . . . . . . . . . 10 92 6.3.1. maxLength . . . . . . . . . . . . . . . . . . . . . . 10 93 6.3.2. minLength . . . . . . . . . . . . . . . . . . . . . . 10 94 6.3.3. pattern . . . . . . . . . . . . . . . . . . . . . . . 10 96 6.4. Validation Keywords for Arrays . . . . . . . . . . . . . 11 97 6.4.1. items . . . . . . . . . . . . . . . . . . . . . . . . 11 98 6.4.2. additionalItems . . . . . . . . . . . . . . . . . . . 11 99 6.4.3. maxItems . . . . . . . . . . . . . . . . . . . . . . 11 100 6.4.4. minItems . . . . . . . . . . . . . . . . . . . . . . 12 101 6.4.5. uniqueItems . . . . . . . . . . . . . . . . . . . . . 12 102 6.4.6. contains . . . . . . . . . . . . . . . . . . . . . . 12 103 6.5. Validation Keywords for Objects . . . . . . . . . . . . . 12 104 6.5.1. maxProperties . . . . . . . . . . . . . . . . . . . . 12 105 6.5.2. minProperties . . . . . . . . . . . . . . . . . . . . 12 106 6.5.3. required . . . . . . . . . . . . . . . . . . . . . . 13 107 6.5.4. properties . . . . . . . . . . . . . . . . . . . . . 13 108 6.5.5. patternProperties . . . . . . . . . . . . . . . . . . 13 109 6.5.6. additionalProperties . . . . . . . . . . . . . . . . 14 110 6.5.7. dependencies . . . . . . . . . . . . . . . . . . . . 14 111 6.5.8. propertyNames . . . . . . . . . . . . . . . . . . . . 15 112 6.6. Keywords for Applying Subschemas Conditionally . . . . . 15 113 6.6.1. if . . . . . . . . . . . . . . . . . . . . . . . . . 15 114 6.6.2. then . . . . . . . . . . . . . . . . . . . . . . . . 16 115 6.6.3. else . . . . . . . . . . . . . . . . . . . . . . . . 16 116 6.7. Keywords for Applying Subschemas With Boolean Logic . . . 16 117 6.7.1. allOf . . . . . . . . . . . . . . . . . . . . . . . . 16 118 6.7.2. anyOf . . . . . . . . . . . . . . . . . . . . . . . . 16 119 6.7.3. oneOf . . . . . . . . . . . . . . . . . . . . . . . . 17 120 6.7.4. not . . . . . . . . . . . . . . . . . . . . . . . . . 17 121 7. Semantic Validation With "format" . . . . . . . . . . . . . . 17 122 7.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . 17 123 7.2. Implementation Requirements . . . . . . . . . . . . . . . 17 124 7.3. Defined Formats . . . . . . . . . . . . . . . . . . . . . 18 125 7.3.1. Dates and Times . . . . . . . . . . . . . . . . . . . 18 126 7.3.2. Email Addresses . . . . . . . . . . . . . . . . . . . 18 127 7.3.3. Hostnames . . . . . . . . . . . . . . . . . . . . . . 19 128 7.3.4. IP Addresses . . . . . . . . . . . . . . . . . . . . 19 129 7.3.5. Resource Identifiers . . . . . . . . . . . . . . . . 19 130 7.3.6. uri-template . . . . . . . . . . . . . . . . . . . . 20 131 7.3.7. JSON Pointers . . . . . . . . . . . . . . . . . . . . 20 132 7.3.8. regex . . . . . . . . . . . . . . . . . . . . . . . . 20 133 8. String-Encoding Non-JSON Data . . . . . . . . . . . . . . . . 21 134 8.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . 21 135 8.2. Implementation Requirements . . . . . . . . . . . . . . . 21 136 8.3. contentEncoding . . . . . . . . . . . . . . . . . . . . . 21 137 8.4. contentMediaType . . . . . . . . . . . . . . . . . . . . 21 138 8.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 22 139 9. Schema Re-Use With "definitions" . . . . . . . . . . . . . . 22 140 10. Schema Annotations . . . . . . . . . . . . . . . . . . . . . 23 141 10.1. "title" and "description" . . . . . . . . . . . . . . . 23 142 10.2. "default" . . . . . . . . . . . . . . . . . . . . . . . 23 143 10.3. "readOnly" and "writeOnly" . . . . . . . . . . . . . . . 24 144 10.4. "examples" . . . . . . . . . . . . . . . . . . . . . . . 24 145 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 146 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 147 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 148 12.2. Informative References . . . . . . . . . . . . . . . . . 27 149 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 28 150 Appendix B. ChangeLog . . . . . . . . . . . . . . . . . . . . . 28 151 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 153 1. Introduction 155 JSON Schema can be used to require that a given JSON document (an 156 instance) satisfies a certain number of criteria. These criteria are 157 asserted by using keywords described in this specification. In 158 addition, a set of keywords is also defined to assist in interactive 159 user interface instance generation. 161 This specification will use the concepts, syntax, and terminology 162 defined by the JSON Schema core [json-schema] specification. 164 2. Conventions and Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 This specification uses the term "container instance" to refer to 171 both array and object instances. It uses the term "children 172 instances" to refer to array elements or object member values. 174 Elements in an array value are said to be unique if no two elements 175 of this array are equal [json-schema]. 177 3. Overview 179 JSON Schema validation applies schemas to locations within the 180 instance, and asserts constraints on the structure of the data at 181 each location. An instance location that satisfies all asserted 182 constraints is then annotated with any keywords that contain non- 183 assertion information, such as descriptive metadata and usage hints. 184 If all locations within the instance satisfy all asserted 185 constraints, then the instance is said to be valid against the 186 schema. 188 Each schema object is independently evaluated against each instance 189 location to which it applies. This greatly simplifies the 190 implementation requirements for validators by ensuring that they do 191 not need to maintain state across the document-wide validation 192 process. 194 3.1. Applicability 196 Validation begins by applying the root schema to the complete 197 instance document. From there, various keywords are used to 198 determine which additional subschemas are applied to either the 199 current location, or a child location. These keywords also define 200 whether and how subschema assertion results are modified and/or 201 combined. Such keywords do not assert conditions on their own. 202 Rather, they control how assertions are applied and evaluated. 204 The keywords in the boolean logic (Section 6.7) and conditional 205 (Section 6.6) sections of this specification apply subschemas to the 206 same location as the parent schema. The former group defines boolean 207 operations on the subschema assertion results, while the latter 208 evaluates one subschema and uses its assertion results to determine 209 which of two other subschemas to apply as well. 211 Several keywords determine which subschemas are applied to array 212 items, object property values, and object property names. They are: 213 "items", "additionalItems", "contains", "properties", 214 "patternProperties", "additionalProperties", and "propertyNames". 215 The "contains" keyword only requires its subschema to be valid 216 against at least one child instance, while the other keywords require 217 that all subschemas are valid against all child instances to which 218 they apply. 220 3.1.1. Keyword Independence 222 Validation keywords typically operate independently, without 223 affecting each other's outcomes. 225 For schema author convenience, there are some exceptions among the 226 keywords that control subschema applicability: 228 "additionalProperties", whose behavior is defined in terms of 229 "properties" and "patternProperties"; and 231 "additionalItems", whose behavior is defined in terms of "items". 233 3.2. Assertions 235 Validation is a process of checking assertions. Each assertion adds 236 constraints that an instance must satisfy in order to successfully 237 validate. 239 Assertion keywords that are absent never restrict validation. In 240 some cases, this no-op behavior is identical to a keyword that exists 241 with certain values, and these values are noted where known. 243 All of the keywords in the general (Section 6.1), numeric 244 (Section 6.2), and string (Section 6.3) sections are assertions, as 245 well as "minItems", "maxItems", "uniqueItems", "minProperties", 246 "maxProperties", and "required". Additionally, "dependencies" is 247 shorthand for a combination of conditional and assertion keywords. 249 The "format", "contentType", and "contentEncoding" keywords can also 250 be implemented as assertions, although that functionality is an 251 optional part of this specification, and the keywords convey 252 additional non-assertion information. 254 3.2.1. Assertions and Instance Primitive Types 256 Most validation assertions only constrain values within a certain 257 primitive type. When the type of the instance is not of the type 258 targeted by the keyword, the instance is considered to conform to the 259 assertion. 261 For example, the "maxLength" keyword will only restrict certain 262 strings (that are too long) from being valid. If the instance is a 263 number, boolean, null, array, or object, then it is valid against 264 this assertion. 266 3.3. Annotations 268 In addition to assertions, this specification provides a small 269 vocabulary of metadata keywords that can be used to annotate the JSON 270 instance with useful information. The Section 7 and Section 8 271 keywords are also useful as annotations as well as being optional 272 assertions, as they convey additional usage guidance for the instance 273 data. 275 A schema that is applicable to a particular location in the instance, 276 against which the instance location is valid, attaches its 277 annotations to that location in the instance. Since many subschemas 278 can be applicable to any single location, annotation keywords need to 279 specify any unusual handling of multiple applicable occurrences of 280 the keyword with different values. The default behavior is simply to 281 collect all values. 283 Additional vocabularies SHOULD make use of this mechanism for 284 applying their own annotations to instances. 286 3.3.1. Annotations and Validation Outcomes 288 Annotations are collected whenever an instance is valid against a 289 schema object, and all of that schema object's parent schemas. 291 In particular, annotations in a subschema contained within a "not", 292 at any depth, including any number of intervening additional "not" 293 subschemas, MUST be ignored. If the instance was valid against the 294 "not" subschema, then by definition it is not valid against the 295 schema that contains the "not", so the "not" subschema's annotations 296 are not used. 298 Similarly, annotations within a failing branch of a "oneOf", "anyOf", 299 "then", or "else" MUST be ignored even when the instance successfully 300 validates against the complete schema document. 302 3.3.2. Annotations and Short-Circuit Validation 304 Annotation keywords MUST be applied to all possible sub-instances. 305 Even if such application can be short-circuited when only assertion 306 evaluation is needed. For instance, the "contains" keyword need only 307 be checked for assertions until at least one array item proves valid. 308 However, when working with annotations, all items in the array must 309 be evaluated to determine all items with which the annotations should 310 be associated. 312 4. Interoperability Considerations 314 4.1. Validation of String Instances 316 It should be noted that the nul character (\u0000) is valid in a JSON 317 string. An instance to validate may contain a string value with this 318 character, regardless of the ability of the underlying programming 319 language to deal with such data. 321 4.2. Validation of Numeric Instances 323 The JSON specification allows numbers with arbitrary precision, and 324 JSON Schema does not add any such bounds. This means that numeric 325 instances processed by JSON Schema can be arbitrarily large and/or 326 have an arbitrarily long decimal part, regardless of the ability of 327 the underlying programming language to deal with such data. 329 4.3. Regular Expressions 331 Two validation keywords, "pattern" and "patternProperties", use 332 regular expressions to express constraints, and the "regex" value for 333 the "format" keyword constrains the instance value to be a regular 334 expression. These regular expressions SHOULD be valid according to 335 the ECMA 262 [ecma262] regular expression dialect. 337 Furthermore, given the high disparity in regular expression 338 constructs support, schema authors SHOULD limit themselves to the 339 following regular expression tokens: 341 individual Unicode characters, as defined by the JSON 342 specification [RFC7159]; 344 simple character classes ([abc]), range character classes ([a-z]); 346 complemented character classes ([^abc], [^a-z]); 348 simple quantifiers: "+" (one or more), "*" (zero or more), "?" 349 (zero or one), and their lazy versions ("+?", "*?", "??"); 351 range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at 352 least x, at most y, occurrences), {x,} (x occurrences or more), 353 and their lazy versions; 355 the beginning-of-input ("^") and end-of-input ("$") anchors; 357 simple grouping ("(...)") and alternation ("|"). 359 Finally, implementations MUST NOT take regular expressions to be 360 anchored, neither at the beginning nor at the end. This means, for 361 instance, the pattern "es" matches "expression". 363 5. Meta-Schema 365 The current URI for the JSON Schema Validation is . 368 6. Validation Keywords 370 Validation keywords in a schema impose requirements for successful 371 validation of an instance. 373 6.1. Validation Keywords for Any Instance Type 375 6.1.1. type 377 The value of this keyword MUST be either a string or an array. If it 378 is an array, elements of the array MUST be strings and MUST be 379 unique. 381 String values MUST be one of the six primitive types ("null", 382 "boolean", "object", "array", "number", or "string"), or "integer" 383 which matches any number with a zero fractional part. 385 An instance validates if and only if the instance is in any of the 386 sets listed for this keyword. 388 6.1.2. enum 390 The value of this keyword MUST be an array. This array SHOULD have 391 at least one element. Elements in the array SHOULD be unique. 393 An instance validates successfully against this keyword if its value 394 is equal to one of the elements in this keyword's array value. 396 Elements in the array might be of any value, including null. 398 6.1.3. const 400 The value of this keyword MAY be of any type, including null. 402 An instance validates successfully against this keyword if its value 403 is equal to the value of the keyword. 405 6.2. Validation Keywords for Numeric Instances (number and integer) 407 6.2.1. multipleOf 409 The value of "multipleOf" MUST be a number, strictly greater than 0. 411 A numeric instance is valid only if division by this keyword's value 412 results in an integer. 414 6.2.2. maximum 416 The value of "maximum" MUST be a number, representing an inclusive 417 upper limit for a numeric instance. 419 If the instance is a number, then this keyword validates only if the 420 instance is less than or exactly equal to "maximum". 422 6.2.3. exclusiveMaximum 424 The value of "exclusiveMaximum" MUST be number, representing an 425 exclusive upper limit for a numeric instance. 427 If the instance is a number, then the instance is valid only if it 428 has a value strictly less than (not equal to) "exclusiveMaximum". 430 6.2.4. minimum 432 The value of "minimum" MUST be a number, representing an inclusive 433 lower limit for a numeric instance. 435 If the instance is a number, then this keyword validates only if the 436 instance is greater than or exactly equal to "minimum". 438 6.2.5. exclusiveMinimum 440 The value of "exclusiveMinimum" MUST be number, representing an 441 exclusive lower limit for a numeric instance. 443 If the instance is a number, then the instance is valid only if it 444 has a value strictly greater than (not equal to) "exclusiveMinimum". 446 6.3. Validation Keywords for Strings 448 6.3.1. maxLength 450 The value of this keyword MUST be a non-negative integer. 452 A string instance is valid against this keyword if its length is less 453 than, or equal to, the value of this keyword. 455 The length of a string instance is defined as the number of its 456 characters as defined by RFC 7159 [RFC7159]. 458 6.3.2. minLength 460 The value of this keyword MUST be a non-negative integer. 462 A string instance is valid against this keyword if its length is 463 greater than, or equal to, the value of this keyword. 465 The length of a string instance is defined as the number of its 466 characters as defined by RFC 7159 [RFC7159]. 468 Omitting this keyword has the same behavior as a value of 0. 470 6.3.3. pattern 472 The value of this keyword MUST be a string. This string SHOULD be a 473 valid regular expression, according to the ECMA 262 regular 474 expression dialect. 476 A string instance is considered valid if the regular expression 477 matches the instance successfully. Recall: regular expressions are 478 not implicitly anchored. 480 6.4. Validation Keywords for Arrays 482 6.4.1. items 484 The value of "items" MUST be either a valid JSON Schema or an array 485 of valid JSON Schemas. 487 This keyword determines how child instances validate for arrays, and 488 does not directly validate the immediate instance itself. 490 If "items" is a schema, validation succeeds if all elements in the 491 array successfully validate against that schema. 493 If "items" is an array of schemas, validation succeeds if each 494 element of the instance validates against the schema at the same 495 position, if any. 497 Omitting this keyword has the same behavior as an empty schema. 499 6.4.2. additionalItems 501 The value of "additionalItems" MUST be a valid JSON Schema. 503 This keyword determines how child instances validate for arrays, and 504 does not directly validate the immediate instance itself. 506 If "items" is an array of schemas, validation succeeds if every 507 instance element at a position greater than the size of "items" 508 validates against "additionalItems". 510 Otherwise, "additionalItems" MUST be ignored, as the "items" schema 511 (possibly the default value of an empty schema) is applied to all 512 elements. 514 Omitting this keyword has the same behavior as an empty schema. 516 6.4.3. maxItems 518 The value of this keyword MUST be a non-negative integer. 520 An array instance is valid against "maxItems" if its size is less 521 than, or equal to, the value of this keyword. 523 6.4.4. minItems 525 The value of this keyword MUST be a non-negative integer. 527 An array instance is valid against "minItems" if its size is greater 528 than, or equal to, the value of this keyword. 530 Omitting this keyword has the same behavior as a value of 0. 532 6.4.5. uniqueItems 534 The value of this keyword MUST be a boolean. 536 If this keyword has boolean value false, the instance validates 537 successfully. If it has boolean value true, the instance validates 538 successfully if all of its elements are unique. 540 Omitting this keyword has the same behavior as a value of false. 542 6.4.6. contains 544 The value of this keyword MUST be a valid JSON Schema. 546 An array instance is valid against "contains" if at least one of its 547 elements is valid against the given schema. 549 6.5. Validation Keywords for Objects 551 6.5.1. maxProperties 553 The value of this keyword MUST be a non-negative integer. 555 An object instance is valid against "maxProperties" if its number of 556 properties is less than, or equal to, the value of this keyword. 558 6.5.2. minProperties 560 The value of this keyword MUST be a non-negative integer. 562 An object instance is valid against "minProperties" if its number of 563 properties is greater than, or equal to, the value of this keyword. 565 Omitting this keyword has the same behavior as a value of 0. 567 6.5.3. required 569 The value of this keyword MUST be an array. Elements of this array, 570 if any, MUST be strings, and MUST be unique. 572 An object instance is valid against this keyword if every item in the 573 array is the name of a property in the instance. 575 Omitting this keyword has the same behavior as an empty array. 577 6.5.4. properties 579 The value of "properties" MUST be an object. Each value of this 580 object MUST be a valid JSON Schema. 582 This keyword determines how child instances validate for objects, and 583 does not directly validate the immediate instance itself. 585 Validation succeeds if, for each name that appears in both the 586 instance and as a name within this keyword's value, the child 587 instance for that name successfully validates against the 588 corresponding schema. 590 Omitting this keyword has the same behavior as an empty object. 592 6.5.5. patternProperties 594 The value of "patternProperties" MUST be an object. Each property 595 name of this object SHOULD be a valid regular expression, according 596 to the ECMA 262 regular expression dialect. Each property value of 597 this object MUST be a valid JSON Schema. 599 This keyword determines how child instances validate for objects, and 600 does not directly validate the immediate instance itself. Validation 601 of the primitive instance type against this keyword always succeeds. 603 Validation succeeds if, for each instance name that matches any 604 regular expressions that appear as a property name in this keyword's 605 value, the child instance for that name successfully validates 606 against each schema that corresponds to a matching regular 607 expression. 609 Omitting this keyword has the same behavior as an empty object. 611 6.5.6. additionalProperties 613 The value of "additionalProperties" MUST be a valid JSON Schema. 615 This keyword determines how child instances validate for objects, and 616 does not directly validate the immediate instance itself. 618 Validation with "additionalProperties" applies only to the child 619 values of instance names that do not match any names in "properties", 620 and do not match any regular expression in "patternProperties". 622 For all such properties, validation succeeds if the child instance 623 validates against the "additionalProperties" schema. 625 Omitting this keyword has the same behavior as an empty schema. 627 6.5.7. dependencies 629 [[CREF1: This keyword may be split into two, with the variation that 630 uses an array of property names rather than a subschema getting a new 631 name. The dual behavior is confusing and relatively difficult to 632 implement. In the previous draft, we proposed dropping the keyword 633 altogether, or dropping one of its forms, but we received feedback in 634 support of keeping it. See issues #442 and #528 at 635 for 636 further discussion. Further feedback is encouraged. ]] 638 This keyword specifies rules that are evaluated if the instance is an 639 object and contains a certain property. 641 This keyword's value MUST be an object. Each property specifies a 642 dependency. Each dependency value MUST be an array or a valid JSON 643 Schema. 645 If the dependency value is a subschema, and the dependency key is a 646 property in the instance, the entire instance must validate against 647 the dependency value. 649 If the dependency value is an array, each element in the array, if 650 any, MUST be a string, and MUST be unique. If the dependency key is 651 a property in the instance, each of the items in the dependency value 652 must be a property that exists in the instance. 654 Omitting this keyword has the same behavior as an empty object. 656 6.5.8. propertyNames 658 The value of "propertyNames" MUST be a valid JSON Schema. 660 If the instance is an object, this keyword validates if every 661 property name in the instance validates against the provided schema. 662 Note the property name that the schema is testing will always be a 663 string. 665 Omitting this keyword has the same behavior as an empty schema. 667 6.6. Keywords for Applying Subschemas Conditionally 669 These keywords work together to implement conditional application of 670 a subschema based on the outcome of another subschema. 672 These keywords MUST NOT interact with each other across subschema 673 boundaries. In other words, an "if" in one branch of an "allOf" MUST 674 NOT have an impact on a "then" or "else" in another branch. 676 There is no default behavior for any of these keywords when they are 677 not present. In particular, they MUST NOT be treated as if present 678 with an empty schema, and when "if" is not present, both "then" and 679 "else" MUST be entirely ignored. 681 6.6.1. if 683 This keyword's value MUST be a valid JSON Schema. 685 This validation outcome of this keyword's subschema has no direct 686 effect on the overall validation result. Rather, it controls which 687 of the "then" or "else" keywords are evaluated. 689 Instances that successfully validate against this keyword's subschema 690 MUST also be valid against the subschema value of the "then" keyword, 691 if present. 693 Instances that fail to validate against this keyword's subschema MUST 694 also be valid against the subschema value of the "else" keyword, if 695 present. 697 If annotations (Section 3.3) are being collected, they are collected 698 from this keyword's subschema in the usual way, including when the 699 keyword is present without either "then" or "else". 701 6.6.2. then 703 This keyword's value MUST be a valid JSON Schema. 705 When "if" is present, and the instance successfully validates against 706 its subschema, then valiation succeeds against this keyword if the 707 instance also successfully validates against this keyword's 708 subschema. 710 This keyword has no effect when "if" is absent, or when the instance 711 fails to validate against its subschema. Implementations MUST NOT 712 evaluate the instance against this keyword, for either validation or 713 annotation collection purposes, in such cases. 715 6.6.3. else 717 This keyword's value MUST be a valid JSON Schema. 719 When "if" is present, and the instance fails to validate against its 720 subschema, then valiation succeeds against this keyword if the 721 instance successfully validates against this keyword's subschema. 723 This keyword has no effect when "if" is absent, or when the instance 724 successfully validates against its subschema. Implementations MUST 725 NOT evaluate the instance against this keyword, for either validation 726 or annotation collection purposes, in such cases. 728 6.7. Keywords for Applying Subschemas With Boolean Logic 730 6.7.1. allOf 732 This keyword's value MUST be a non-empty array. Each item of the 733 array MUST be a valid JSON Schema. 735 An instance validates successfully against this keyword if it 736 validates successfully against all schemas defined by this keyword's 737 value. 739 6.7.2. anyOf 741 This keyword's value MUST be a non-empty array. Each item of the 742 array MUST be a valid JSON Schema. 744 An instance validates successfully against this keyword if it 745 validates successfully against at least one schema defined by this 746 keyword's value. 748 6.7.3. oneOf 750 This keyword's value MUST be a non-empty array. Each item of the 751 array MUST be a valid JSON Schema. 753 An instance validates successfully against this keyword if it 754 validates successfully against exactly one schema defined by this 755 keyword's value. 757 6.7.4. not 759 This keyword's value MUST be a valid JSON Schema. 761 An instance is valid against this keyword if it fails to validate 762 successfully against the schema defined by this keyword. 764 7. Semantic Validation With "format" 766 7.1. Foreword 768 Structural validation alone may be insufficient to validate that an 769 instance meets all the requirements of an application. The "format" 770 keyword is defined to allow interoperable semantic validation for a 771 fixed subset of values which are accurately described by 772 authoritative resources, be they RFCs or other external 773 specifications. 775 The value of this keyword is called a format attribute. It MUST be a 776 string. A format attribute can generally only validate a given set 777 of instance types. If the type of the instance to validate is not in 778 this set, validation for this format attribute and instance SHOULD 779 succeed. 781 7.2. Implementation Requirements 783 The "format" keyword functions as both an annotation (Section 3.3) 784 and as an assertion (Section 3.2). While no special effort is 785 required to implement it as an annotation conveying semantic meaning, 786 implementing validation is non-trivial. 788 Implementations MAY support the "format" keyword as a validation 789 assertion. Should they choose to do so: 791 they SHOULD implement validation for attributes defined below; 793 they SHOULD offer an option to disable validation for this 794 keyword. 796 Implementations MAY add custom format attributes. Save for agreement 797 between parties, schema authors SHALL NOT expect a peer 798 implementation to support this keyword and/or custom format 799 attributes. 801 7.3. Defined Formats 803 7.3.1. Dates and Times 805 These attributes apply to string instances. 807 Date and time format names are derived from RFC 3339, section 5.6 808 [RFC3339]. 810 Implementations supporting formats SHOULD implement support for the 811 following attributes: 813 date-time: A string instance is valid against this attribute if it 814 is a valid representation according to the "date-time" production. 816 date: A string instance is valid against this attribute if it is a 817 valid representation according to the "full-date" production. 819 time: A string instance is valid against this attribute if it is a 820 valid representation according to the "full-time" production. 822 Implementations MAY support additional attributes using the other 823 production names defined in that section. If "full-date" or "full- 824 time" are implemented, the corresponding short form ("date" or "time" 825 respectively) MUST be implemented, and MUST behave identically. 826 Implementations SHOULD NOT define extension attributes with any name 827 matching an RFC 3339 production unless it validates according to the 828 rules of that production. [[CREF2: There is not currently consensus 829 on the need for supporting all RFC 3339 formats, so this approach of 830 reserving the namespace will encourage experimentation without 831 committing to the entire set. Either the format implementation 832 requirements will become more flexible in general, or these will 833 likely either be promoted to fully specified attributes or dropped. 834 ]] 836 7.3.2. Email Addresses 838 These attributes apply to string instances. 840 A string instance is valid against these attributes if it is a valid 841 Internet email address as follows: 843 email: As defined by RFC 5322, section 3.4.1 [RFC5322]. 845 idn-email: As defined by RFC 6531 [RFC6531] 847 Note that all strings valid against the "email" attribute are also 848 valid against the "idn-email" attribute. 850 7.3.3. Hostnames 852 These attributes apply to string instances. 854 A string instance is valid against these attributes if it is a valid 855 representation for an Internet hostname as follows: 857 hostname: As defined by RFC 1034, section 3.1 [RFC1034], including 858 host names produced using the Punycode algorithm specified in RFC 859 5891, section 4.4 [RFC5891]. 861 idn-hostname: As defined by either RFC 1034 as for hostname, or an 862 internationalized hostname as defined by RFC 5890, section 2.3.2.3 863 [RFC5890]. 865 Note that all strings valid against the "hostname" attribute are also 866 valid against the "idn-hostname" attribute. 868 7.3.4. IP Addresses 870 These attributes apply to string instances. 872 A string instance is valid against these attributes if it is a valid 873 representation of an IP address as follows: 875 ipv4: An IPv4 address according to the "dotted-quad" ABNF syntax as 876 defined in RFC 2673, section 3.2 [RFC2673]. 878 ipv6: An IPv6 address as defined in RFC 4291, section 2.2 [RFC4291]. 880 7.3.5. Resource Identifiers 882 These attributes apply to string instances. 884 uri: A string instance is valid against this attribute if it is a 885 valid URI, according to [RFC3986]. 887 uri-reference: A string instance is valid against this attribute if 888 it is a valid URI Reference (either a URI or a relative- 889 reference), according to [RFC3986]. 891 iri: A string instance is valid against this attribute if it is a 892 valid IRI, according to [RFC3987]. 894 iri-reference: A string instance is valid against this attribute if 895 it is a valid IRI Reference (either an IRI or a relative- 896 reference), according to [RFC3987]. 898 Note that all valid URIs are valid IRIs, and all valid URI References 899 are also valid IRI References. 901 7.3.6. uri-template 903 This attribute applies to string instances. 905 A string instance is valid against this attribute if it is a valid 906 URI Template (of any level), according to [RFC6570]. 908 Note that URI Templates may be used for IRIs; there is no separate 909 IRI Template specification. 911 7.3.7. JSON Pointers 913 These attributes apply to string instances. 915 json-pointer: A string instance is valid against this attribute if 916 it is a valid JSON string representation of a JSON Pointer, 917 according to RFC 6901, section 5 [RFC6901]. 919 relative-json-pointer: A string instance is valid against this 920 attribute if it is a valid Relative JSON Pointer 921 [relative-json-pointer]. 923 To allow for both absolute and relative JSON Pointers, use "anyOf" or 924 "oneOf" to indicate support for either format. 926 7.3.8. regex 928 This attribute applies to string instances. 930 A regular expression, which SHOULD be valid according to the ECMA 262 931 [ecma262] regular expression dialect. 933 Implementations that validate formats MUST accept at least the subset 934 of ECMA 262 defined in the Regular Expressions (Section 4.3) section 935 of this specification, and SHOULD accept all valid ECMA 262 936 expressions. 938 8. String-Encoding Non-JSON Data 940 8.1. Foreword 942 Properties defined in this section indicate that an instance contains 943 non-JSON data encoded in a JSON string. They describe the type of 944 content and how it is encoded. 946 These properties provide additional information required to interpret 947 JSON data as rich multimedia documents. 949 8.2. Implementation Requirements 951 The content keywords function as both annotations (Section 3.3) and 952 as assertions (Section 3.2). While no special effort is required to 953 implement them as annotations conveying how applications can 954 interpret the data in the string, implementing validation of 955 conformance to the media type and encoding is non-trivial. 957 Implementations MAY support the "contentMediaType" and 958 "contentEncoding" keywords as validation assertions. Should they 959 choose to do so, they SHOULD offer an option to disable validation 960 for these keywords. 962 8.3. contentEncoding 964 If the instance value is a string, this property defines that the 965 string SHOULD be interpreted as binary data and decoded using the 966 encoding named by this property. RFC 2045, Sec 6.1 [RFC2045] lists 967 the possible values for this property. 969 The value of this property MUST be a string. 971 The value of this property SHOULD be ignored if the instance 972 described is not a string. 974 8.4. contentMediaType 976 The value of this property must be a media type, as defined by RFC 977 2046 [RFC2046]. This property defines the media type of instances 978 which this schema defines. 980 The value of this property MUST be a string. 982 The value of this property SHOULD be ignored if the instance 983 described is not a string. 985 If the "contentEncoding" property is not present, but the instance 986 value is a string, then the value of this property SHOULD specify a 987 text document type, and the character set SHOULD be the character set 988 into which the JSON string value was decoded (for which the default 989 is Unicode). 991 8.5. Example 993 Here is an example schema, illustrating the use of "contentEncoding" 994 and "contentMediaType": 996 { 997 "type": "string", 998 "contentEncoding": "base64", 999 "contentMediaType": "image/png" 1000 } 1002 Instances described by this schema should be strings, and their 1003 values should be interpretable as base64-encoded PNG images. 1005 Another example: 1007 { 1008 "type": "string", 1009 "contentMediaType": "text/html" 1010 } 1012 Instances described by this schema should be strings containing HTML, 1013 using whatever character set the JSON string was decoded into 1014 (default is Unicode). 1016 9. Schema Re-Use With "definitions" 1018 The "definitions" keywords provides a standardized location for 1019 schema authors to inline re-usable JSON Schemas into a more general 1020 schema. The keyword does not directly affect the validation result. 1022 This keyword's value MUST be an object. Each member value of this 1023 object MUST be a valid JSON Schema. 1025 As an example, here is a schema describing an array of positive 1026 integers, where the positive integer constraint is a subschema in 1027 "definitions": 1029 { 1030 "type": "array", 1031 "items": { "$ref": "#/definitions/positiveInteger" }, 1032 "definitions": { 1033 "positiveInteger": { 1034 "type": "integer", 1035 "exclusiveMinimum": 0 1036 } 1037 } 1038 } 1040 10. Schema Annotations 1042 Schema validation is a useful mechanism for annotating instance data 1043 with additional information. The rules for determining when and how 1044 annotations are associated with an instance are outlined in section 1045 3.3. 1047 These general-purpose annotation keywords provide commonly used 1048 information for documentation and user interface display purposes. 1049 They are not intended to form a comprehensive set of features. 1050 Rather, additional vocabularies can be defined for more complex 1051 annotation-based applications. 1053 10.1. "title" and "description" 1055 The value of both of these keywords MUST be a string. 1057 Both of these keywords can be used to decorate a user interface with 1058 information about the data produced by this user interface. A title 1059 will preferably be short, whereas a description will provide 1060 explanation about the purpose of the instance described by this 1061 schema. 1063 10.2. "default" 1065 There are no restrictions placed on the value of this keyword. When 1066 multiple occurrences of this keyword are applicable to a single sub- 1067 instance, implementations SHOULD remove duplicates. 1069 This keyword can be used to supply a default JSON value associated 1070 with a particular schema. It is RECOMMENDED that a default value be 1071 valid against the associated schema. 1073 10.3. "readOnly" and "writeOnly" 1075 The value of these keywords MUST be a boolean. When multiple 1076 occurrences of these keywords are applicable to a single sub- 1077 instance, the resulting value MUST be true if any occurrence 1078 specifies a true value, and MUST be false otherwise. 1080 If "readOnly" has a value of boolean true, it indicates that the 1081 value of the instance is managed exclusively by the owning authority, 1082 and attempts by an application to modify the value of this property 1083 are expected to be ignored or rejected by that owning authority. 1085 An instance document that is marked as "readOnly for the entire 1086 document MAY be ignored if sent to the owning authority, or MAY 1087 result in an error, at the authority's discretion. 1089 If "writeOnly" has a value of boolean true, it indicates that the 1090 value is never present when the instance is retrieved from the owning 1091 authority. It can be present when sent to the owning authority to 1092 update or create the document (or the resource it represents), but it 1093 will not be included in any updated or newly created version of the 1094 instance. 1096 An instance document that is marked as "writeOnly" for the entire 1097 document MAY be returned as a blank document of some sort, or MAY 1098 produce an error upon retrieval, or have the retrieval request 1099 ignored, at the authority's discretion. 1101 For example, "readOnly" would be used to mark a database-generated 1102 serial number as read-only, while "writeOnly" would be used to mark a 1103 password input field. 1105 These keywords can be used to assist in user interface instance 1106 generation. In particular, an application MAY choose to use a widget 1107 that hides input values as they are typed for write-only fields. 1109 Omitting these keywords has the same behavior as values of false. 1111 10.4. "examples" 1113 The value of this keyword MUST be an array. There are no 1114 restrictions placed on the values within the array. When multiple 1115 occurrences of this keyword are applicable to a single sub-instance, 1116 implementations MUST provide a flat array of all values rather than 1117 an array of arrays. 1119 This keyword can be used to provide sample JSON values associated 1120 with a particular schema, for the purpose of illustrating usage. It 1121 is RECOMMENDED that these values be valid against the associated 1122 schema. 1124 Implementations MAY use the value(s) of "default", if present, as an 1125 additional example. If "examples" is absent, "default" MAY still be 1126 used in this manner. 1128 11. Security Considerations 1130 JSON Schema validation defines a vocabulary for JSON Schema core and 1131 concerns all the security considerations listed there. 1133 JSON Schema validation allows the use of Regular Expressions, which 1134 have numerous different (often incompatible) implementations. Some 1135 implementations allow the embedding of arbitrary code, which is 1136 outside the scope of JSON Schema and MUST NOT be permitted. Regular 1137 expressions can often also be crafted to be extremely expensive to 1138 compute (with so-called "catastrophic backtracking"), resulting in a 1139 denial-of-service attack. 1141 Implementations that support validating or otherwise evaluating 1142 instance string data based on "contentEncoding" and/or 1143 "contentMediaType" are at risk of evaluating data in an unsafe way 1144 based on misleading information. Applications can mitigate this risk 1145 by only performing such processing when a relationship between the 1146 schema and instance is established (e.g., they share the same 1147 authority). 1149 Processing a media type or encoding is subject to the security 1150 considerations of that media type or encoding. For example, the 1151 security considerations of RFC 4329 Scripting Media Types [RFC4329] 1152 apply when processing JavaScript or ECMAScript encoded within a JSON 1153 string. 1155 12. References 1157 12.1. Normative References 1159 [ecma262] "ECMA 262 specification", . 1163 [json-schema] 1164 Wright, A. and H. Andrews, "JSON Schema: A Media Type for 1165 Describing JSON Documents", draft-handrews-json-schema-01 1166 (work in progress), November 2017. 1168 [relative-json-pointer] 1169 Luff, G. and H. Andrews, "Relative JSON Pointers", draft- 1170 handrews-relative-json-pointer-01 (work in progress), 1171 November 2017. 1173 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1174 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1175 . 1177 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1178 Extensions (MIME) Part One: Format of Internet Message 1179 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1180 . 1182 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1183 Extensions (MIME) Part Two: Media Types", RFC 2046, 1184 DOI 10.17487/RFC2046, November 1996, 1185 . 1187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1188 Requirement Levels", BCP 14, RFC 2119, 1189 DOI 10.17487/RFC2119, March 1997, 1190 . 1192 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", 1193 RFC 2673, DOI 10.17487/RFC2673, August 1999, 1194 . 1196 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1197 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1198 . 1200 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1201 Resource Identifier (URI): Generic Syntax", STD 66, 1202 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1203 . 1205 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1206 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 1207 January 2005, . 1209 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1210 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1211 2006, . 1213 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1214 DOI 10.17487/RFC5322, October 2008, 1215 . 1217 [RFC5890] Klensin, J., "Internationalized Domain Names for 1218 Applications (IDNA): Definitions and Document Framework", 1219 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1220 . 1222 [RFC5891] Klensin, J., "Internationalized Domain Names in 1223 Applications (IDNA): Protocol", RFC 5891, 1224 DOI 10.17487/RFC5891, August 2010, 1225 . 1227 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 1228 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 1229 . 1231 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 1232 and D. Orchard, "URI Template", RFC 6570, 1233 DOI 10.17487/RFC6570, March 2012, 1234 . 1236 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 1237 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 1238 DOI 10.17487/RFC6901, April 2013, 1239 . 1241 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1242 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1243 2014, . 1245 12.2. Informative References 1247 [RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, 1248 DOI 10.17487/RFC4329, April 2006, 1249 . 1251 Appendix A. Acknowledgments 1253 Thanks to Gary Court, Francis Galiegue, Kris Zyp, and Geraint Luff 1254 for their work on the initial drafts of JSON Schema. 1256 Thanks to Jason Desrosiers, Daniel Perrett, Erik Wilde, Ben Hutton, 1257 Evgeny Poberezkin, Brad Bowman, Gowry Sankar, Donald Pipowitch, Dave 1258 Finlay, and Denis Laxalde for their submissions and patches to the 1259 document. 1261 Appendix B. ChangeLog 1263 [[CREF3: This section to be removed before leaving Internet-Draft 1264 status.]] 1266 draft-handrews-json-schema-validation-01 1268 * This draft is purely a clarification with no functional changes 1270 * Provided the general principle behind ignoring annotations 1271 under "not" and similar cases 1273 * Clarified "if"/"then"/"else" validation interactions 1275 * Clarified "if"/"then"/"else" behavior for annotation 1277 * Minor formatting and cross-referencing improvements 1279 draft-handrews-json-schema-validation-00 1281 * Added "if"/"then"/"else" 1283 * Classify keywords as assertions or annotations per the core 1284 spec 1286 * Warn of possibly removing "dependencies" in the future 1288 * Grouped validation keywords into sub-sections for readability 1290 * Moved "readOnly" from hyper-schema to validation meta-data 1292 * Added "writeOnly" 1294 * Added string-encoded media section, with former hyper-schema 1295 "media" keywords 1297 * Restored "regex" format (removal was unintentional) 1298 * Added "date" and "time" formats, and reserved additional RFC 1299 3339 format names 1301 * I18N formats: "iri", "iri-reference", "idn-hostname", "idn- 1302 email" 1304 * Clarify that "json-pointer" format means string encoding, not 1305 URI fragment 1307 * Fixed typo that inverted the meaning of "minimum" and 1308 "exclusiveMinimum" 1310 * Move format syntax references into Normative References 1312 * JSON is a normative requirement 1314 draft-wright-json-schema-validation-01 1316 * Standardized on hyphenated format names with full words 1317 ("uriref" becomes "uri-reference") 1319 * Add the formats "uri-template" and "json-pointer" 1321 * Changed "exclusiveMaximum"/"exclusiveMinimum" from boolean 1322 modifiers of "maximum"/"minimum" to independent numeric fields. 1324 * Split the additionalItems/items into two sections 1326 * Reworked properties/patternProperties/additionalProperties 1327 definition 1329 * Added "examples" keyword 1331 * Added "contains" keyword 1333 * Allow empty "required" and "dependencies" arrays 1335 * Fixed "type" reference to primitive types 1337 * Added "const" keyword 1339 * Added "propertyNames" keyword 1341 draft-wright-json-schema-validation-00 1343 * Added additional security considerations 1344 * Removed reference to "latest version" meta-schema, use numbered 1345 version instead 1347 * Rephrased many keyword definitions for brevity 1349 * Added "uriref" format that also allows relative URI references 1351 draft-fge-json-schema-validation-00 1353 * Initial draft. 1355 * Salvaged from draft v3. 1357 * Redefine the "required" keyword. 1359 * Remove "extends", "disallow" 1361 * Add "anyOf", "allOf", "oneOf", "not", "definitions", 1362 "minProperties", "maxProperties". 1364 * "dependencies" member values can no longer be single strings; 1365 at least one element is required in a property dependency 1366 array. 1368 * Rename "divisibleBy" to "multipleOf". 1370 * "type" arrays can no longer have schemas; remove "any" as a 1371 possible value. 1373 * Rework the "format" section; make support optional. 1375 * "format": remove attributes "phone", "style", "color"; rename 1376 "ip-address" to "ipv4"; add references for all attributes. 1378 * Provide algorithms to calculate schema(s) for array/object 1379 instances. 1381 * Add interoperability considerations. 1383 Authors' Addresses 1385 Austin Wright (editor) 1387 EMail: aaa@bzfx.net 1388 Henry Andrews (editor) 1389 Cloudflare, Inc. 1390 San Francisco, CA 1391 USA 1393 EMail: henry@cloudflare.com 1395 Geraint Luff 1396 Cambridge 1397 UK 1399 EMail: luffgd@gmail.com