| Internet Engineering Task Force | fge. Galiegue, Ed. |
| Internet-Draft | |
| Intended status: Informational | K. Zyp |
| Expires: August 26, 2017 | SitePen (USA) |
| G. Court | |
| 2013 |
JSON Schema: interactive and non interactive validation
draft-fge-json-schema-validation-00
JSON Schema (application/schema+json) has several purposes, one of which is instance validation. The validation process may be interactive or non interactive. For instance, applications may use JSON Schema to build a user interface enabling interactive content generation in addition to user input checking, or validate data retrieved from various sources. This specification describes schema keywords dedicated to validation purposes.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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/.
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."
This Internet-Draft will expire on August 26, 2017.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
JSON Schema can be used to require that a given JSON document (an instance) satisfies a certain number of criteria. These criteria are materialized by a set of keywords which are described in this specification. In addition, a set of keywords is defined to assist in interactive instance generation. Those are also described in this specification.
This specification will use the terminology defined by the JSON Schema core specification. It is advised that readers have a copy of this specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This specification uses the term "container instance" to refer to both array and object instances. It uses the term "children instances" to refer to array elements or object member values.
This specification uses the term "property set" to refer to the set of an object's member names; for instance, the property set of JSON Object { "a": 1, "b": 2 } is [ "a", "b" ].
Elements in an array value are said to be unique if no two elements of this array are equal, as defined by the core specification.
It should be noted that the nul character (\x00) is valid in a JSON string. An instance to validate may contain a string value with this character, regardless of the ability of the underlying programming language to deal with such data.
The JSON specification does not define any bounds to the scale or precision of numeric values. JSON Schema does not define any such bounds either. This means that numeric instances processed by JSON Schema can be arbitrarily large and/or have an arbitrarily large decimal part, regardless of the ability of the underlying programming language to deal with such data.
Two validation keywords, "pattern" and "patternProperties", use regular expressions to express constraints. These regular expressions SHOULD be valid according to the ECMA 262 [ecma262] regular expression dialect.
Furthermore, given the high disparity in regular expression constructs support, schema authors SHOULD limit themselves to the following regular expression tokens:
Finally, implementations MUST NOT consider that regular expressions are anchored, neither at the beginning nor at the end. This means, for instance, that "es" matches "expression".
Some validation keywords only apply to one or more primitive types. When the primitive type of the instance cannot be validated by a given keyword, validation for this keyword and instance SHOULD succeed.
This specification groups keywords in different sections, according to the primitive type, or types, these keywords validate. Note that some keywords validate all instance types.
In order to validate an instance, some keywords are influenced by the presence (or absence) of other keywords. In this case, all these keywords will be grouped in the same section.
Some keywords, if absent, MAY be regarded by implementations as having a default value. In this case, the default value will be mentioned.
Keywords with the possibility to validate container instances (arrays or objects) only validate the instances themselves and not their children (array items or object properties). Some of these keywords do, however, contain information which is necessary for calculating which schema(s) a child must be valid against. The algorithms to calculate a child instance's relevant schema(s) are explained in a separate section.
It should be noted that while an array element will only have to validate against one schema, object member values may have to validate against more than one schema.
The value of "multipleOf" MUST be a JSON number. This number MUST be strictly greater than 0.
A numeric instance is valid against "multipleOf" if the result of the division of the instance by this keyword's value is an integer.
The value of "maximum" MUST be a JSON number. The value of "exclusiveMaximum" MUST be a boolean.
If "exclusiveMaximum" is present, "maximum" MUST also be present.
Successful validation depends on the presence and value of "exclusiveMaximum":
"exclusiveMaximum", if absent, may be considered as being present with boolean value false.
The value of "minimum" MUST be a JSON number. The value of "exclusiveMinimum" MUST be a boolean.
If "exclusiveMinimum" is present, "minimum" MUST also be present.
Successful validation depends on the presence and value of "exclusiveMinimum":
"exclusiveMinimum", if absent, may be considered as being present with boolean value false.
The value of this keyword MUST be an integer. This integer MUST be greater than, or equal to, 0.
A string instance is valid against this keyword if its length is less than, or equal to, the value of this keyword.
The length of a string instance is defined as the number of its characters as defined by RFC 4627 [RFC4627].
The value of this keyword MUST be an integer. This integer MUST be greater than, or equal to, 0.
A string instance is valid against this keyword if its length is greater than, or equal to, the value of this keyword.
The length of a string instance is defined as the number of its characters as defined by RFC 4627 [RFC4627].
"minLength", if absent, may be considered as being present with integer value 0.
The value of this keyword MUST be a string. This string SHOULD be a valid regular expression, according to the ECMA 262 regular expression dialect.
A string instance is considered valid if the regular expression matches the instance successfully. Recall: regular expressions are not implicitly anchored.
The value of "additionalItems" MUST be either a boolean or an object. If it is an object, this object MUST be a valid JSON Schema.
The value of "items" MUST be either an object or an array. If it is an object, this object MUST be a valid JSON Schema. If it is an array, items of this array MUST be objects, and each of these objects MUST be a valid JSON Schema.
Successful validation of an array instance with regards to these two keywords is determined as follows:
The following example covers the case where "additionalItems" has boolean value false and "items" is an array, since this is the only situation under which an instance may fail to validate successfully.
This is an example schema:
{
"items": [ {}, {}, {} ],
"additionalItems": false
}
With this schema, the following instances are valid:
the following instances are invalid:
If either keyword is absent, it may be considered present with an empty schema.
The value of this keyword MUST be an integer. This integer MUST be greater than, or equal to, 0.
An array instance is valid against "maxItems" if its size is less than, or equal to, the value of this keyword.
The value of this keyword MUST be an integer. This integer MUST be greater than, or equal to, 0.
An array instance is valid against "minItems" if its size is greater than, or equal to, the value of this keyword.
If this keyword is not present, it may be considered present with a value of 0.
The value of this keyword MUST be a boolean.
If this keyword has boolean value false, the instance validates successfully. If it has boolean value true, the instance validates successfully if all of its elements are unique.
If not present, this keyword may be considered present with boolean value false.
The value of this keyword MUST be an integer. This integer MUST be greater than, or equal to, 0.
An object instance is valid against "maxProperties" if its number of properties is less than, or equal to, the value of this keyword.
The value of this keyword MUST be an integer. This integer MUST be greater than, or equal to, 0.
An object instance is valid against "minProperties" if its number of properties is greater than, or equal to, the value of this keyword.
If this keyword is not present, it may be considered present with a value of 0.
The value of this keyword MUST be an array. This array MUST have at least one element. Elements of this array MUST be strings, and MUST be unique.
An object instance is valid against this keyword if its property set contains all elements in this keyword's array value.
The value of "additionalProperties" MUST be a boolean or an object. If it is an object, it MUST also be a valid JSON Schema.
The value of "properties" MUST be an object. Each value of this object MUST be an object, and each object MUST be a valid JSON Schema.
The value of "patternProperties" MUST be an object. Each property name of this object SHOULD be a valid regular expression, according to the ECMA 262 regular expression dialect. Each property value of this object MUST be an object, and each object MUST be a valid JSON Schema.
Successful validation of an object instance against these three keywords depends on the value of "additionalProperties":
If either "properties" or "patternProperties" are absent, they can be considered present with an empty object as a value.
If "additionalProperties" is absent, it may be considered present with an empty schema as a value.
In this case, validation of the instance depends on the property set of "properties" and "patternProperties". In this section, the property names of "patternProperties" will be called regexes for convenience.
The first step is to collect the following sets:
Having collected these three sets, the process is as follows:
Validation of the instance succeeds if, after these two steps, set "s" is empty.
This schema will be used as an example:
{
"properties": {
"p1": {}
},
"patternProperties": {
"p": {},
"[0-9]": {}
},
"additionalProperties": false
}
This is the instance to validate:
{
"p1": true,
"p2": null,
"a32&o": "foobar",
"": [],
"fiddle": 42,
"apple": "pie"
}
The three property sets are:
Applying the two steps of the algorithm:
The set "s" still contains two elements, "" and "fiddle". Validation therefore fails.
This keyword's value MUST be an object. Each value of this object MUST be either an object or an array.
If the value is an object, it MUST be a valid JSON Schema. This is called a schema dependency.
If the value is an array, it MUST have at least one element. Each element MUST be a string, and elements in the array MUST be unique. This is called a property dependency.
For all (name, schema) pair of schema dependencies, if the instance has a property by this name, then it must also validate successfully against the schema.
Note that this is the instance itself which must validate successfully, not the value associated with the property name.
For each (name, propertyset) pair of property dependencies, if the instance has a property by this name, then it must also have properties with the same names as propertyset.
The value of this keyword MUST be an array. This array MUST have at least one element. Elements in the array MUST be unique.
Elements in the array MAY be of any type, including null.
An instance validates successfully against this keyword if its value is equal to one of the elements in this keyword's array value.
The value of this keyword MUST be either a string or an array. If it is an array, elements of the array MUST be strings and MUST be unique.
String values MUST be one of the seven primitive types defined by the core specification.
An instance matches successfully if its primitive type is one of the types defined by keyword. Recall: "number" includes "integer".
This keyword's value MUST be an array. This array MUST have at least one element.
Elements of the array MUST be objects. Each object MUST be a valid JSON Schema.
An instance validates successfully against this keyword if it validates successfully against all schemas defined by this keyword's value.
This keyword's value MUST be an array. This array MUST have at least one element.
Elements of the array MUST be objects. Each object MUST be a valid JSON Schema.
An instance validates successfully against this keyword if it validates successfully against at least one schema defined by this keyword's value.
This keyword's value MUST be an array. This array MUST have at least one element.
Elements of the array MUST be objects. Each object MUST be a valid JSON Schema.
An instance validates successfully against this keyword if it validates successfully against exactly one schema defined by this keyword's value.
This keyword's value MUST be an object. This object MUST be a valid JSON Schema.
An instance is valid against this keyword if it fails to validate successfully against the schema defined by this keyword.
This keyword's value MUST be an object. Each member value of this object MUST be a valid JSON Schema.
This keyword plays no role in validation per se. Its role is to provide a standardized location for schema authors to inline JSON Schemas into a more general schema.
{
"type": "array",
"items": { "$ref": "#/definitions/positiveInteger" },
"definitions": {
"positiveInteger": {
"type": "integer",
"minimum": 0,
"exclusiveMinimum": true
}
}
}
As an example, here is a schema describing an array of positive integers, where the positive integer constraint is a subschema in "definitions":
The value of both of these keywords MUST be a string.
Both of these keywords can be used to decorate a user interface with information about the data produced by this user interface. A title will preferrably be short, whereas a description will provide explanation about the purpose of the instance described by this schema.
Both of these keywords MAY be used in root schemas, and in any subschemas.
There are no restrictions placed on the value of this keyword.
This keyword can be used to supply a default JSON value associated with a particular schema. It is RECOMMENDED that a default value be valid against the associated schema.
This keyword MAY be used in root schemas, and in any subschemas.
Structural validation alone may be insufficient to validate that an instance meets all the requirements of an application. The "format" keyword is defined to allow interoperable semantic validation for a fixed subset of values which are accurately described by authoritative resources, be they RFCs or other external specifications.
The value of this keyword is called a format attribute. It MUST be a string. A format attribute can generally only validate a given set of instance types. If the type of the instance to validate is not in this set, validation for this format attribute and instance SHOULD succeed.
Implementations MAY support the "format" keyword. Should they choose to do so:
Implementations MAY add custom format attributes. Save for agreement between parties, schema authors SHALL NOT expect a peer implementation to support this keyword and/or custom format attributes.
This attribute applies to string instances.
A string instance is valid against this attribute if it is a valid date representation as defined by RFC 3339, section 5.6 [RFC3339].
This attribute applies to string instances.
A string instance is valid against this attribute if it is a valid Internet email address as defined by RFC 5322, section 3.4.1 [RFC5322].
This attribute applies to string instances.
A string instance is valid against this attribute if it is a valid representation for an Internet host name, as defined by RFC 1034, section 3.1 [RFC1034].
This attribute applies to string instances.
A string instance is valid against this attribute if it is a valid representation of an IPv4 address according to the "dotted-quad" ABNF syntax as defined in RFC 2673, section 3.2 [RFC2673].
This attribute applies to string instances.
A string instance is valid against this attribute if it is a valid representation of an IPv6 address as defined in RFC 2373, section 2.2 [RFC2373].
This attribute applies to string instances.
A string instance is valid against this attribute if it is a valid URI, according to [RFC3986].
Calculating the schema, or schemas, a child instance must validate against is influenced by the following:
In addition, it is important that if one or more keyword(s) implied in the calculation are not defined, they be considered present with their default value, which will be recalled in this section.
The defining characteristic of the child instance is its index within the array. Recall: array indices start at 0.
The two implied keywords in this calculation are "items" and "additionalItems".
If either keyword is absent, it is considered present with an empty schema as a value. In addition, boolean value true for "additionalItems" is considered equivalent to an empty schema.
If items is a schema, then the child instance must be valid against this schema, regardless of its index, and regardless of the value of "additionalItems".
In this situation, the schema depends on the index:
The defining characteristic is the property name of the child.
The three keywords implied in this calculation are "properties", "patternProperties" and "additionalProperties".
If "properties" or "patternProperties" are absent, they are considered present with an empty object as a value.
If "additionalProperties" is absent, it is considered present with an empty schema as a value. In addition, boolean value true is considered equivalent to an empty schema.
The calculation below uses the following names:
If set "p" contains value "m", then the corresponding schema in "properties" is added to "s".
For each regex in "pp", if it matches "m" successfully, the corresponding schema in "patternProperties" is added to "s".
The schema defined by "additionalProperties" is added to "s" if and only if, at this stage, "s" is empty.
JSON Schema validation does not have any additional security considerations than those defined by the JSON Schema core specification.
This specification does not have any influence with regards to IANA.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC1034] | Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987. |
| [RFC2373] | Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998. |
| [RFC2673] | Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, DOI 10.17487/RFC2673, August 1999. |
| [RFC3339] | Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002. |
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005. |
| [RFC4627] | Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, DOI 10.17487/RFC4627, July 2006. |
| [RFC5322] | Resnick, P., Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008. |
| [ecma262] | ECMA 262 specification" | , "