idnits 2.17.1 draft-wright-json-schema-validation-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 13, 2016) is 2744 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 2673 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 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 G. Luff 5 Expires: April 16, 2017 October 13, 2016 7 JSON Schema Validation: A Vocabulary for Structural Validation of JSON 8 draft-wright-json-schema-validation-00 10 Abstract 12 JSON Schema (application/schema+json) has several purposes, one of 13 which is JSON instance validation. This document specifies a 14 vocabulary for JSON Schema to describe the meaning of JSON documents, 15 provide hints for user interfaces working with JSON data, and to make 16 assertions about what a valid document must look like. 18 Note to Readers 20 The issues list for this draft can be found at . 23 For additional information, see . 25 To provide feedback, use this issue tracker, the communication 26 methods listed on the homepage, or email the document editors. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 16, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 64 3. Interoperability considerations . . . . . . . . . . . . . . . 4 65 3.1. Validation of string instances . . . . . . . . . . . . . 4 66 3.2. Validation of numeric instances . . . . . . . . . . . . . 4 67 3.3. Regular expressions . . . . . . . . . . . . . . . . . . . 4 68 4. General validation considerations . . . . . . . . . . . . . . 5 69 4.1. Keywords and instance primitive types . . . . . . . . . . 5 70 4.2. Missing keywords . . . . . . . . . . . . . . . . . . . . 5 71 4.3. Linearity . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Validation keywords . . . . . . . . . . . . . . . . . . . . . 5 73 5.1. multipleOf . . . . . . . . . . . . . . . . . . . . . . . 6 74 5.2. maximum . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5.3. exclusiveMaximum . . . . . . . . . . . . . . . . . . . . 6 76 5.4. minimum . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 5.5. exclusiveMinimum . . . . . . . . . . . . . . . . . . . . 6 78 5.6. maxLength . . . . . . . . . . . . . . . . . . . . . . . . 7 79 5.7. minLength . . . . . . . . . . . . . . . . . . . . . . . . 7 80 5.8. pattern . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 5.9. additionalItems and items . . . . . . . . . . . . . . . . 7 82 5.10. maxItems . . . . . . . . . . . . . . . . . . . . . . . . 8 83 5.11. minItems . . . . . . . . . . . . . . . . . . . . . . . . 8 84 5.12. uniqueItems . . . . . . . . . . . . . . . . . . . . . . . 8 85 5.13. maxProperties . . . . . . . . . . . . . . . . . . . . . . 9 86 5.14. minProperties . . . . . . . . . . . . . . . . . . . . . . 9 87 5.15. required . . . . . . . . . . . . . . . . . . . . . . . . 9 88 5.16. properties . . . . . . . . . . . . . . . . . . . . . . . 9 89 5.17. patternProperties . . . . . . . . . . . . . . . . . . . . 9 90 5.18. additionalProperties . . . . . . . . . . . . . . . . . . 10 91 5.19. dependencies . . . . . . . . . . . . . . . . . . . . . . 10 92 5.20. enum . . . . . . . . . . . . . . . . . . . . . . . . . . 10 93 5.21. type . . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 5.22. allOf . . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 5.23. anyOf . . . . . . . . . . . . . . . . . . . . . . . . . . 11 96 5.24. oneOf . . . . . . . . . . . . . . . . . . . . . . . . . . 11 97 5.25. not . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 98 5.26. definitions . . . . . . . . . . . . . . . . . . . . . . . 12 99 6. Metadata keywords . . . . . . . . . . . . . . . . . . . . . . 12 100 6.1. "title" and "description" . . . . . . . . . . . . . . . . 12 101 6.2. "default" . . . . . . . . . . . . . . . . . . . . . . . . 13 102 7. Semantic validation with "format" . . . . . . . . . . . . . . 13 103 7.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . 13 104 7.2. Implementation requirements . . . . . . . . . . . . . . . 13 105 7.3. Defined formats . . . . . . . . . . . . . . . . . . . . . 14 106 7.3.1. date-time . . . . . . . . . . . . . . . . . . . . . . 14 107 7.3.2. email . . . . . . . . . . . . . . . . . . . . . . . . 14 108 7.3.3. hostname . . . . . . . . . . . . . . . . . . . . . . 14 109 7.3.4. ipv4 . . . . . . . . . . . . . . . . . . . . . . . . 14 110 7.3.5. ipv6 . . . . . . . . . . . . . . . . . . . . . . . . 14 111 7.3.6. uri . . . . . . . . . . . . . . . . . . . . . . . . . 15 112 7.3.7. uriref . . . . . . . . . . . . . . . . . . . . . . . 15 113 8. Security considerations . . . . . . . . . . . . . . . . . . . 15 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 115 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 116 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 117 10.2. Informative References . . . . . . . . . . . . . . . . . 16 118 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 119 Appendix B. ChangeLog . . . . . . . . . . . . . . . . . . . . . 17 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 122 1. Introduction 124 JSON Schema can be used to require that a given JSON document (an 125 instance) satisfies a certain number of criteria. These criteria are 126 asserted by using keywords described in this specification. In 127 addition, a set of keywords is also defined to assist in interactive, 128 user interface instance generation. 130 This specification will use the terminology defined by the JSON 131 Schema core [json-schema] specification. 133 2. Conventions and Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 This specification uses the term "container instance" to refer to 140 both array and object instances. It uses the term "children 141 instances" to refer to array elements or object member values. 143 This specification uses the term "property set" to refer to the set 144 of an object's member names; for instance, the property set of JSON 145 Object { "a": 1, "b": 2 } is [ "a", "b" ]. 147 Elements in an array value are said to be unique if no two elements 148 of this array are equal [json-schema]. 150 3. Interoperability considerations 152 3.1. Validation of string instances 154 It should be noted that the nul character (\u0000) is valid in a JSON 155 string. An instance to validate may contain a string value with this 156 character, regardless of the ability of the underlying programming 157 language to deal with such data. 159 3.2. Validation of numeric instances 161 The JSON specification allows numbers with arbitrary precision, and 162 JSON Schema does not add any such bounds. This means that numeric 163 instances processed by JSON Schema can be arbitrarily large and/or 164 have an arbitrarily long decimal part, regardless of the ability of 165 the underlying programming language to deal with such data. 167 3.3. Regular expressions 169 Two validation keywords, "pattern" and "patternProperties", use 170 regular expressions to express constraints. These regular 171 expressions SHOULD be valid according to the ECMA 262 [ecma262] 172 regular expression dialect. 174 Furthermore, given the high disparity in regular expression 175 constructs support, schema authors SHOULD limit themselves to the 176 following regular expression tokens: 178 individual Unicode characters, as defined by the JSON 179 specification [RFC7159]; 181 simple character classes ([abc]), range character classes ([a-z]); 183 complemented character classes ([^abc], [^a-z]); 185 simple quantifiers: "+" (one or more), "*" (zero or more), "?" 186 (zero or one), and their lazy versions ("+?", "*?", "??"); 187 range quantifiers: "{x}" (exactly x occurrences), "{x,y}" (at 188 least x, at most y, occurrences), {x,} (x occurrences or more), 189 and their lazy versions; 191 the beginning-of-input ("^") and end-of-input ("$") anchors; 193 simple grouping ("(...)") and alternation ("|"). 195 Finally, implementations MUST NOT take regular expressions to be 196 anchored, neither at the beginning nor at the end. This means, for 197 instance, the pattern "es" matches "expression". 199 4. General validation considerations 201 4.1. Keywords and instance primitive types 203 Most validation keywords only limit the range of values within a 204 certain primitive type. When the primitive type of the instance is 205 not of the type targeted by the keyword, the validation succeeds. 207 For example, the "maxLength" keyword will only restrict certain 208 strings (that are too long) from being valid. If the instance is a 209 number, boolean, null, array, or object, the keyword passes 210 validation. 212 4.2. Missing keywords 214 Validation keywords that are missing never restrict validation. In 215 some cases, this no-op behavior is identical to a keyword that exists 216 with certain values, and these values are noted where known. 218 4.3. Linearity 220 Validation keywords typically operate independent of each other, 221 without affecting each other. 223 For author convienence, there are some exceptions: 225 "additionalProperties", whose behavior is defined in terms of 226 "properties" and "patternProperties"; and 228 "additionalItems", whose behavior is defined in terms of "items" 230 5. Validation keywords 232 Validation keywords in a schema impose requirements for successfully 233 validating an instance. 235 5.1. multipleOf 237 The value of "multipleOf" MUST be a number, strictly greater than 0. 239 A numeric instance is only valid if division by this keyword's value 240 results in an integer. 242 5.2. maximum 244 The value of "maximum" MUST be a number, representing an upper limit 245 for a numeric instance. 247 If the instance is a number, then this keyword validates if 248 "exclusiveMaximum" is true and instance is less than the provided 249 value, or else if the instance is less than or exactly equal to the 250 provided value. 252 5.3. exclusiveMaximum 254 The value of "exclusiveMaximum" MUST be a boolean, representing 255 whether the limit in "maximum" is exclusive or not. An undefined 256 value is the same as false. 258 If "exclusiveMaximum" is true, then a numeric instance SHOULD NOT be 259 equal to the value specified in "maximum". If "exclusiveMaximum" is 260 false (or not specified), then a numeric instance MAY be equal to the 261 value of "maximum". 263 5.4. minimum 265 The value of "minimum" MUST be a number, representing a lower limit 266 for a numeric instance. 268 If the instance is a number, then this keyword validates if 269 "exclusiveMinimum" is true and instance is greater than the provided 270 value, or else if the instance is greater than or exactly equal to 271 the provided value. 273 5.5. exclusiveMinimum 275 The value of "exclusiveMinimum" MUST be a boolean, representing 276 whether the limit in "minimum" is exclusive or not. An undefined 277 value is the same as false. 279 If "exclusiveMinimum" is true, then a numeric instance SHOULD NOT be 280 equal to the value specified in "minimum". If "exclusiveMinimum" is 281 false (or not specified), then a numeric instance MAY be equal to the 282 value of "minimum". 284 5.6. maxLength 286 The value of this keyword MUST be a non-negative integer. 288 The value of this keyword MUST be an integer. This integer MUST be 289 greater than, or equal to, 0. 291 A string instance is valid against this keyword if its length is less 292 than, or equal to, the value of this keyword. 294 The length of a string instance is defined as the number of its 295 characters as defined by RFC 7159 [RFC7159]. 297 5.7. minLength 299 A string instance is valid against this keyword if its length is 300 greater than, or equal to, the value of this keyword. 302 The length of a string instance is defined as the number of its 303 characters as defined by RFC 7159 [RFC7159]. 305 The value of this keyword MUST be an integer. This integer MUST be 306 greater than, or equal to, 0. 308 "minLength", if absent, may be considered as being present with 309 integer value 0. 311 5.8. pattern 313 The value of this keyword MUST be a string. This string SHOULD be a 314 valid regular expression, according to the ECMA 262 regular 315 expression dialect. 317 A string instance is considered valid if the regular expression 318 matches the instance successfully. Recall: regular expressions are 319 not implicitly anchored. 321 5.9. additionalItems and items 323 The value of "additionalItems" MUST be either a boolean or an object. 324 If it is an object, this object MUST be a valid JSON Schema. 326 The value of "items" MUST be either a schema or array of schemas. 328 Successful validation of an array instance with regards to these two 329 keywords is determined as follows: 331 if "items" is not present, or its value is an object, validation 332 of the instance always succeeds, regardless of the value of 333 "additionalItems"; 335 if the value of "additionalItems" is boolean value true or an 336 object, validation of the instance always succeeds; 338 if the value of "additionalItems" is boolean value false and the 339 value of "items" is an array, the instance is valid if its size is 340 less than, or equal to, the size of "items". 342 If either keyword is absent, it may be considered present with an 343 empty schema. 345 5.10. maxItems 347 The value of this keyword MUST be an integer. This integer MUST be 348 greater than, or equal to, 0. 350 An array instance is valid against "maxItems" if its size is less 351 than, or equal to, the value of this keyword. 353 5.11. minItems 355 The value of this keyword MUST be an integer. This integer MUST be 356 greater than, or equal to, 0. 358 An array instance is valid against "minItems" if its size is greater 359 than, or equal to, the value of this keyword. 361 If this keyword is not present, it may be considered present with a 362 value of 0. 364 5.12. uniqueItems 366 The value of this keyword MUST be a boolean. 368 If this keyword has boolean value false, the instance validates 369 successfully. If it has boolean value true, the instance validates 370 successfully if all of its elements are unique. 372 If not present, this keyword may be considered present with boolean 373 value false. 375 5.13. maxProperties 377 The value of this keyword MUST be an integer. This integer MUST be 378 greater than, or equal to, 0. 380 An object instance is valid against "maxProperties" if its number of 381 properties is less than, or equal to, the value of this keyword. 383 5.14. minProperties 385 The value of this keyword MUST be an integer. This integer MUST be 386 greater than, or equal to, 0. 388 An object instance is valid against "minProperties" if its number of 389 properties is greater than, or equal to, the value of this keyword. 391 If this keyword is not present, it may be considered present with a 392 value of 0. 394 5.15. required 396 The value of this keyword MUST be an array. This array MUST have at 397 least one element. Elements of this array MUST be strings, and MUST 398 be unique. 400 An object instance is valid against this keyword if its property set 401 contains all elements in this keyword's array value. 403 5.16. properties 405 The value of "properties" MUST be an object. Each value of this 406 object MUST be an object, and each object MUST be a valid JSON 407 Schema. 409 If absent, it can be considered the same as an empty object. 411 5.17. patternProperties 413 The value of "patternProperties" MUST be an object. Each property 414 name of this object SHOULD be a valid regular expression, according 415 to the ECMA 262 regular expression dialect. Each property value of 416 this object MUST be an object, and each object MUST be a valid JSON 417 Schema. 419 If absent, it can be considered the same as an empty object. 421 5.18. additionalProperties 423 The value of "additionalProperties" MUST be a boolean or a schema. 425 If "additionalProperties" is absent, it may be considered present 426 with an empty schema as a value. 428 If "additionalProperties" is true, validation always succeeds. 430 If "additionalProperties" is false, validation succeeds only if the 431 instance is an object and all properties on the instance were covered 432 by "properties" and/or "patternProperties". 434 If "additionalProperties" is an object, validate the value as a 435 schema to all of the properties that weren't validated by 436 "properties" nor "patternProperties". 438 5.19. dependencies 440 This keyword specifies rules that are evaluated if the instance is an 441 object and contains a certain property. 443 This keyword's value MUST be an object. Each property specifies a 444 dependency. Each dependency value MUST be an object or an array. 446 If the dependency value is an object, it MUST be a valid JSON Schema. 447 If the dependency key is a property in the instance, the dependency 448 value must validate against the entire instance. 450 If the dependency value is an array, it MUST have at least one 451 element, each element MUST be a string, and elements in the array 452 MUST be unique. If the dependency key is a property in the instance, 453 each of the items in the dependency value must be a property that 454 exists in the instance. 456 5.20. enum 458 The value of this keyword MUST be an array. This array SHOULD have 459 at least one element. Elements in the array SHOULD be unique. 461 Elements in the array MAY be of any type, including null. 463 An instance validates successfully against this keyword if its value 464 is equal to one of the elements in this keyword's array value. 466 5.21. type 468 The value of this keyword MUST be either a string or an array. If it 469 is an array, elements of the array MUST be strings and MUST be 470 unique. 472 String values MUST be one of the seven primitive types defined by the 473 core specification. 475 An instance matches successfully if its primitive type is one of the 476 types defined by keyword. Recall: "number" includes "integer". 478 5.22. allOf 480 This keyword's value MUST be an array. This array MUST have at least 481 one element. 483 Elements of the array MUST be objects. Each object MUST be a valid 484 JSON Schema. 486 An instance validates successfully against this keyword if it 487 validates successfully against all schemas defined by this keyword's 488 value. 490 5.23. anyOf 492 This keyword's value MUST be an array. This array MUST have at least 493 one element. 495 Elements of the array MUST be objects. Each object MUST be a valid 496 JSON Schema. 498 An instance validates successfully against this keyword if it 499 validates successfully against at least one schema defined by this 500 keyword's value. 502 5.24. oneOf 504 This keyword's value MUST be an array. This array MUST have at least 505 one element. 507 Elements of the array MUST be objects. Each object MUST be a valid 508 JSON Schema. 510 An instance validates successfully against this keyword if it 511 validates successfully against exactly one schema defined by this 512 keyword's value. 514 5.25. not 516 This keyword's value MUST be an object. This object MUST be a valid 517 JSON Schema. 519 An instance is valid against this keyword if it fails to validate 520 successfully against the schema defined by this keyword. 522 5.26. definitions 524 This keyword's value MUST be an object. Each member value of this 525 object MUST be a valid JSON Schema. 527 This keyword plays no role in validation per se. Its role is to 528 provide a standardized location for schema authors to inline JSON 529 Schemas into a more general schema. 531 As an example, here is a schema describing an array of positive 532 integers, where the positive integer constraint is a subschema in 533 "definitions": 535 { 536 "type": "array", 537 "items": { "$ref": "#/definitions/positiveInteger" }, 538 "definitions": { 539 "positiveInteger": { 540 "type": "integer", 541 "minimum": 0, 542 "exclusiveMinimum": true 543 } 544 } 545 } 547 6. Metadata keywords 549 6.1. "title" and "description" 551 The value of both of these keywords MUST be a string. 553 Both of these keywords can be used to decorate a user interface with 554 information about the data produced by this user interface. A title 555 will preferrably be short, whereas a description will provide 556 explanation about the purpose of the instance described by this 557 schema. 559 Both of these keywords MAY be used in root schemas, and in any 560 subschemas. 562 6.2. "default" 564 There are no restrictions placed on the value of this keyword. 566 This keyword can be used to supply a default JSON value associated 567 with a particular schema. It is RECOMMENDED that a default value be 568 valid against the associated schema. 570 This keyword MAY be used in root schemas, and in any subschemas. 572 7. Semantic validation with "format" 574 7.1. Foreword 576 Structural validation alone may be insufficient to validate that an 577 instance meets all the requirements of an application. The "format" 578 keyword is defined to allow interoperable semantic validation for a 579 fixed subset of values which are accurately described by 580 authoritative resources, be they RFCs or other external 581 specifications. 583 The value of this keyword is called a format attribute. It MUST be a 584 string. A format attribute can generally only validate a given set 585 of instance types. If the type of the instance to validate is not in 586 this set, validation for this format attribute and instance SHOULD 587 succeed. 589 7.2. Implementation requirements 591 Implementations MAY support the "format" keyword. Should they choose 592 to do so: 594 they SHOULD implement validation for attributes defined below; 596 they SHOULD offer an option to disable validation for this 597 keyword. 599 Implementations MAY add custom format attributes. Save for agreement 600 between parties, schema authors SHALL NOT expect a peer 601 implementation to support this keyword and/or custom format 602 attributes. 604 7.3. Defined formats 606 7.3.1. date-time 608 This attribute applies to string instances. 610 A string instance is valid against this attribute if it is a valid 611 date representation as defined by RFC 3339, section 5.6 [RFC3339]. 613 7.3.2. email 615 This attribute applies to string instances. 617 A string instance is valid against this attribute if it is a valid 618 Internet email address as defined by RFC 5322, section 3.4.1 619 [RFC5322]. 621 7.3.3. hostname 623 7.3.3.1. Applicability 625 This attribute applies to string instances. 627 7.3.3.2. Validation 629 A string instance is valid against this attribute if it is a valid 630 representation for an Internet host name, as defined by RFC 1034, 631 section 3.1 [RFC1034]. 633 7.3.4. ipv4 635 This attribute applies to string instances. 637 A string instance is valid against this attribute if it is a valid 638 representation of an IPv4 address according to the "dotted-quad" ABNF 639 syntax as defined in RFC 2673, section 3.2 [RFC2673]. 641 7.3.5. ipv6 643 This attribute applies to string instances. 645 A string instance is valid against this attribute if it is a valid 646 representation of an IPv6 address as defined in RFC 2373, section 2.2 647 [RFC2373]. 649 7.3.6. uri 651 This attribute applies to string instances. 653 A string instance is valid against this attribute if it is a valid 654 URI, according to [RFC3986]. 656 7.3.7. uriref 658 This attribute applies to string instances. 660 A string instance is valid against this attribute if it is a valid 661 URI Reference (either a URI or a relative-reference), according to 662 [RFC3986]. 664 8. Security considerations 666 JSON Schema validation defines a vocabulary for JSON Schema core and 667 conserns all the security considerations listed there. 669 JSON Schema validation allows the use of Regular Expressions, which 670 have numerous different (often incompatible) implementations. Some 671 implementations allow the embedding of arbritrary code, which is 672 outside the scope of JSON Schema and MUST NOT be permitted. Regular 673 expressions can often also be crafted to be extremely expensive to 674 compute (with so-called "catastrophic backtracking"), resulting in a 675 denial-of-service attack. 677 9. IANA Considerations 679 This specification does not have any influence with regards to IANA. 681 10. References 683 10.1. Normative References 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 687 RFC2119, March 1997, 688 . 690 [json-schema] 691 "JSON Schema: A Media Type for Describing JSON Documents", 692 draft-wright-json-schema-00 (work in progress), October 693 2016. 695 10.2. Informative References 697 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 698 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 699 . 701 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 702 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, 703 . 705 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", 706 RFC 2673, DOI 10.17487/RFC2673, August 1999, 707 . 709 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 710 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 711 . 713 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 714 Resource Identifier (URI): Generic Syntax", STD 66, RFC 715 3986, DOI 10.17487/RFC3986, January 2005, 716 . 718 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 719 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 720 2014, . 722 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 723 10.17487/RFC5322, October 2008, 724 . 726 [ecma262] "ECMA 262 specification", . 730 Appendix A. Acknowledgments 732 Thanks to Gary Court, Francis Galiegue, Kris Zyp, and Geraint Luff 733 for their work on the initial drafts of JSON Schema. 735 Thanks to Jason Desrosiers, Daniel Perrett, Erik Wilde, Ben Hutton, 736 Evgeny Poberezkin, and Henry H. Andrews for their submissions and 737 patches to the document. 739 Appendix B. ChangeLog 741 [[CREF1: This section to be removed before leaving Internet-Draft 742 status.]] 744 draft-wright-json-schema-validation-00 746 * Added additional security considerations 748 * Removed reference to "latest version" meta-schema, use numbered 749 version instead 751 * Rephrased many keyword definitions for brevity 753 * Added "uriref" format that also allows relative URI references 755 draft-fge-json-schema-validation-01 757 * Initial draft. 759 * Salvaged from draft v3. 761 * Redefine the "required" keyword. 763 * Remove "extends", "disallow" 765 * Add "anyOf", "allOf", "oneOf", "not", "definitions", 766 "minProperties", "maxProperties". 768 * "dependencies" member values can no longer be single strings; 769 at least one element is required in a property dependency 770 array. 772 * Rename "divisibleBy" to "multipleOf". 774 * "type" arrays can no longer have schemas; remove "any" as a 775 possible value. 777 * Rework the "format" section; make support optional. 779 * "format": remove attributes "phone", "style", "color"; rename 780 "ip-address" to "ipv4"; add references for all attributes. 782 * Provide algorithms to calculate schema(s) for array/object 783 instances. 785 * Add interoperability considerations. 787 Authors' Addresses 789 Austin Wright (editor) 791 EMail: aaa@bzfx.net 793 Geraint Luff 795 EMail: luffgd@gmail.com