You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 2, 2023. It is now read-only.
<metaname="dct.abstract" content="JSON Schema defines the media type "application/schema+json", a JSON-based format for describing the structure of JSON data. JSON Schema asserts what a JSON document must look like, ways to extract information from it, and how to interact with it. The "application/schema-instance+json" media type provides additional feature-rich integration with "application/schema+json" beyond what can be offered for "application/json" documents. " />
429
429
<metaname="description" content="JSON Schema defines the media type "application/schema+json", a JSON-based format for describing the structure of JSON data. JSON Schema asserts what a JSON document must look like, ways to extract information from it, and how to interact with it. The "application/schema-instance+json" media type provides additional feature-rich integration with "application/schema+json" beyond what can be offered for "application/json" documents. " />
430
430
@@ -448,20 +448,20 @@
448
448
<tdclass="right">H. Andrews, Ed.</td>
449
449
</tr>
450
450
<tr>
451
-
<tdclass="left">Expires: April 23, 2018</td>
451
+
<tdclass="left">Expires: May 20, 2018</td>
452
452
<tdclass="right">Cloudflare, Inc.</td>
453
453
</tr>
454
454
<tr>
455
455
<tdclass="left"></td>
456
-
<tdclass="right">October 20, 2017</td>
456
+
<tdclass="right">November 16, 2017</td>
457
457
</tr>
458
458
459
459
460
460
</tbody>
461
461
</table>
462
462
463
-
<pclass="title">FOR PRE-PUBLICATION REVIEW ONLY: JSON Schema: A Media Type for Describing JSON Documents<br/>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
480
480
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
481
481
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
482
-
<p>This Internet-Draft will expire on April 23, 2018.</p>
482
+
<p>This Internet-Draft will expire on May 20, 2018.</p>
@@ -585,7 +585,7 @@ <h1 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1.</a> Instance Data
585
585
<pid="rfc.section.4.2.1.p.5">Note that JSON Schema vocabularies are free to define their own extended type system. This should not be confused with the core data model types defined here. As an example, "integer" is a reasonable type for a vocabulary to define as a value for a keyword, but the data model makes no distinction between integers and other numbers. </p>
586
586
<h1id="rfc.section.4.2.2"><ahref="#rfc.section.4.2.2">4.2.2.</a> Instance Media Types</h1>
587
587
<pid="rfc.section.4.2.2.p.1">JSON Schema is designed to fully work with "application/json" documents, as well as media types using the "+json" structured syntax suffix. </p>
588
-
<pid="rfc.section.4.2.2.p.2">Some functionality that is useful for working with schemas is defined by each media type, namely media type parameters and URI fragment identifier syntax and semantics. These features are useful in content negotiation and in caclulating URIs for specific locations within an instance, respectively. </p>
588
+
<pid="rfc.section.4.2.2.p.2">Some functionality that is useful for working with schemas is defined by each media type, namely media type parameters and URI fragment identifier syntax and semantics. These features are useful in content negotiation and in calculating URIs for specific locations within an instance, respectively. </p>
589
589
<pid="rfc.section.4.2.2.p.3">This specification defines the "application/schema-instance+json" media type in order to allow instance authors to take full advantage of parameters and fragment identifiers for these purposes. </p>
<pid="rfc.section.4.2.3.p.1">Two JSON instances are said to be equal if and only if they are of the same type and have the same value according to the data model. Specifically, this means: </p>
<pid="rfc.section.6.4.p.1">Implementations MAY define additional keywords to JSON Schema. Save for explicit agreement, schema authors SHALL NOT expect these additional keywords to be supported by peer implementations. Implementations SHOULD ignore keywords they do not support. </p>
669
669
<pid="rfc.section.6.4.p.2">Authors of extensions to JSON Schema are encouraged to write their own meta-schemas, which extend the existing meta-schemas using "allOf". This extended meta-schema SHOULD be referenced using the "$schema" keyword, to allow tools to follow the correct behaviour. </p>
670
-
<pid="rfc.section.6.4.p.3">Note that the recursive nature of meta-schemas requires re-definining recursive keywords in the extended meta-schema, as can be seen in the JSON Hyper-Schema meta-schema. </p>
670
+
<pid="rfc.section.6.4.p.3">Note that the recursive nature of meta-schemas requires re-defining recursive keywords in the extended meta-schema, as can be seen in the JSON Hyper-Schema meta-schema. </p>
671
671
<h1id="rfc.section.7"><ahref="#rfc.section.7">7.</a> The "$schema" Keyword</h1>
672
672
<pid="rfc.section.7.p.1">The "$schema" keyword is both used as a JSON Schema version identifier and the ___location of a resource which is itself a JSON Schema, which describes any schema written for this particular version. </p>
673
673
<pid="rfc.section.7.p.2">The value of this keyword MUST be a <ahref="#RFC3986">URI</a><citetitle="NONE">[RFC3986]</cite> (containing a scheme) and this URI MUST be normalized. The current schema MUST be valid against the meta-schema identified by this URI. </p>
@@ -687,7 +687,7 @@ <h1 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1.</a> Initial Base URI</h
<pid="rfc.section.9.2.p.1">The "$id" keyword defines a URI for the schema, and the base URI that other URI references within the schema are resolved against. A subschema's "$id" is resolved against the base URI of its parent schema. If no parent sets an explicit base with "$id", the base URI is that of the entire document, as determined per <ahref="#RFC3986">RFC 3986 section 5</a><citetitle="NONE">[RFC3986]</cite>. </p>
689
689
<pid="rfc.section.9.2.p.2">If present, the value for this keyword MUST be a string, and MUST represent a valid <ahref="#RFC3986">URI-reference</a><citetitle="NONE">[RFC3986]</cite>. This value SHOULD be normalized, and SHOULD NOT be an empty fragment <#> or an empty string <>. </p>
690
-
<pid="rfc.section.9.2.p.3">The root schema of a JSON Schema document SHOULD contain an "$id" keyword with a URI (containing a scheme). This URI SHOULD either not have a fragment, or have one that is an empty string. <aid="CREF3" class="info">[CREF3]<spanclass="info">How should an "$id" URI reference containing a fragement with other components be interpreted? There are two cases: when the other components match the current base URI and when they change the base URI. </span></a></p>
690
+
<pid="rfc.section.9.2.p.3">The root schema of a JSON Schema document SHOULD contain an "$id" keyword with a URI (containing a scheme). This URI SHOULD either not have a fragment, or have one that is an empty string. <aid="CREF3" class="info">[CREF3]<spanclass="info">How should an "$id" URI reference containing a fragment with other components be interpreted? There are two cases: when the other components match the current base URI and when they change the base URI. </span></a></p>
691
691
<pid="rfc.section.9.2.p.4">To name subschemas in a JSON Schema document, subschemas can use "$id" to give themselves a document-local identifier. This is done by setting "$id" to a URI reference consisting only of a plain name fragment (not a JSON Pointer fragment). The fragment identifier MUST begin with a letter ([A-Za-z]), followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), or periods ("."). </p>
692
692
<pid="rfc.section.9.2.p.5">Providing a plain name fragment enables a subschema to be relocated within a schema without requiring that JSON Pointer references are updated. </p>
693
693
<pid="rfc.section.9.2.p.6">The effect of defining a fragment-only "$id" URI reference that neither matches the above requirements nor is a valid JSON pointer is not defined. </p>
@@ -810,7 +810,7 @@ <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a href="#security" id
810
810
<pid="rfc.section.12.p.3">Servers need to take care that malicious parties can't change the functionality of existing schemas by uploading a schema with an pre-existing or very similar "$id". </p>
811
811
<pid="rfc.section.12.p.4">Individual JSON Schema vocabularies are liable to also have their own security considerations. Consult the respective specifications for more information. </p>
812
812
<pid="rfc.section.12.p.5">Schema authors should take care with "$comment" contents, as a malicious implementation can display them to end-users in violation of a spec, or fail to strip them if such behavior is expected. </p>
813
-
<pid="rfc.section.12.p.6">A malicous schema author could place executable code or other dangerous material within a "$comment". Implementations MUST NOT parse or otherwise take action based on "$comment" contents. </p>
813
+
<pid="rfc.section.12.p.6">A malicious schema author could place executable code or other dangerous material within a "$comment". Implementations MUST NOT parse or otherwise take action based on "$comment" contents. </p>
0 commit comments