idnits 2.17.1 draft-handrews-json-schema-validation-02.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 (September 16, 2019) is 1684 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2673 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 4329 (Obsoleted by RFC 9239) Summary: 2 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: March 19, 2020 6 B. Hutton, Ed. 7 Wellcome Sanger Institute 8 September 16, 2019 10 JSON Schema Validation: A Vocabulary for Structural Validation of JSON 11 draft-handrews-json-schema-validation-02 13 Abstract 15 JSON Schema (application/schema+json) has several purposes, one of 16 which is JSON instance validation. This document specifies a 17 vocabulary for JSON Schema to describe the meaning of JSON documents, 18 provide hints for user interfaces working with JSON data, and to make 19 assertions about what a valid document must look like. 21 Note to Readers 23 The issues list for this draft can be found at . 26 For additional information, see . 28 To provide feedback, use this issue tracker, the communication 29 methods listed on the homepage, or email the document editors. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 19, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Interoperability Considerations . . . . . . . . . . . . . . . 4 69 4.1. Validation of String Instances . . . . . . . . . . . . . 4 70 4.2. Validation of Numeric Instances . . . . . . . . . . . . . 5 71 4.3. Regular Expressions . . . . . . . . . . . . . . . . . . . 5 72 5. Meta-Schema . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 6. A Vocabulary for Structural Validation . . . . . . . . . . . 5 74 6.1. Validation Keywords for Any Instance Type . . . . . . . . 6 75 6.1.1. type . . . . . . . . . . . . . . . . . . . . . . . . 6 76 6.1.2. enum . . . . . . . . . . . . . . . . . . . . . . . . 6 77 6.1.3. const . . . . . . . . . . . . . . . . . . . . . . . . 6 78 6.2. Validation Keywords for Numeric Instances (number and 79 integer) . . . . . . . . . . . . . . . . . . . . . . . . 6 80 6.2.1. multipleOf . . . . . . . . . . . . . . . . . . . . . 6 81 6.2.2. maximum . . . . . . . . . . . . . . . . . . . . . . . 7 82 6.2.3. exclusiveMaximum . . . . . . . . . . . . . . . . . . 7 83 6.2.4. minimum . . . . . . . . . . . . . . . . . . . . . . . 7 84 6.2.5. exclusiveMinimum . . . . . . . . . . . . . . . . . . 7 85 6.3. Validation Keywords for Strings . . . . . . . . . . . . . 7 86 6.3.1. maxLength . . . . . . . . . . . . . . . . . . . . . . 7 87 6.3.2. minLength . . . . . . . . . . . . . . . . . . . . . . 8 88 6.3.3. pattern . . . . . . . . . . . . . . . . . . . . . . . 8 89 6.4. Validation Keywords for Arrays . . . . . . . . . . . . . 8 90 6.4.1. maxItems . . . . . . . . . . . . . . . . . . . . . . 8 91 6.4.2. minItems . . . . . . . . . . . . . . . . . . . . . . 8 92 6.4.3. uniqueItems . . . . . . . . . . . . . . . . . . . . . 8 93 6.4.4. maxContains . . . . . . . . . . . . . . . . . . . . . 9 94 6.4.5. minContains . . . . . . . . . . . . . . . . . . . . . 9 95 6.5. Validation Keywords for Objects . . . . . . . . . . . . . 9 96 6.5.1. maxProperties . . . . . . . . . . . . . . . . . . . . 9 97 6.5.2. minProperties . . . . . . . . . . . . . . . . . . . . 9 98 6.5.3. required . . . . . . . . . . . . . . . . . . . . . . 10 99 6.5.4. dependentRequired . . . . . . . . . . . . . . . . . . 10 100 7. A Vocabulary for Semantic Content With "format" . . . . . . . 10 101 7.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . 10 102 7.2. Implementation Requirements . . . . . . . . . . . . . . . 11 103 7.2.1. As an annotation . . . . . . . . . . . . . . . . . . 11 104 7.2.2. As an assertion . . . . . . . . . . . . . . . . . . . 12 105 7.2.3. Custom format attributes . . . . . . . . . . . . . . 13 106 7.3. Defined Formats . . . . . . . . . . . . . . . . . . . . . 13 107 7.3.1. Dates, Times, and Duration . . . . . . . . . . . . . 14 108 7.3.2. Email Addresses . . . . . . . . . . . . . . . . . . . 14 109 7.3.3. Hostnames . . . . . . . . . . . . . . . . . . . . . . 15 110 7.3.4. IP Addresses . . . . . . . . . . . . . . . . . . . . 15 111 7.3.5. Resource Identifiers . . . . . . . . . . . . . . . . 15 112 7.3.6. uri-template . . . . . . . . . . . . . . . . . . . . 16 113 7.3.7. JSON Pointers . . . . . . . . . . . . . . . . . . . . 16 114 7.3.8. regex . . . . . . . . . . . . . . . . . . . . . . . . 16 115 8. A Vocabulary for the Contents of String-Encoded Data . . . . 17 116 8.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . 17 117 8.2. Implementation Requirements . . . . . . . . . . . . . . . 17 118 8.3. contentEncoding . . . . . . . . . . . . . . . . . . . . . 18 119 8.4. contentMediaType . . . . . . . . . . . . . . . . . . . . 18 120 8.5. contentSchema . . . . . . . . . . . . . . . . . . . . . . 18 121 8.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 19 122 9. A Vocabulary for Basic Meta-Data Annotations . . . . . . . . 20 123 9.1. "title" and "description" . . . . . . . . . . . . . . . . 21 124 9.2. "default" . . . . . . . . . . . . . . . . . . . . . . . . 21 125 9.3. "deprecated" . . . . . . . . . . . . . . . . . . . . . . 21 126 9.4. "readOnly" and "writeOnly" . . . . . . . . . . . . . . . 22 127 9.5. "examples" . . . . . . . . . . . . . . . . . . . . . . . 22 128 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 129 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 130 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 131 11.2. Informative References . . . . . . . . . . . . . . . . . 25 132 Appendix A. Keywords Moved from Validation to Core . . . . . . . 26 133 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 26 134 Appendix C. ChangeLog . . . . . . . . . . . . . . . . . . . . . 27 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 137 1. Introduction 139 JSON Schema can be used to require that a given JSON document (an 140 instance) satisfies a certain number of criteria. These criteria are 141 asserted by using keywords described in this specification. In 142 addition, a set of keywords is also defined to assist in interactive 143 user interface instance generation. 145 This specification will use the concepts, syntax, and terminology 146 defined by the JSON Schema core [json-schema] specification. 148 2. Conventions and Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 This specification uses the term "container instance" to refer to 155 both array and object instances. It uses the term "children 156 instances" to refer to array elements or object member values. 158 Elements in an array value are said to be unique if no two elements 159 of this array are equal [json-schema]. 161 3. Overview 163 JSON Schema validation asserts constraints on the structure of 164 instance data. An instance location that satisfies all asserted 165 constraints is then annotated with any keywords that contain non- 166 assertion information, such as descriptive metadata and usage hints. 167 If all locations within the instance satisfy all asserted 168 constraints, then the instance is said to be valid against the 169 schema. 171 Each schema object is independently evaluated against each instance 172 location to which it applies. This greatly simplifies the 173 implementation requirements for validators by ensuring that they do 174 not need to maintain state across the document-wide validation 175 process. 177 This specification defines a set of assertion keywords, as well as a 178 small vocabulary of metadata keywords that can be used to annotate 179 the JSON instance with useful information. The Section 7 keyword is 180 intended primarily as an annotation, but can optionally be used as an 181 assertion. The Section 8 keywords are annotations for working with 182 documents embedded as JSON strings. 184 4. Interoperability Considerations 186 4.1. Validation of String Instances 188 It should be noted that the nul character (\u0000) is valid in a JSON 189 string. An instance to validate may contain a string value with this 190 character, regardless of the ability of the underlying programming 191 language to deal with such data. 193 4.2. Validation of Numeric Instances 195 The JSON specification allows numbers with arbitrary precision, and 196 JSON Schema does not add any such bounds. This means that numeric 197 instances processed by JSON Schema can be arbitrarily large and/or 198 have an arbitrarily long decimal part, regardless of the ability of 199 the underlying programming language to deal with such data. 201 4.3. Regular Expressions 203 Keywords that use regular expressions, or constrain the instance 204 value to be a regular expression, are subject to the interoperability 205 considerations for regular expressions in the JSON Schema Core 206 [json-schema] specification. 208 5. Meta-Schema 210 The current URI for the default JSON Schema meta-schema is 211 . For schema author 212 convenience, this meta-schema describes all vocabularies defined in 213 this specification and the JSON Schema Core specification, as well as 214 two former keywords which are reserved for a transitional period. 215 Individual vocabulary and vocabulary meta-schema URIs are given for 216 each section below. Certain vocabularies are optional to support, 217 which is explained in detail in the relevant sections. 219 Updated vocabulary and meta-schema URIs MAY be published between 220 specification drafts in order to correct errors. Implementations 221 SHOULD consider URIs dated after this specification draft and before 222 the next to indicate the same syntax and semantics as those listed 223 here. 225 6. A Vocabulary for Structural Validation 227 Validation keywords in a schema impose requirements for successful 228 validation of an instance. These keywords are all assertions without 229 any annotation behavior. 231 Meta-schemas that do not use "$vocabulary" SHOULD be considered to 232 require this vocabulary as if its URI were present with a value of 233 true. 235 The current URI for this vocabulary, known as the Validation 236 vocabulary, is: . 239 The current URI for the corresponding meta-schema is: . 242 6.1. Validation Keywords for Any Instance Type 244 6.1.1. type 246 The value of this keyword MUST be either a string or an array. If it 247 is an array, elements of the array MUST be strings and MUST be 248 unique. 250 String values MUST be one of the six primitive types ("null", 251 "boolean", "object", "array", "number", or "string"), or "integer" 252 which matches any number with a zero fractional part. 254 An instance validates if and only if the instance is in any of the 255 sets listed for this keyword. 257 6.1.2. enum 259 The value of this keyword MUST be an array. This array SHOULD have 260 at least one element. Elements in the array SHOULD be unique. 262 An instance validates successfully against this keyword if its value 263 is equal to one of the elements in this keyword's array value. 265 Elements in the array might be of any type, including null. 267 6.1.3. const 269 The value of this keyword MAY be of any type, including null. 271 Use of this keyword is functionally equivalent to an "enum" 272 (Section 6.1.2) with a single value. 274 An instance validates successfully against this keyword if its value 275 is equal to the value of the keyword. 277 6.2. Validation Keywords for Numeric Instances (number and integer) 279 6.2.1. multipleOf 281 The value of "multipleOf" MUST be a number, strictly greater than 0. 283 A numeric instance is valid only if division by this keyword's value 284 results in an integer. 286 6.2.2. maximum 288 The value of "maximum" MUST be a number, representing an inclusive 289 upper limit for a numeric instance. 291 If the instance is a number, then this keyword validates only if the 292 instance is less than or exactly equal to "maximum". 294 6.2.3. exclusiveMaximum 296 The value of "exclusiveMaximum" MUST be number, representing an 297 exclusive upper limit for a numeric instance. 299 If the instance is a number, then the instance is valid only if it 300 has a value strictly less than (not equal to) "exclusiveMaximum". 302 6.2.4. minimum 304 The value of "minimum" MUST be a number, representing an inclusive 305 lower limit for a numeric instance. 307 If the instance is a number, then this keyword validates only if the 308 instance is greater than or exactly equal to "minimum". 310 6.2.5. exclusiveMinimum 312 The value of "exclusiveMinimum" MUST be number, representing an 313 exclusive lower limit for a numeric instance. 315 If the instance is a number, then the instance is valid only if it 316 has a value strictly greater than (not equal to) "exclusiveMinimum". 318 6.3. Validation Keywords for Strings 320 6.3.1. maxLength 322 The value of this keyword MUST be a non-negative integer. 324 A string instance is valid against this keyword if its length is less 325 than, or equal to, the value of this keyword. 327 The length of a string instance is defined as the number of its 328 characters as defined by RFC 8259 [RFC8259]. 330 6.3.2. minLength 332 The value of this keyword MUST be a non-negative integer. 334 A string instance is valid against this keyword if its length is 335 greater than, or equal to, the value of this keyword. 337 The length of a string instance is defined as the number of its 338 characters as defined by RFC 8259 [RFC8259]. 340 Omitting this keyword has the same behavior as a value of 0. 342 6.3.3. pattern 344 The value of this keyword MUST be a string. This string SHOULD be a 345 valid regular expression, according to the ECMA 262 regular 346 expression dialect. 348 A string instance is considered valid if the regular expression 349 matches the instance successfully. Recall: regular expressions are 350 not implicitly anchored. 352 6.4. Validation Keywords for Arrays 354 6.4.1. maxItems 356 The value of this keyword MUST be a non-negative integer. 358 An array instance is valid against "maxItems" if its size is less 359 than, or equal to, the value of this keyword. 361 6.4.2. minItems 363 The value of this keyword MUST be a non-negative integer. 365 An array instance is valid against "minItems" if its size is greater 366 than, or equal to, the value of this keyword. 368 Omitting this keyword has the same behavior as a value of 0. 370 6.4.3. uniqueItems 372 The value of this keyword MUST be a boolean. 374 If this keyword has boolean value false, the instance validates 375 successfully. If it has boolean value true, the instance validates 376 successfully if all of its elements are unique. 378 Omitting this keyword has the same behavior as a value of false. 380 6.4.4. maxContains 382 The value of this keyword MUST be a non-negative integer. 384 An array instance is valid against "maxContains" if the number of 385 elements that are valid against the schema for "contains" 386 [json-schema] is less than, or equal to, the value of this keyword. 388 If "contains" is not present within the same schema object, then this 389 keyword has no effect. 391 6.4.5. minContains 393 The value of this keyword MUST be a non-negative integer. 395 An array instance is valid against "minContains" if the number of 396 elements that are valid against the schema for "contains" 397 [json-schema] is greater than, or equal to, the value of this 398 keyword. 400 A value of 0 is allowed, but is only useful for setting a range of 401 occurrences from 0 to the value of "maxContains". A value of 0 with 402 no "maxContains" causes "contains" to always pass validation. 404 If "contains" is not present within the same schema object, then this 405 keyword has no effect. 407 Omitting this keyword has the same behavior as a value of 1. 409 6.5. Validation Keywords for Objects 411 6.5.1. maxProperties 413 The value of this keyword MUST be a non-negative integer. 415 An object instance is valid against "maxProperties" if its number of 416 properties is less than, or equal to, the value of this keyword. 418 6.5.2. minProperties 420 The value of this keyword MUST be a non-negative integer. 422 An object instance is valid against "minProperties" if its number of 423 properties is greater than, or equal to, the value of this keyword. 425 Omitting this keyword has the same behavior as a value of 0. 427 6.5.3. required 429 The value of this keyword MUST be an array. Elements of this array, 430 if any, MUST be strings, and MUST be unique. 432 An object instance is valid against this keyword if every item in the 433 array is the name of a property in the instance. 435 Omitting this keyword has the same behavior as an empty array. 437 6.5.4. dependentRequired 439 The value of this keyword MUST be an object. Properties in this 440 object, if any, MUST be arrays. Elements in each array, if any, MUST 441 be strings, and MUST be unique. 443 This keyword specifies properties that are required if a specific 444 other property is present. Their requirement is dependent on the 445 presence of the other property. 447 Validation succeeds if, for each name that appears in both the 448 instance and as a name within this keyword's value, every item in the 449 corresponding array is also the name of a property in the instance. 451 Omitting this keyword has the same behavior as an empty object. 453 7. A Vocabulary for Semantic Content With "format" 455 7.1. Foreword 457 Structural validation alone may be insufficient to allow an 458 application to correctly utilize certain values. The "format" 459 annotation keyword is defined to allow schema authors to convey 460 semantic information for a fixed subset of values which are 461 accurately described by authoritative resources, be they RFCs or 462 other external specifications. 464 Implementations MAY treat "format" as an assertion in addition to an 465 annotation, and attempt to validate the value's conformance to the 466 specified semantics. See the Implementation Requirements below for 467 details. 469 The value of this keyword is called a format attribute. It MUST be a 470 string. A format attribute can generally only validate a given set 471 of instance types. If the type of the instance to validate is not in 472 this set, validation for this format attribute and instance SHOULD 473 succeed. All format attributes defined in this section apply to 474 strings, but a format attribute can be specified to apply to any 475 instance types defined in the data model defined in the core JSON 476 Schema. [json-schema] [[CREF1: Note that the "type" keyword in this 477 specification defines an "integer" type which is not part of the data 478 model. Therefore a format attribute can be limited to numbers, but 479 not specifically to integers. However, a numeric format can be used 480 alongside the "type" keyword with a value of "integer", or could be 481 explicitly defined to always pass if the number is not an integer, 482 which produces essentially the same behavior as only applying to 483 integers. ]] 485 Meta-schemas that do not use "$vocabulary" SHOULD be considered to 486 utilize this vocabulary as if its URI were present with a value of 487 false. See the Implementation Requirements below for details. 489 The current URI for this vocabulary, known as the Format vocabulary, 490 is: . 492 The current URI for the corresponding meta-schema is: . 495 7.2. Implementation Requirements 497 The "format" keyword functions as an annotation, and optionally as an 498 assertion. [[CREF2: This is due to the keyword's history, and is not 499 in line with current keyword design principles.]] In order to manage 500 this ambiguity, the "format" keyword is defined in its own separate 501 vocabulary, as noted above. The true or false value of the 502 vocabulary declaration governs the implementation requirements 503 necessary to process a schema that uses "format", and the behaviors 504 on which schema authors can rely. 506 7.2.1. As an annotation 508 The value of format MUST be collected as an annotation, if the 509 implementation supports annotation collection. This enables 510 application-level validation when schema validation is unavailable or 511 inadequate. 513 This requirement is not affected by the boolean value of the 514 vocabulary declaration, nor by the configuration of "format"'s 515 assertion behavior described in the next section. [[CREF3: Requiring 516 annotation collection even when the vocabulary is declared with a 517 value of false is atypical, but necessary to ensure that the best 518 practice of performing application-level validation is possible even 519 when assertion evaluation is not implemented. Since "format" has 520 always been a part of this specification, requiring implementations 521 to be aware of it even with a false vocabulary declaration is deemed 522 to not be a burden. ]] 524 7.2.2. As an assertion 526 Regardless of the boolean value of the vocabulary declaration, an 527 implementation that can evaluate "format" as an assertion MUST 528 provide options to enable and disable such evaluation. The assertion 529 evaluation behavior when the option is not explicitly specified 530 depends on the vocabulary declaration's boolean value. 532 When implementing this entire specification, this vocabulary MUST be 533 supported with a value of false (but see details below), and MAY be 534 supported with a value of true. 536 When the vocabulary is declared with a value of false, an 537 implementation: 539 MUST NOT evaluate "format" as an assertion unless it is explicitly 540 configured to do so; 542 SHOULD provide an implementation-specific best effort validation 543 for each format attribute defined below; 545 MAY choose to implement validation of any or all format attributes 546 as a no-op by always producing a validation result of true; 548 SHOULD document its level of support for validation. 550 [[CREF4: This matches the current reality of implementations, which 551 provide widely varying levels of validation, including no validation 552 at all, for some or all format attributes. It is also designed to 553 encourage relying only on the annotation behavior and performing 554 semantic validation in the application, which is the recommended best 555 practice. ]] 557 When the vocabulary is declared with a value of true, an 558 implementation that supports this form of the vocabulary: 560 MUST evaluate "format" as an assertion unless it is explicitly 561 configured not to do so; 563 MUST implement syntactic validation for all format attributes 564 defined in this specification, and for any additional format 565 attributes that it recognizes, such that there exist possible 566 instance values of the correct type that will fail validation. 568 The requirement for minimal validation of format attributes is 569 intentionally vague and permissive, due to the complexity involved in 570 many of the attributes. Note in particular that the requirement is 571 limited to syntactic checking; it is not to be expected that an 572 implementation would send an email, attempt to connect to a URL, or 573 otherwise check the existence of an entity identified by a format 574 instance. [[CREF5: The expectation is that for simple formats such 575 as date-time, syntactic validation will be thorough. For a complex 576 format such as email addresses, which are the amalgamation of various 577 standards and numerous adjustments over time, with obscure and/or 578 obsolete rules that may or may not be restricted by other 579 applications making use of the value, a minimal validation is 580 sufficient. For example, an instance string that does not contain an 581 "@" is clearly not a valid email address, and an "email" or 582 "hostname" containing characters outside of 7-bit ASCII is likewise 583 clearly invalid. ]] 585 It is RECOMMENDED that implementations use a common parsing library 586 for each format, or a well-known regular expression. Implementations 587 SHOULD clearly document how and to what degree each format attribute 588 is validated. 590 The standard core and validation meta-schema (Section 5) includes 591 this vocabulary in its "$vocabulary" keyword with a value of false, 592 since by default implementations are not required to support this 593 keyword as an assertion. Supporting the format vocabulary with a 594 value of true is understood to greatly increase code size and in some 595 cases execution time, and will not be appropriate for all 596 implementations. 598 7.2.3. Custom format attributes 600 Implementations MAY support custom format attributes. Save for 601 agreement between parties, schema authors SHALL NOT expect a peer 602 implementation to support such custom format attributes. An 603 implementation MUST NOT fail validation or cease processing due to an 604 unknown format attribute. When treating "format" as an annotation, 605 implementations SHOULD collect both known and unknown format 606 attribute values. 608 Vocabularies do not support specifically declaring different value 609 sets for keywords. Due to this limitation, and the historically 610 uneven implementation of this keyword, it is RECOMMENDED to define 611 additional keywords in a custom vocabulary rather than additional 612 format attributes if interoperability is desired. 614 7.3. Defined Formats 615 7.3.1. Dates, Times, and Duration 617 These attributes apply to string instances. 619 Date and time format names are derived from RFC 3339, section 5.6 620 [RFC3339]. The duration format is from the ISO 8601 ABNF as given in 621 Appendix A of RFC 3339. 623 Implementations supporting formats SHOULD implement support for the 624 following attributes: 626 date-time: A string instance is valid against this attribute if it 627 is a valid representation according to the "date-time" production. 629 date: A string instance is valid against this attribute if it is a 630 valid representation according to the "full-date" production. 632 time: A string instance is valid against this attribute if it is a 633 valid representation according to the "full-time" production. 635 duration: A string instance is valid against this attribute if it is 636 a valid representation according to the "duration" production. 638 Implementations MAY support additional attributes using the other 639 production names defined in that section. If "full-date" or "full- 640 time" are implemented, the corresponding short form ("date" or "time" 641 respectively) MUST be implemented, and MUST behave identically. 642 Implementations SHOULD NOT define extension attributes with any name 643 matching an RFC 3339 production unless it validates according to the 644 rules of that production. [[CREF6: There is not currently consensus 645 on the need for supporting all RFC 3339 formats, so this approach of 646 reserving the namespace will encourage experimentation without 647 committing to the entire set. Either the format implementation 648 requirements will become more flexible in general, or these will 649 likely either be promoted to fully specified attributes or dropped. 650 ]] 652 7.3.2. Email Addresses 654 These attributes apply to string instances. 656 A string instance is valid against these attributes if it is a valid 657 Internet email address as follows: 659 email: As defined by RFC 5322, section 3.4.1 [RFC5322]. 661 idn-email: As defined by RFC 6531 [RFC6531] 662 Note that all strings valid against the "email" attribute are also 663 valid against the "idn-email" attribute. 665 7.3.3. Hostnames 667 These attributes apply to string instances. 669 A string instance is valid against these attributes if it is a valid 670 representation for an Internet hostname as follows: 672 hostname: As defined by RFC 1123, section 2.1 [RFC1123], including 673 host names produced using the Punycode algorithm specified in RFC 674 5891, section 4.4 [RFC5891]. 676 idn-hostname: As defined by either RFC 1123 as for hostname, or an 677 internationalized hostname as defined by RFC 5890, section 2.3.2.3 678 [RFC5890]. 680 Note that all strings valid against the "hostname" attribute are also 681 valid against the "idn-hostname" attribute. 683 7.3.4. IP Addresses 685 These attributes apply to string instances. 687 A string instance is valid against these attributes if it is a valid 688 representation of an IP address as follows: 690 ipv4: An IPv4 address according to the "dotted-quad" ABNF syntax as 691 defined in RFC 2673, section 3.2 [RFC2673]. 693 ipv6: An IPv6 address as defined in RFC 4291, section 2.2 [RFC4291]. 695 7.3.5. Resource Identifiers 697 These attributes apply to string instances. 699 uri: A string instance is valid against this attribute if it is a 700 valid URI, according to [RFC3986]. 702 uri-reference: A string instance is valid against this attribute if 703 it is a valid URI Reference (either a URI or a relative- 704 reference), according to [RFC3986]. 706 iri: A string instance is valid against this attribute if it is a 707 valid IRI, according to [RFC3987]. 709 iri-reference: A string instance is valid against this attribute if 710 it is a valid IRI Reference (either an IRI or a relative- 711 reference), according to [RFC3987]. 713 uuid: A string instance is valid against this attribute if it is a 714 valid string representation of a UUID, according to [RFC4122]. 716 Note that all valid URIs are valid IRIs, and all valid URI References 717 are also valid IRI References. 719 Note also that the "uuid" format is for plain UUIDs, not UUIDs in 720 URNs. An example is "f81d4fae-7dec-11d0-a765-00a0c91e6bf6". For 721 UUIDs as URNs, use the "uri" format, with a "pattern" regular 722 expression of "^urn:uuid:" to indicate the URI scheme and URN 723 namespace. 725 7.3.6. uri-template 727 This attribute applies to string instances. 729 A string instance is valid against this attribute if it is a valid 730 URI Template (of any level), according to [RFC6570]. 732 Note that URI Templates may be used for IRIs; there is no separate 733 IRI Template specification. 735 7.3.7. JSON Pointers 737 These attributes apply to string instances. 739 json-pointer: A string instance is valid against this attribute if 740 it is a valid JSON string representation of a JSON Pointer, 741 according to RFC 6901, section 5 [RFC6901]. 743 relative-json-pointer: A string instance is valid against this 744 attribute if it is a valid Relative JSON Pointer 745 [relative-json-pointer]. 747 To allow for both absolute and relative JSON Pointers, use "anyOf" or 748 "oneOf" to indicate support for either format. 750 7.3.8. regex 752 This attribute applies to string instances. 754 A regular expression, which SHOULD be valid according to the ECMA 262 755 [ecma262] regular expression dialect. 757 Implementations that validate formats MUST accept at least the subset 758 of ECMA 262 defined in the Regular Expressions (Section 4.3) section 759 of this specification, and SHOULD accept all valid ECMA 262 760 expressions. 762 8. A Vocabulary for the Contents of String-Encoded Data 764 8.1. Foreword 766 Annotations defined in this section indicate that an instance 767 contains non-JSON data encoded in a JSON string. 769 These properties provide additional information required to interpret 770 JSON data as rich multimedia documents. They describe the type of 771 content, how it is encoded, and/or how it may be validated. They do 772 not function as validation assertions; a malformed string-encoded 773 document MUST NOT cause the containing instance to be considered 774 invalid. 776 Meta-schemas that do not use "$vocabulary" SHOULD be considered to 777 require this vocabulary as if its URI were present with a value of 778 true. 780 The current URI for this vocabulary, known as the Content vocabulary, 781 is: . 783 The current URI for the corresponding meta-schema is: . 786 8.2. Implementation Requirements 788 Due to security and performance concerns, as well as the open-ended 789 nature of possible content types, implementations MUST NOT 790 automatically decode, parse, and/or validate the string contents by 791 default. This additionally supports the use case of embedded 792 documents intended for processing by a different consumer than that 793 which processed the containing document. 795 All keywords in this section apply only to strings, and have no 796 effect on other data types. 798 Implementations MAY offer the ability to decode, parse, and/or 799 validate the string contents automatically. However, it MUST NOT 800 perform these operations by default, and MUST provide the validation 801 result of each string-encoded document separately from the enclosing 802 document. This process SHOULD be equivalent to fully evaluating the 803 instance against the original schema, followed by using the 804 annotations to decode, parse, and/or validate each string-encoded 805 document. [[CREF7: For now, the exact mechanism of performing and 806 returning parsed data and/or validation results from such an 807 automatic decoding, parsing, and validating feature is left 808 unspecified. Should such a feature prove popular, it may be 809 specified more thoroughly in a future draft. ]] 811 See also the Security Considerations (Section 10) sections for 812 possible vulnerabilities introduced by automatically processing the 813 instance string according to these keywords. 815 8.3. contentEncoding 817 If the instance value is a string, this property defines that the 818 string SHOULD be interpreted as binary data and decoded using the 819 encoding named by this property. 821 Possible values for this property are listed in RFC 2045, Sec 6.1 822 [RFC2045] and RFC 4648 [RFC4648]. For "base64", which is defined in 823 both RFCs, the definition in RFC 4648, which removes line length 824 limitations, SHOULD be used, as various other specifications have 825 mandated different lengths. Note that line lengths within a string 826 can be constrained using the "pattern" (Section 6.3.3) keyword. 828 If this keyword is absent, but "contentMediaType" is present, this 829 indicates that the media type could be encoded into UTF-8 like any 830 other JSON string value, and does not require additional decoding. 832 The value of this property MUST be a string. 834 8.4. contentMediaType 836 If the instance is a string, this property indicates the media type 837 of the contents of the string. If "contentEncoding" is present, this 838 property describes the decoded string. 840 The value of this property MUST be a string, which MUST be a media 841 type, as defined by RFC 2046 [RFC2046]. 843 8.5. contentSchema 845 If the instance is a string, and if "contentMediaType" is present, 846 this property contains a schema which describes the structure of the 847 string. 849 This keyword MAY be used with any media type that can be mapped into 850 JSON Schema's data model. 852 The value of this property SHOULD be ignored if "contentMediaType" is 853 not present. 855 8.6. Example 857 Here is an example schema, illustrating the use of "contentEncoding" 858 and "contentMediaType": 860 { 861 "type": "string", 862 "contentEncoding": "base64", 863 "contentMediaType": "image/png" 864 } 866 Instances described by this schema are expected to be strings, and 867 their values should be interpretable as base64-encoded PNG images. 869 Another example: 871 { 872 "type": "string", 873 "contentMediaType": "text/html" 874 } 876 Instances described by this schema are expected to be strings 877 containing HTML, using whatever character set the JSON string was 878 decoded into. Per section 8.1 of RFC 8259 [RFC8259], outside of an 879 entirely closed system, this MUST be UTF-8. 881 This example describes a JWT that is MACed using the HMAC SHA-256 882 algorithm, and requires the "iss" and "exp" fields in its claim set. 884 { 885 "type": "string", 886 "contentMediaType": "application/jwt", 887 "contentSchema": { 888 "type": "array", 889 "minItems": 2, 890 "items": [ 891 { 892 "const": { 893 "typ": "JWT", 894 "alg": "HS256" 895 } 896 }, 897 { 898 "type": "object", 899 "required": ["iss", "exp"], 900 "properties": { 901 "iss": {"type": "string"}, 902 "exp": {"type": "integer"} 903 } 904 } 905 ] 906 } 907 } 909 Note that "contentEncoding" does not appear. While the "application/ 910 jwt" media type makes use of base64url encoding, that is defined by 911 the media type, which determines how the JWT string is decoded into a 912 list of two JSON data structures: first the header, and then the 913 payload. Since the JWT media type ensures that the JWT can be 914 represented in a JSON string, there is no need for further encoding 915 or decoding. 917 9. A Vocabulary for Basic Meta-Data Annotations 919 These general-purpose annotation keywords provide commonly used 920 information for documentation and user interface display purposes. 921 They are not intended to form a comprehensive set of features. 922 Rather, additional vocabularies can be defined for more complex 923 annotation-based applications. 925 Meta-schemas that do not use "$vocabulary" SHOULD be considered to 926 require this vocabulary as if its URI were present with a value of 927 true. 929 The current URI for this vocabulary, known as the Meta-Data 930 vocabulary, is: . 933 The current URI for the corresponding meta-schema is: . 936 9.1. "title" and "description" 938 The value of both of these keywords MUST be a string. 940 Both of these keywords can be used to decorate a user interface with 941 information about the data produced by this user interface. A title 942 will preferably be short, whereas a description will provide 943 explanation about the purpose of the instance described by this 944 schema. 946 9.2. "default" 948 There are no restrictions placed on the value of this keyword. When 949 multiple occurrences of this keyword are applicable to a single sub- 950 instance, implementations SHOULD remove duplicates. 952 This keyword can be used to supply a default JSON value associated 953 with a particular schema. It is RECOMMENDED that a default value be 954 valid against the associated schema. 956 9.3. "deprecated" 958 The value of this keyword MUST be a boolean. When multiple 959 occurrences of this keyword are applicable to a single sub-instance, 960 applications SHOULD consider the instance location to be deprecated 961 if any occurrence specifies a true value. 963 If "deprecated" has a value of boolean true, it indicates that 964 applications SHOULD refrain from usage of the declared property. It 965 MAY mean the property is going to be removed in the future. 967 A root schema containing "deprecated" with a value of true indicates 968 that the entire resource being described MAY be removed in the 969 future. 971 When the "deprecated" keyword is applied to an item in an array by 972 means of "items", if "items" is a single schema, the deprecation 973 relates to the whole array, while if "items" is an array of schemas, 974 the deprecation relates to the corrosponding item according to the 975 subschemas position. 977 Omitting this keyword has the same behavior as a value of false. 979 9.4. "readOnly" and "writeOnly" 981 The value of these keywords MUST be a boolean. When multiple 982 occurrences of these keywords are applicable to a single sub- 983 instance, the resulting behavior SHOULD be as for a true value if any 984 occurrence specifies a true value, and SHOULD be as for a false value 985 otherwise. 987 If "readOnly" has a value of boolean true, it indicates that the 988 value of the instance is managed exclusively by the owning authority, 989 and attempts by an application to modify the value of this property 990 are expected to be ignored or rejected by that owning authority. 992 An instance document that is marked as "readOnly for the entire 993 document MAY be ignored if sent to the owning authority, or MAY 994 result in an error, at the authority's discretion. 996 If "writeOnly" has a value of boolean true, it indicates that the 997 value is never present when the instance is retrieved from the owning 998 authority. It can be present when sent to the owning authority to 999 update or create the document (or the resource it represents), but it 1000 will not be included in any updated or newly created version of the 1001 instance. 1003 An instance document that is marked as "writeOnly" for the entire 1004 document MAY be returned as a blank document of some sort, or MAY 1005 produce an error upon retrieval, or have the retrieval request 1006 ignored, at the authority's discretion. 1008 For example, "readOnly" would be used to mark a database-generated 1009 serial number as read-only, while "writeOnly" would be used to mark a 1010 password input field. 1012 These keywords can be used to assist in user interface instance 1013 generation. In particular, an application MAY choose to use a widget 1014 that hides input values as they are typed for write-only fields. 1016 Omitting these keywords has the same behavior as values of false. 1018 9.5. "examples" 1020 The value of this keyword MUST be an array. There are no 1021 restrictions placed on the values within the array. When multiple 1022 occurrences of this keyword are applicable to a single sub-instance, 1023 implementations MUST provide a flat array of all values rather than 1024 an array of arrays. 1026 This keyword can be used to provide sample JSON values associated 1027 with a particular schema, for the purpose of illustrating usage. It 1028 is RECOMMENDED that these values be valid against the associated 1029 schema. 1031 Implementations MAY use the value(s) of "default", if present, as an 1032 additional example. If "examples" is absent, "default" MAY still be 1033 used in this manner. 1035 10. Security Considerations 1037 JSON Schema validation defines a vocabulary for JSON Schema core and 1038 concerns all the security considerations listed there. 1040 JSON Schema validation allows the use of Regular Expressions, which 1041 have numerous different (often incompatible) implementations. Some 1042 implementations allow the embedding of arbitrary code, which is 1043 outside the scope of JSON Schema and MUST NOT be permitted. Regular 1044 expressions can often also be crafted to be extremely expensive to 1045 compute (with so-called "catastrophic backtracking"), resulting in a 1046 denial-of-service attack. 1048 Implementations that support validating or otherwise evaluating 1049 instance string data based on "contentEncoding" and/or 1050 "contentMediaType" are at risk of evaluating data in an unsafe way 1051 based on misleading information. Applications can mitigate this risk 1052 by only performing such processing when a relationship between the 1053 schema and instance is established (e.g., they share the same 1054 authority). 1056 Processing a media type or encoding is subject to the security 1057 considerations of that media type or encoding. For example, the 1058 security considerations of RFC 4329 Scripting Media Types [RFC4329] 1059 apply when processing JavaScript or ECMAScript encoded within a JSON 1060 string. 1062 11. References 1064 11.1. Normative References 1066 [ecma262] "ECMA 262 specification", . 1070 [json-schema] 1071 Wright, A. and H. Andrews, "JSON Schema: A Media Type for 1072 Describing JSON Documents", draft-handrews-json-schema-02 1073 (work in progress), November 2017. 1075 [relative-json-pointer] 1076 Luff, G. and H. Andrews, "Relative JSON Pointers", draft- 1077 handrews-relative-json-pointer-01 (work in progress), 1078 November 2017. 1080 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1081 Application and Support", STD 3, RFC 1123, 1082 DOI 10.17487/RFC1123, October 1989, 1083 . 1085 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1086 Extensions (MIME) Part One: Format of Internet Message 1087 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1088 . 1090 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1091 Extensions (MIME) Part Two: Media Types", RFC 2046, 1092 DOI 10.17487/RFC2046, November 1996, 1093 . 1095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", BCP 14, RFC 2119, 1097 DOI 10.17487/RFC2119, March 1997, 1098 . 1100 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", 1101 RFC 2673, DOI 10.17487/RFC2673, August 1999, 1102 . 1104 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1105 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1106 . 1108 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1109 Resource Identifier (URI): Generic Syntax", STD 66, 1110 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1111 . 1113 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1114 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 1115 January 2005, . 1117 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1118 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1119 DOI 10.17487/RFC4122, July 2005, 1120 . 1122 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1123 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1124 2006, . 1126 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1127 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1128 . 1130 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1131 DOI 10.17487/RFC5322, October 2008, 1132 . 1134 [RFC5890] Klensin, J., "Internationalized Domain Names for 1135 Applications (IDNA): Definitions and Document Framework", 1136 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1137 . 1139 [RFC5891] Klensin, J., "Internationalized Domain Names in 1140 Applications (IDNA): Protocol", RFC 5891, 1141 DOI 10.17487/RFC5891, August 2010, 1142 . 1144 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 1145 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 1146 . 1148 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 1149 and D. Orchard, "URI Template", RFC 6570, 1150 DOI 10.17487/RFC6570, March 2012, 1151 . 1153 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 1154 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 1155 DOI 10.17487/RFC6901, April 2013, 1156 . 1158 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1159 Interchange Format", STD 90, RFC 8259, 1160 DOI 10.17487/RFC8259, December 2017, 1161 . 1163 11.2. Informative References 1165 [RFC4329] Hoehrmann, B., "Scripting Media Types", RFC 4329, 1166 DOI 10.17487/RFC4329, April 2006, 1167 . 1169 Appendix A. Keywords Moved from Validation to Core 1171 Several keywords have been moved from this document into the Core 1172 Specification [json-schema] as of this draft, in some cases with re- 1173 naming or other changes. This affects the following former 1174 validation keywords: 1176 "definitions" Renamed to "$defs" to match "$ref" and be shorter to 1177 type. Schema vocabulary authors SHOULD NOT define a "definitions" 1178 keyword with different behavior in order to avoid invalidating 1179 schemas that still use the older name. While "definitions" is 1180 absent in the single-vocabulary meta-schemas referenced by this 1181 document, it remains present in the default meta-schema, and 1182 implementations SHOULD assume that "$defs" and "definitions" have 1183 the same behavior when that meta-schema is used. 1185 "allOf", "anyOf", "oneOf", "not", "if", "then", "else", 1186 "items", "additionalItems", 1187 "contains", "propertyNames", 1188 "properties", "patternProperties", "additionalProperties" 1189 All of these keywords apply subschemas to the instance and combine 1190 their results, without asserting any conditions of their own. 1191 Without assertion keywords, these applicators can only cause 1192 assertion failures by using the false boolean schema, or by 1193 inverting the result of the true boolean schema (or equivalent 1194 schema objects). For this reason, they are better defined as a 1195 generic mechanism on which validation, hyper-schema, and extension 1196 vocabularies can all be based. 1198 "dependencies" This keyword had two different modes of behavior, 1199 which made it relatively challenging to implement and reason 1200 about. The schema form has been moved to Core and renamed to 1201 "dependentSchemas", as part of the applicator vocabulary. It is 1202 analogous to "properties", except that instead of applying its 1203 subschema to the property value, it applies it to the object 1204 containing the property. The property name array form is retained 1205 here and renamed to "dependentRequired", as it is an assertion 1206 which is a shortcut for the conditional use of the "required" 1207 assertion keyword. 1209 Appendix B. Acknowledgments 1211 Thanks to Gary Court, Francis Galiegue, Kris Zyp, and Geraint Luff 1212 for their work on the initial drafts of JSON Schema. 1214 Thanks to Jason Desrosiers, Daniel Perrett, Erik Wilde, Ben Hutton, 1215 Evgeny Poberezkin, Brad Bowman, Gowry Sankar, Donald Pipowitch, Dave 1216 Finlay, and Denis Laxalde for their submissions and patches to the 1217 document. 1219 Appendix C. ChangeLog 1221 [[CREF8: This section to be removed before leaving Internet-Draft 1222 status.]] 1224 draft-handrews-json-schema-validation-02 1226 * Grouped keywords into formal vocabuarlies 1228 * Update "format" implementation requirements in terms of 1229 vocabularies 1231 * By default, "format" MUST NOT be validated, although validation 1232 can be enabled 1234 * A vocabulary declaration can be used to require "format" 1235 validation 1237 * Moved "definitions" to the core spec as "$defs" 1239 * Moved applicator keywords to the core spec 1241 * Renamed the array form of "dependencies" to 1242 "dependentRequired", moved the schema form to the core spec 1244 * Specified all "content*" keywords as annotations, not 1245 assertions 1247 * Added "contentSchema" to allow applying a schema to a string- 1248 encoded document 1250 * Also allow RFC 4648 encodings in "contentEncoding" 1252 * Added "minContains" and "maxContains" 1254 * Update RFC reference for "hostname" and "idn-hostname" 1256 * Add "uuid" and "duration" formats 1258 draft-handrews-json-schema-validation-01 1260 * This draft is purely a clarification with no functional changes 1262 * Provided the general principle behind ignoring annotations 1263 under "not" and similar cases 1265 * Clarified "if"/"then"/"else" validation interactions 1267 * Clarified "if"/"then"/"else" behavior for annotation 1269 * Minor formatting and cross-referencing improvements 1271 draft-handrews-json-schema-validation-00 1273 * Added "if"/"then"/"else" 1275 * Classify keywords as assertions or annotations per the core 1276 spec 1278 * Warn of possibly removing "dependencies" in the future 1280 * Grouped validation keywords into sub-sections for readability 1282 * Moved "readOnly" from hyper-schema to validation meta-data 1284 * Added "writeOnly" 1286 * Added string-encoded media section, with former hyper-schema 1287 "media" keywords 1289 * Restored "regex" format (removal was unintentional) 1291 * Added "date" and "time" formats, and reserved additional RFC 1292 3339 format names 1294 * I18N formats: "iri", "iri-reference", "idn-hostname", "idn- 1295 email" 1297 * Clarify that "json-pointer" format means string encoding, not 1298 URI fragment 1300 * Fixed typo that inverted the meaning of "minimum" and 1301 "exclusiveMinimum" 1303 * Move format syntax references into Normative References 1305 * JSON is a normative requirement 1307 draft-wright-json-schema-validation-01 1309 * Standardized on hyphenated format names with full words 1310 ("uriref" becomes "uri-reference") 1312 * Add the formats "uri-template" and "json-pointer" 1313 * Changed "exclusiveMaximum"/"exclusiveMinimum" from boolean 1314 modifiers of "maximum"/"minimum" to independent numeric fields. 1316 * Split the additionalItems/items into two sections 1318 * Reworked properties/patternProperties/additionalProperties 1319 definition 1321 * Added "examples" keyword 1323 * Added "contains" keyword 1325 * Allow empty "required" and "dependencies" arrays 1327 * Fixed "type" reference to primitive types 1329 * Added "const" keyword 1331 * Added "propertyNames" keyword 1333 draft-wright-json-schema-validation-00 1335 * Added additional security considerations 1337 * Removed reference to "latest version" meta-schema, use numbered 1338 version instead 1340 * Rephrased many keyword definitions for brevity 1342 * Added "uriref" format that also allows relative URI references 1344 draft-fge-json-schema-validation-00 1346 * Initial draft. 1348 * Salvaged from draft v3. 1350 * Redefine the "required" keyword. 1352 * Remove "extends", "disallow" 1354 * Add "anyOf", "allOf", "oneOf", "not", "definitions", 1355 "minProperties", "maxProperties". 1357 * "dependencies" member values can no longer be single strings; 1358 at least one element is required in a property dependency 1359 array. 1361 * Rename "divisibleBy" to "multipleOf". 1363 * "type" arrays can no longer have schemas; remove "any" as a 1364 possible value. 1366 * Rework the "format" section; make support optional. 1368 * "format": remove attributes "phone", "style", "color"; rename 1369 "ip-address" to "ipv4"; add references for all attributes. 1371 * Provide algorithms to calculate schema(s) for array/object 1372 instances. 1374 * Add interoperability considerations. 1376 Authors' Addresses 1378 Austin Wright (editor) 1380 EMail: aaa@bzfx.net 1382 Henry Andrews (editor) 1384 EMail: andrews_henry@yahoo.com 1386 Ben Hutton (editor) 1387 Wellcome Sanger Institute 1389 EMail: bh7@sanger.ac.uk 1390 URI: https://jsonschema.dev