idnits 2.17.1 draft-wright-json-schema-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 : ---------------------------------------------------------------------------- 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 (April 15, 2017) is 2539 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'A-Za-z' is mentioned on line 413, but not defined == Missing Reference: '0-9' is mentioned on line 414, but not defined ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 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: October 17, 2017 Cloudflare, Inc. 6 April 15, 2017 8 JSON Schema: A Media Type for Describing JSON Documents 9 draft-wright-json-schema-01 11 Abstract 13 JSON Schema defines the media type "application/schema+json", a JSON- 14 based format for describing the structure of JSON data. JSON Schema 15 asserts what a JSON document must look like, ways to extract 16 information from it, and how to interact with it, ideal for 17 annotating existing JSON APIs that would not otherwise have 18 hypermedia controls or be machine-readable. 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 http://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 October 17, 2017. 47 Copyright Notice 49 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 66 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Validation . . . . . . . . . . . . . . . . . . . . . . . 3 68 3.2. Hypermedia and Linking . . . . . . . . . . . . . . . . . 4 69 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4.1. JSON Document . . . . . . . . . . . . . . . . . . . . . . 4 71 4.2. Instance . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4.3. Instance equality . . . . . . . . . . . . . . . . . . . . 5 73 4.4. JSON Schema documents . . . . . . . . . . . . . . . . . . 5 74 4.5. Root schema and subschemas . . . . . . . . . . . . . . . 6 75 5. Fragment identifiers . . . . . . . . . . . . . . . . . . . . 6 76 6. General considerations . . . . . . . . . . . . . . . . . . . 7 77 6.1. Range of JSON values . . . . . . . . . . . . . . . . . . 7 78 6.2. Programming language independence . . . . . . . . . . . . 7 79 6.3. Mathematical integers . . . . . . . . . . . . . . . . . . 7 80 6.4. Extending JSON Schema . . . . . . . . . . . . . . . . . . 7 81 7. The "$schema" keyword . . . . . . . . . . . . . . . . . . . . 8 82 8. Schema references with $ref . . . . . . . . . . . . . . . . . 8 83 9. Base URI and dereferencing . . . . . . . . . . . . . . . . . 9 84 9.1. Initial base URI . . . . . . . . . . . . . . . . . . . . 9 85 9.2. The "$id" keyword . . . . . . . . . . . . . . . . . . . . 9 86 9.2.1. Internal references . . . . . . . . . . . . . . . . . 10 87 9.2.2. External references . . . . . . . . . . . . . . . . . 11 88 10. Usage for hypermedia . . . . . . . . . . . . . . . . . . . . 11 89 10.1. Linking to a schema . . . . . . . . . . . . . . . . . . 12 90 10.2. Describing a profile of JSON . . . . . . . . . . . . . . 12 91 10.3. Usage over HTTP . . . . . . . . . . . . . . . . . . . . 13 92 11. Security considerations . . . . . . . . . . . . . . . . . . . 13 93 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 94 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 96 13.2. Informative References . . . . . . . . . . . . . . . . . 15 97 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 98 Appendix B. ChangeLog . . . . . . . . . . . . . . . . . . . . . 17 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 101 1. Introduction 103 JSON Schema is a JSON media type for defining the structure of JSON 104 data. JSON Schema is intended to define validation, documentation, 105 hyperlink navigation, and interaction control of JSON data. 107 This specification defines JSON Schema core terminology and 108 mechanisms, including pointing to another JSON Schema by reference, 109 dereferencing a JSON Schema reference, and specifying the vocabulary 110 being used. 112 Other specifications define the vocabularies that perform assertions 113 about validation, linking, annotation, navigation, and interaction. 115 2. Conventions and Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 The terms "JSON", "JSON text", "JSON value", "member", "element", 122 "object", "array", "number", "string", "boolean", "true", "false", 123 and "null" in this document are to be interpreted as defined in RFC 124 7159 [RFC7159]. 126 3. Overview 128 This document proposes a new media type "application/schema+json" to 129 identify a JSON Schema for describing JSON data. JSON Schemas are 130 themselves JSON documents. This, and related specifications, define 131 keywords allowing authors to describe JSON data in several ways. 133 3.1. Validation 135 JSON Schema describes the structure of a JSON document (for instance, 136 required properties and length limitations). Applications can use 137 this information to validate instances (check that constraints are 138 met), or inform interfaces to collect user input such that the 139 constraints are satisfied. 141 Validation behaviour and keywords are specified in a separate 142 document [json-schema-validation]. 144 3.2. Hypermedia and Linking 146 JSON Hyper-Schema describes the hypertext structure of a JSON 147 document. This includes link relations from the instance to other 148 resources, interpretation of instances as multimedia data, and 149 submission data required to use an API. 151 Hyper-schema behaviour and keywords are specified in a separate 152 document [json-hyper-schema]. 154 4. Definitions 156 4.1. JSON Document 158 A JSON document is an information resource (series of octets) 159 described by the application/json media type. 161 In JSON Schema, the terms "JSON document", "JSON text", and "JSON 162 value" are interchangeable because of the data model it defines. 164 JSON Schema is only defined over JSON documents. However, any 165 document or memory structure that can be parsed into or processed 166 according to the JSON Schema data model can be interpreted against a 167 JSON Schema, including media types like CBOR [RFC7049]. 169 4.2. Instance 171 JSON Schema interprets documents according to a data model. A JSON 172 value interpreted according to this data model is called an 173 "instance". 175 An instance has one of six primitive types, and a range of possible 176 values depending on the type: 178 null A JSON "null" production 180 boolean A "true" or "false" value, from the JSON "true" or "false" 181 productions 183 object An unordered set of properties mapping a string to an 184 instance, from the JSON "object" production 186 array An ordered list of instances, from the JSON "array" production 188 number An arbitrary-precision, base-10 decimal number value, from 189 the JSON "number" production 191 string A string of Unicode code points, from the JSON "string" 192 production 194 Whitespace and formatting concerns are thus outside the scope of JSON 195 Schema. 197 Since an object cannot have two properties with the same key, 198 behavior for a JSON document that tries to define two properties (the 199 "member" production) with the same key (the "string" production) in a 200 single object is undefined. 202 4.3. Instance equality 204 Two JSON instances are said to be equal if and only if they are of 205 the same type and have the same value according to the data model. 206 Specifically, this means: 208 both are null; or 210 both are true; or 212 both are false; or 214 both are strings, and are the same codepoint-for-codepoint; or 216 both are numbers, and have the same mathematical value; or 218 both are arrays, and have an equal value item-for-item; or 220 both are objects, and each property in one has exactly one 221 property with a key equal to the other's, and that other property 222 has an equal value. 224 Implied in this definition is that arrays must be the same length, 225 objects must have the same number of members, properties in objects 226 are unordered, there is no way to define multiple properties with the 227 same key, and mere formatting differences (indentation, placement of 228 commas, trailing zeros) are insignificant. 230 4.4. JSON Schema documents 232 A JSON Schema document, or simply a schema, is a JSON document used 233 to describe an instance. A schema is itself interpreted as an 234 instance. A JSON Schema MUST be an object or a boolean. 236 Boolean values are equivalent to the following behaviors: 238 true Always passes validation, as if the empty schema {} 239 false Always fails validation, as if the schema { "not":{} } 241 Properties that are used to describe the instance are called 242 keywords, or schema keywords. The meaning of properties is specified 243 by the vocabulary that the schema is using. 245 A JSON Schema MAY contain properties which are not schema keywords. 246 Unknown keywords SHOULD be ignored. 248 A schema that itself describes a schema is called a meta-schema. 249 Meta-schemas are used to validate JSON Schemas and specify which 250 vocabulary it is using. 252 An empty schema is a JSON Schema with no properties, or only unknown 253 properties. 255 4.5. Root schema and subschemas 257 The root schema is the schema that comprises the entire JSON document 258 in question. 260 Some keywords take schemas themselves, allowing JSON Schemas to be 261 nested: 263 { 264 "title": "root", 265 "items": { 266 "title": "array item" 267 } 268 } 270 In this example document, the schema titled "array item" is a 271 subschema, and the schema titled "root" is the root schema. 273 As with the root schema, a subschema is either an object or a 274 boolean. 276 5. Fragment identifiers 278 In accordance with section 3.1 of [RFC6839], the syntax and semantics 279 of fragment identifiers specified for any +json media type SHOULD be 280 as specified for "application/json". (At publication of this 281 document, there is no fragment identification syntax defined for 282 "application/json".) 283 Additionally, the "application/schema+json" media type supports two 284 fragment identifier structures: plain names and JSON Pointers. The 285 use of JSON Pointers as URI fragment identifiers is described in RFC 286 6901 [RFC6901]. Fragment identifiers matching the JSON Pointer 287 syntax, including the empty string, MUST be interpreted as JSON 288 Pointer fragment identifiers. 290 Per the W3C's best practices for fragment identifiers 291 [W3C.WD-fragid-best-practices-20121025], plain name fragment 292 identifiers are reserved for referencing locally named schemas. All 293 fragment identifiers that do not match the JSON Pointer syntax MUST 294 be interpreted as plain name fragment identifiers. 296 Defining and referencing a plain name fragment identifier in the 297 "$id" keyword (Section 9.2) section. 299 6. General considerations 301 6.1. Range of JSON values 303 An instance may be any valid JSON value as defined by JSON [RFC7159]. 304 JSON Schema imposes no restrictions on type: JSON Schema can describe 305 any JSON value, including, for example, null. 307 6.2. Programming language independence 309 JSON Schema is programming language agnostic, and supports the full 310 range of values described in the data model. Be aware, however, that 311 some languages and JSON parsers may not be able to represent in 312 memory the full range of values describable by JSON. 314 6.3. Mathematical integers 316 Some programming languages and parsers use different internal 317 representations for floating point numbers than they do for integers. 319 For consistency, integer JSON numbers SHOULD NOT be encoded with a 320 fractional part. 322 6.4. Extending JSON Schema 324 Implementations MAY define additional keywords to JSON Schema. Save 325 for explicit agreement, schema authors SHALL NOT expect these 326 additional keywords to be supported by peer implementations. 327 Implementations SHOULD ignore keywords they do not support. 329 Authors of extensions to JSON Schema are encouraged to write their 330 own meta-schemas, which extend the existing meta-schemas using 331 "allOf". This extended meta-schema SHOULD be referenced using the 332 "$schema" keyword, to allow tools to follow the correct behaviour. 334 7. The "$schema" keyword 336 The "$schema" keyword is both used as a JSON Schema version 337 identifier and the location of a resource which is itself a JSON 338 Schema, which describes any schema written for this particular 339 version. 341 The value of this keyword MUST be a URI [RFC3986] (containing a 342 scheme) and this URI MUST be normalized. The current schema MUST be 343 valid against the meta-schema identified by this URI. 345 The "$schema" keyword SHOULD be used in a root schema. It MUST NOT 346 appear in subschemas. 348 [[CREF1: While this pattern is likely to remain best practice for 349 schema authoring, implementation behavior is subject to be revised or 350 liberalized in future drafts.]] 352 Values for this property are defined in other documents and by other 353 parties. JSON Schema implementations SHOULD implement support for 354 current and previous published drafts of JSON Schema vocabularies as 355 deemed reasonable. 357 8. Schema references with $ref 359 The "$ref" keyword is used to reference a schema, and provides the 360 ability to validate recursive structures through self-reference. 362 An object schema with a "$ref" property MUST be interpreted as a 363 "$ref" reference. The value of the "$ref" property MUST be a URI 364 Reference. Resolved against the current URI base, it identifies the 365 URI of a schema to use. All other properties in a "$ref" object MUST 366 be ignored. 368 The URI is not a network locator, only an identifier. A schema need 369 not be downloadable from the address if it is a network-addressable 370 URL, and implementations SHOULD NOT assume they should perform a 371 network operation when they encounter a network-addressable URI. 373 A schema MUST NOT be run into an infinite loop against a schema. For 374 example, if two schemas "#alice" and "#bob" both have an "allOf" 375 property that refers to the other, a naive validator might get stuck 376 in an infinite recursive loop trying to validate the instance. 377 Schemas SHOULD NOT make use of infinite recursive nesting like this; 378 the behavior is undefined. 380 9. Base URI and dereferencing 382 9.1. Initial base URI 384 RFC3986 Section 5.1 [RFC3986] defines how to determine the default 385 base URI of a document. 387 Informatively, the initial base URI of a schema is the URI at which 388 it was found, or a suitable substitute URI if none is known. 390 9.2. The "$id" keyword 392 The "$id" keyword defines a URI for the schema, and the base URI that 393 other URI references within the schema are resolved against. The 394 "$id" keyword itself is resolved against the base URI that the object 395 as a whole appears in. 397 If present, the value for this keyword MUST be a string, and MUST 398 represent a valid URI-reference [RFC3986]. This value SHOULD be 399 normalized, and SHOULD NOT be an empty fragment <#> or an empty 400 string <>. 402 The root schema of a JSON Schema document SHOULD contain an "$id" 403 keyword with a URI (containing a scheme). This URI SHOULD either not 404 have a fragment, or have one that is an empty string. [[CREF2: How 405 should an "$id" URI reference containing a fragement with other 406 components be interpreted? There are two cases: when the other 407 components match the current base URI and when they change the base 408 URI. ]] 410 To name subschemas in a JSON Schema document, subschemas can use 411 "$id" to give themselves a document-local identifier. This is done 412 by setting "$id" to a URI reference consisting only of a fragment. 413 The fragment identifier MUST begin with a letter ([A-Za-z]), followed 414 by any number of letters, digits ([0-9]), hyphens ("-"), underscores 415 ("_"), colons (":"), or periods ("."). 417 The effect of defining an "$id" that neither matches the above 418 requirements nor is a valid JSON pointer is not defined. 420 For example: 422 { 423 "$id": "http://example.com/root.json", 424 "definitions": { 425 "A": { "$id": "#foo" }, 426 "B": { 427 "$id": "other.json", 428 "definitions": { 429 "X": { "$id": "#bar" }, 430 "Y": { "$id": "t/inner.json" } 431 } 432 }, 433 "C": { 434 "$id": "urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f" 435 } 436 } 437 } 439 The schemas at the following URI-encoded JSON Pointers [RFC6901] 440 (relative to the root schema) have the following base URIs, and are 441 identifiable by either URI in accordance with Section 5 above: 443 # (document root) http://example.com/root.json# 445 #/definitions/A http://example.com/root.json#foo 447 #/definitions/B http://example.com/other.json 449 #/definitions/B/definitions/X http://example.com/other.json#bar 451 #/definitions/B/definitions/Y http://example.com/t/inner.json 453 #/definitions/C urn:uuid:ee564b8a-7a87-4125-8c96-e9f123d6766f 455 9.2.1. Internal references 457 Schemas can be identified by any URI that has been given to them, 458 including a JSON Pointer or their URI given directly by "$id". 460 Tools SHOULD take note of the URIs that schemas, including 461 subschemas, provide for themselves using "$id". This is known as 462 "Internal referencing". 464 For example, consider this schema: 466 { 467 "$id": "http://example.net/root.json", 468 "items": { 469 "type": "array", 470 "items": { "$ref": "#item" } 471 }, 472 "definitions": { 473 "single": { 474 "$id": "#item", 475 "type": "integer" 476 } 477 } 478 } 480 When an implementation encounters the <#/definitions/single> schema, 481 it resolves the "$id" URI reference against the current base URI to 482 form . 484 When an implementation then looks inside the <#/items> schema, it 485 encounters the <#item> reference, and resolves this to 486 which is understood as the schema 487 defined elsewhere in the same document. 489 9.2.2. External references 491 To differentiate schemas between each other in a vast ecosystem, 492 schemas are identified by URI. As specified above, this does not 493 necessarily mean anything is downloaded, but instead JSON Schema 494 implementations SHOULD already understand the schemas they will be 495 using, including the URIs that identify them. 497 Implementations SHOULD be able to associate arbitrary URIs with an 498 arbitrary schema and/or automatically associate a schema's "$id"- 499 given URI, depending on the trust that the validator has in the 500 schema. 502 A schema MAY (and likely will) have multiple URIs, but there is no 503 way for a URI to identify more than one schema. When multiple 504 schemas try to identify with the same URI, validators SHOULD raise an 505 error condition. 507 10. Usage for hypermedia 509 JSON has been adopted widely by HTTP servers for automated APIs and 510 robots. This section describes how to enhance processing of JSON 511 documents in a more RESTful manner when used with protocols that 512 support media types and Web linking [RFC5988]. 514 10.1. Linking to a schema 516 It is RECOMMENDED that instances described by a schema/profile 517 provide a link to a downloadable JSON Schema using the link relation 518 "describedby", as defined by Linked Data Protocol 1.0, section 8.1 519 [W3C.REC-ldp-20150226]. 521 In HTTP, such links can be attached to any response using the Link 522 header [RFC5988]. An example of such a header would be: 524 Link: ; rel="describedby" 526 10.2. Describing a profile of JSON 528 Instances MAY specify a "profile" as described in The 'profile' Link 529 Relation [RFC6906]. When used as a media-type parameter, HTTP 530 servers gain the ability to perform Content-Type Negotiation based on 531 profile. The media-type parameter MUST be a whitespace-separated 532 list of URIs (i.e. relative references are invalid). 534 The profile URI is opaque and SHOULD NOT automatically be 535 dereferenced. If the implementation does not understand the 536 semantics of the provided profile, the implementation can instead 537 follow the "describedby" links, if any, which may provide information 538 on how to handle the profile. Since "profile" doesn't necessarily 539 point to a network location, the "describedby" relation is used for 540 linking to a downloadable schema. However, for simplicity, schema 541 authors should make these URIs point to the same resource when 542 possible. 544 In HTTP, the media-type parameter would be sent inside the Content- 545 Type header: 547 Content-Type: application/json; 548 profile="http://example.com/my-hyper-schema#" 550 Multiple profiles are whitespace separated: 552 Content-Type: application/json; 553 profile="http://example.com/alice http://example.com/bob" 555 HTTP can also send the "profile" in a Link, though this may impact 556 media-type semantics and Content-Type negotiation if this replaces 557 the media-type parameter entirely: 559 Link: ;rel="profile", ;rel="profile" 561 10.3. Usage over HTTP 563 When used for hypermedia systems over a network, HTTP [RFC7231] is 564 frequently the protocol of choice for distributing schemas. 565 Misbehaving clients can pose problems for server maintainers if they 566 pull a schema over the network more frequently than necessary, when 567 it's instead possible to cache a schema for a long period of time. 569 HTTP servers SHOULD set long-lived caching headers on JSON Schemas. 570 HTTP clients SHOULD observe caching headers and not re-request 571 documents within their freshness period. Distributed systems SHOULD 572 make use of a shared cache and/or caching proxy. 574 Clients SHOULD set or prepend a User-Agent header specific to the 575 JSON Schema implementation or software product. Since symbols are 576 listed in decreasing order of significance, the JSON Schema library 577 name/version should precede the more generic HTTP library name (if 578 any). For example: 580 User-Agent: product-name/5.4.1 so-cool-json-schema/1.0.2 curl/7.43.0 582 Clients SHOULD be able to make requests with a "From" header so that 583 server operators can contact the owner of a potentially misbehaving 584 script. 586 11. Security considerations 588 Both schemas and instances are JSON values. As such, all security 589 considerations defined in RFC 7159 [RFC7159] apply. 591 Instances and schemas are both frequently written by untrusted third 592 parties, to be deployed on public Internet servers. Validators 593 should take care that the parsing of schemas doesn't consume 594 excessive system resources. Validators MUST NOT fall into an 595 infinite loop. 597 Servers need to take care that malicious parties can't change the 598 functionality of existing schemas by uploading a schema with an pre- 599 existing or very similar "$id". 601 Individual JSON Schema vocabularies are liable to also have their own 602 security considerations. Consult the respective specifications for 603 more information. 605 12. IANA Considerations 607 The proposed MIME media type for JSON Schema is defined as follows: 609 Type name: application 611 Subtype name: schema+json 613 Required parameters: N/A 615 Encoding considerations: Encoding considerations are identical to 616 those specified for the "application/json" media type. See JSON 617 [RFC7159]. 619 Security considerations: See Section 11 above. 621 Interoperability considerations: See Sections 6.2 and 6.3 above. 623 Fragment identifier considerations: See Section 5 625 13. References 627 13.1. Normative References 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, 631 DOI 10.17487/RFC2119, March 1997, 632 . 634 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 635 Resource Identifier (URI): Generic Syntax", STD 66, 636 RFC 3986, DOI 10.17487/RFC3986, January 2005, 637 . 639 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type 640 Structured Syntax Suffixes", RFC 6839, 641 DOI 10.17487/RFC6839, January 2013, 642 . 644 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 645 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 646 DOI 10.17487/RFC6901, April 2013, 647 . 649 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 650 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 651 2014, . 653 [W3C.REC-ldp-20150226] 654 Speicher, S., Arwe, J., and A. Malhotra, "Linked Data 655 Platform 1.0", World Wide Web Consortium Recommendation 656 REC-ldp-20150226, February 2015, 657 . 659 13.2. Informative References 661 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 662 DOI 10.17487/RFC5988, October 2010, 663 . 665 [RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906, 666 DOI 10.17487/RFC6906, March 2013, 667 . 669 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 670 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 671 October 2013, . 673 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 674 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 675 DOI 10.17487/RFC7231, June 2014, 676 . 678 [W3C.WD-fragid-best-practices-20121025] 679 Tennison, J., "Best Practices for Fragment Identifiers and 680 Media Type Definitions", World Wide Web Consortium 681 LastCall WD-fragid-best-practices-20121025, October 2012, 682 . 685 [json-schema-validation] 686 Wright, A. and G. Luff, "JSON Schema Validation: A 687 Vocabulary for Structural Validation of JSON", draft- 688 wright-json-schema-validation-00 (work in progress), 689 October 2016. 691 [json-hyper-schema] 692 Wright, A. and G. Luff, "JSON Hyper-Schema: A Vocabulary 693 for Hypermedia Annotation of JSON", draft-wright-json- 694 schema-hyperschema-00 (work in progress), October 2016. 696 Appendix A. Acknowledgments 698 Thanks to Gary Court, Francis Galiegue, Kris Zyp, and Geraint Luff 699 for their work on the initial drafts of JSON Schema. 701 Thanks to Jason Desrosiers, Daniel Perrett, Erik Wilde, Ben Hutton, 702 Evgeny Poberezkin, Brad Bowman, Gowry Sankar, Donald Pipowitch, and 703 Dave Finlay for their submissions and patches to the document. 705 Appendix B. ChangeLog 707 [[CREF3: This section to be removed before leaving Internet-Draft 708 status.]] 710 draft-wright-json-schema-01 712 * Updated intro 714 * Allowed for any schema to be a boolean 716 * "$schema" SHOULD NOT appear in subschemas, although that may 717 change 719 * Changed "id" to "$id"; all core keywords prefixed with "$" 721 * Clarify and formalize fragments for application/schema+json 723 * Note applicability to formats such as CBOR that can be 724 represented in the JSON data model 726 draft-wright-json-schema-00 728 * Updated references to JSON 730 * Updated references to HTTP 732 * Updated references to JSON Pointer 734 * Behavior for "id" is now specified in terms of RFC3986 736 * Aligned vocabulary usage for URIs with RFC3986 738 * Removed reference to draft-pbryan-zyp-json-ref-03 740 * Limited use of "$ref" to wherever a schema is expected 742 * Added definition of the "JSON Schema data model" 743 * Added additional security considerations 745 * Defined use of subschema identifiers for "id" 747 * Rewrote section on usage with HTTP 749 * Rewrote section on usage with rel="describedBy" and 750 rel="profile" 752 * Fixed numerous invalid examples 754 draft-zyp-json-schema-04 756 * Split validation keywords into separate document 758 draft-zyp-json-schema-00 760 * Initial draft. 762 * Salvaged from draft v3. 764 * Mandate the use of JSON Reference, JSON Pointer. 766 * Define the role of "id". Define URI resolution scope. 768 * Add interoperability considerations. 770 Authors' Addresses 772 Austin Wright (editor) 774 EMail: aaa@bzfx.net 776 Henry Andrews (editor) 777 Cloudflare, Inc. 779 EMail: henry@cloudflare.com